Hallo Chris,
poste doch mal Deine .htaccess.
Häufig liegt es am Zertifikat - was für eines verwendest Du denn?
Beste Grüße
Jörg
Hallo Chris,
poste doch mal Deine .htaccess.
Häufig liegt es am Zertifikat - was für eines verwendest Du denn?
Beste Grüße
Jörg
Hallo Christian,
meine .htaccess greift die von Dir genannten Direktiven auf. Ich habe auch verschiedene Varianten getestet.
Merkwürdig ist, dass Moodle problemlos mit LDAPs authentifizieren kann.
VG
Chris
Hallo Jörg,
müssten denn dann Moodle und andere Web-Anwendungen, die via LDAPs authentifizieren, nicht ebenfalls Zertifikatsprobleme haben? Oder handhabt das Apache dann anders? Ldapsearch zu diesem host funktioniert auch.
VG
Chris
Hallo Chris,
das spricht in der Tat gegen Zertifikatsprobleme.
Sind denn mod_auth_basic und mod_authnz_ldap aktiviert?
Ansonsten würde ich mal beim Ldap-Sever das Loglevel hochsetzen und schauen, o da überhaupt eine Anfrage ankommt.
Viele Grüße
Jörg
Wenn das mit dem Loglevel so einfach tut ist gut, ich steige bei solchen Problemen immer erstmal mit einem tcpdump ein, setze mich per ssh auf den ldap-Server und schau ob da beim Authentifizieren ueberhaupt was ankommt. Wenn da nix zappelt, stimmt die Route nicht, das VPN hat Probleme oder oder …
tcpdump -i eth0 src host IP_des_Servers_mit_Anfrage
Hallo,
vielen Dank für Eure Antworten.
Also wenn ich:
ldapsearch -x -D ‘uid=USERID,ou=accounts,dc=linux,dc=lokal’ -W -H ldaps://<EIGENE_DYNDNS_ADRESSE>:636 -b ou=accounts,dc=linux,dc=lokal uid=USERID
in angepasster Form angebe, erhalte ich die Abfrage des LDAP-PW, danach werden die korrekten Infos dargestellt.
Die LDAPs-Anfrage geht also problemlos durch. Gleiches gilt ja auch für Moodle etc.
Das Problem tritt wirklich nur bei Apache 2.4 bei der Verzeichnisauthentifizierung auf.
Hier mal die .htaccess
AuthName "Anmeldung"
AuthBasicProvider ldap
AuthType Basic
AuthLDAPURL "ldaps://MeineURL:636/ou=accounts,dc=linuxmuster,dc=local?uid"
Optional mal angewendet: AuthLDAPBindDN "cn=USERID,ou=accounts,dc=linuxmuster,dc=local"
Optional mal angewendet: AuthLDAPBindPassword "pw"
require valid-user
Bei AuthLDAPURL habe ich auch schon ?uid weggelassen.
Die entsprechenden LDAP-Module für den Apache sind natürlich aktiviert und die Direktive für 2.4
AuthzLDAPAuthoritative on
habe ich ebenfalls rausgelassen, da diese in 2.4 nicht mehr unterstützt wird und zu Fehlern führt.
Für die Logs habe ich Debug eingestellt und bei dem Versuch sich via LDAP für das Verzeichnis zu authentifizieren sehe ich folgende Fehlermeldung:
[authnz_ldap:info] [pid 12458] [client XXX.XXX.XXX.XXX:32193] AH01695: auth_ldap authenticate: user USERID authentication failed; U
RI /verzeichnis/ [LDAP: ldap_simple_bind() failed][Can’t contact LDAP server]
Ergebnis des tcpdump auf dem linuxmuster.net Servers:
cpdump -v -i eth0 src host xxx.xxx.xxx.xxx
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
13:03:15.273179 IP (tos 0x0, ttl 57, id 26268, offset 0, flags [DF], proto TCP (6), length 60)
meineURL.44192 > server01.linuxmuster.local.ldaps: Flags [S], cksum 0x1006 (correct), seq 734111637, win 29200, options [mss 1452,sackOK,TS val 786546953 ecr 0,nop,wscale 7], length 0
13:03:15.298667 IP (tos 0x0, ttl 57, id 26269, offset 0, flags [DF], proto TCP (6), length 52)
meineURL.44192 > server01.linuxmuster.local.ldaps: Flags [.], cksum 0x835d (correct), ack 2518879203, win 229, options [nop,nop,TS val 786546979 ecr 258439936], length 0
13:03:15.298715 IP (tos 0x0, ttl 57, id 26270, offset 0, flags [DF], proto TCP (6), length 284)
meineURL.44192 > server01.linuxmuster.local.ldaps: Flags [P.], cksum 0x532c (correct), seq 0:232, ack 1, win 229, options [nop,nop,TS val 786546980 ecr 258439936], length 232
13:03:15.324560 IP (tos 0x0, ttl 57, id 26271, offset 0, flags [DF], proto TCP (6), length 52)
meineURL.44192 > server01.linuxmuster.local.ldaps: Flags [.], cksum 0x81fe (correct), ack 87, win 229, options [nop,nop,TS val 786547005 ecr 258439943], length 0
13:03:15.329469 IP (tos 0x0, ttl 57, id 26272, offset 0, flags [DF], proto TCP (6), length 52)
meineURL.44192 > server01.linuxmuster.local.ldaps: Flags [.], cksum 0x7ee3 (correct), ack 865, win 241, options [nop,nop,TS val 786547010 ecr 258439943], length 0
13:03:15.329494 IP (tos 0x0, ttl 57, id 26273, offset 0, flags [DF], proto TCP (6), length 52)
meineURL.44192 > server01.linuxmuster.local.ldaps: Flags [.], cksum 0x7eda (correct), ack 874, win 241, options [nop,nop,TS val 786547010 ecr 258439943], length 0
13:03:15.330201 IP (tos 0x0, ttl 57, id 26274, offset 0, flags [DF], proto TCP (6), length 191)
meineURL.44192 > server01.linuxmuster.local.ldaps: Flags [P.], cksum 0x8741 (correct), seq 232:371, ack 874, win 241, options [nop,nop,TS val 786547011 ecr 258439943], length 139
Anfrage scheint also anzukommen, aber ?
VG
Christian
Da muss ich leider aussteigen, ich hasse LDAP und weiss nicht, wieviele Stunden meines Lebens ich damit schon verheizt habe - mit begrenztem Erkenntnisgewinn. LDAP und Zope werden meine Sargnaegel.
Hallo Chris,
die .htaccess sollte z. B. so aussehen:
AuthName "Anmeldung"
AuthBasicProvider ldap
AuthType Basic
AuthLDAPURL ldaps://MeineURL/dc=linuxmuster,dc=local?uid
AuthLDAPGroupAttributeIsDN off
AuthLDAPGroupAttribute memberUid
require ldap-group cn=teachers,ou=groups,dc=linuxmuster,dc=local
Und natürlich muss in der Apache-Konfiguration das Überschreiben von AuthConfig per .htaccess-Datei zugelassen sein.
Viele Grüße
Jörg
Hallo Jörg,
Überschrieben von AuthConfig via .htaccess habe ich aktiviert.
Ja meine .htaccess habe ich nun auch mal nach Deinem Vorschlag umgestellt, mit mehrfach angepasster URL (mal ohne mal mit Portnr), aber leider ohne Erfolg. Mal mit Bind DN mal als anonymous, mal Group Dirrectiven auskommentiert …
Bislang ohne Erfolg.
VG
Chris
Hallo Chris,
nun war ich neugierig und habe es mit einem externen Apache 2.4 und unserem Schulserver probiert. Das klappt mit der oben geposteten .htaccess und einem Lehrer-Account.
Wenn man einen einzelnen User zulassen möchte, dann lautet die Syntax übrigens einfach nur:
require ldap-user username
Vielleicht liegt es daran?
Beste Grüße
Jörg
Hallo Jörg,
danke für Deinen Test.
Ich habe nun nochmal folgende .htaccess getestet:
AuthName "Anmeldung"
AuthBasicProvider ldap
AuthType Basic
AuthLDAPURL "ldaps://meineURL:636/dc=linuxmuster,dc=local?uid"
AuthLDAPGroupAttributeIsDN off
AuthLDAPGroupAttribute memberUid
Require valid-user
Das Ganze wird wieder mit Internal Server error quittiert.
In den Debug-Logs des Apache sehe ich nur den Hinweis:
[LDAP: ldap_simple_bind() failed][Can’t contact LDAP server]
Mit tcpdump sehe ich, dass auf dem linuxmuster.net Server die Anfrage ankommt und eine TCP-Verbindung hergestellt wird.
Da muss noch ein anderer Fehler sein. ldapsearch - Anfragen funktionieren ja mit meiner URL und den sonstigen Angaben.
VG
Chris
Ich hatte mal Probleme mit Roundup (Trouble Ticket System) an LDAPS, da musste ich die Zertifikatsueberpruefung abschalten, dann hat das erst getan, da “self signed” - vielleicht hat es damit was zu tun?
Hallo,
ok, es liegt tatsächlich am Zertifikat wie ich in Tests zusammen mit Jörg @jrichter herausgefunden habe. Ich nutze intern nur ein self-signed Zertifikat.
Das bedeutet, ich musst dem externen Apache beibringen, dass er das Zertifikat nicht vollständig prüft.
Ich habe nun unter
/etc/apache2/conf-enabled/security.conf
Folgende Direktive ganz am Ender der Datei eingetragen:
LDAPVerifyServerCert Off
Danach den Apache neu starten und mit der .haccess erneut getestet. Nun klappt es.
Danke @jrichter
VG
Chris
Hallo, Chris,
ich hab mir mal meine eigene Apache-LDAPs - Abfrage angesehen:
Bei mir ist noch das dabei:
…
AuthzLDAPAuthoritative on
…
Ich hab den Eintrag in der security NICHT (!)
L.G.
Christoph Gü
Hallo Christoph,
dieser Eintrag gilt wohl nur für Apache 2.2 bei 2.4 darf ein solcher Eintrag wohl nicht mehr verwendet werden.
VG
Chris
Hallo Chris,
und mal wieder wusste es das Wiki schon längst:
LG Jörg
ich hab dasselbe vor und bekomme nach login in einen 500er Error
Kennst du das?
kommt die .htaccess in den ordner test oder eine ebene höher ?
ja hab ich er sagt mir Internal Server Error
Die muss da mit hinein. Aber es ist auf jeden Fall ratsamer, das ganze mit funktionierender Verschlüsselung zu machen – so wie hier erläutert: