Hallo!
Wir setzen gerade unseren Webserver neu auf. Dabei wollen wir die
Authentifizierung über einen eingerichteten LDAP-Server realisieren.
Grundsätzlich funktioniert unser Setup. Allerdings liegt der Fehler - wie so
häufig - wohl im Detail.
Die Basisinstallation ist von Debian. Es kommen dabei folgende Verisonen zum
Einsatz:
Apache 2.0.52 mit aktiviertem mod_auth_ldap.
OpenSSL 0.9.7d (17. März 2004)
Auf dem LDAP-Server liegen folgende Versionen:
OpenSSL 0.9.7b (10. April 2003)
Ich habe das cacert.pem auf den Webserver kopiert und der Zugriff
funktioniert von der Shell aus auch:
(wobei auch die unverschlüsselte Übertragung ohne -Z{Z} auch funktioniert?!)
ldapsearch -h ldapserver.domain.de -b "ou=people,dc=domain,dc=de"
"uid=userid" -ZZ -x
# extended LDIF
#
# LDAPv3
# base <ou=people,dc=domain,dc=de> with scope sub
# filter: uid=userid
# requesting: ALL
#
# userid, people, domain.de
dn: uid=userid,ou=people,dc=domain,dc=de
objectClass: posixAccount
objectClass: inetOrgPerson
objectClass: sambaAccount
gidNumber: 100
uidNumber: 500
sn: [..]
loginShell: /bin/bash
homeDirectory: /home/userid
uid: userid
pwdLastSet: 1094566508
logonTime: 0
logoffTime: 2147483647
kickoffTime: 2147483647
pwdCanChange: 0
pwdMustChange: 2147483647
displayName: [..]
cn: [..]
rid: 2000
primaryGroupID: 1201
acctFlags: [UX ]
# search result
search: 3
result: 0 Success
# numResponses: 2
# numEntries: 1
Nun haben wir einen VirtualHost (für den DAV-Zugriff) in Apache
konfiguriert; und zwar so:
<VirtualHost *:80>
ServerName dav.domain.de
DocumentRoot /data/www/websites
<Directory /data/www/websites>
DAV on
ForceType text/plain
AuthType Basic
AuthName "DAV-Area"
AuthLDAPEnabled on #
LDAP einschalten
AuthLDAPURL
ldaps://ldapserver.domain.de/dc=domain,dc=de?uid?one
AuthLDAPAuthoritative on #
nur LDAP als Authentifizierung zulassen
require valid-user
Options all
AllowOverride None
Order allow,deny
Allow from all
</Directory>
# E-Mail-Adresse, die der Server in Fehlermeldungen einfügt, welche
an den Client gesendet werden
ServerAdmin [EMAIL PROTECTED]
# Possible values include: debug, info, notice, warn, error, crit,
alert, emerg.
LogLevel debug
CustomLog /data/www/log/dav.domain.de/access.log combined
ErrorLog /data/www/log/dav.domain.de/error.log
</VirtualHost>
Wenn ich nun unter Windows XP (SP 1 oder SP 2) einen WebFolder einrichten
will, um darauf zuzugreifen, poppt das Fenster mit "Benutzername" und
"Kennwort" hoch. Wenn ich die Felder ausfülle und Enter drücke, bricht
Windows mit dem Hinweis ab, dass ich keinen Zugriff habe.
Nun habe ich auf dem LDAP-Server das verbose debugging mal aktiviert. Hier
der Auszug:
Nov 5 10:13:52 slapd[10242]: daemon: activity on 1 descriptors
Nov 5 10:13:52 slapd[10242]: daemon: new connection on 29
Nov 5 10:13:52 slapd[10242]: conn=51 fd=29 ACCEPT from
IP=192.168.65.181:33162 (IP=0.0.0.0:636)
Nov 5 10:13:52 slapd[10242]: daemon: added 29r
Nov 5 10:13:52 slapd[10242]: daemon: activity on:
Nov 5 10:13:52 slapd[10242]:
Nov 5 10:13:52 slapd[10242]: daemon: select: listen=6 active_threads=1
tvp=NULL
Nov 5 10:13:52 slapd[10242]: daemon: select: listen=7 active_threads=1
tvp=NULL
Nov 5 10:13:52 slapd[10242]: daemon: select: listen=8 active_threads=1
tvp=NULL
Nov 5 10:13:52 slapd[10242]: daemon: select: listen=9 active_threads=1
tvp=NULL
Nov 5 10:13:52 slapd[10242]: daemon: activity on 1 descriptors
Nov 5 10:13:52 slapd[10242]: daemon: activity on:
Nov 5 10:13:52 slapd[10242]: 29r
Nov 5 10:13:52 slapd[10242]:
Nov 5 10:13:52 slapd[10242]: daemon: read activity on 29
Nov 5 10:13:52 slapd[10242]: connection_get(29)
Nov 5 10:13:52 slapd[10242]: connection_get(29): got connid=51
Nov 5 10:13:52 slapd[10242]: connection_read(29): checking for input on
id=51
Nov 5 10:13:52 slapd[10242]: connection_read(29): TLS accept error error=-1
id=51, closing
Nov 5 10:13:52 slapd[10242]: connection_closing: readying conn=51 sd=29 for
close
Nov 5 10:13:52 slapd[10242]: connection_close: conn=51 sd=29
Nov 5 10:13:52 slapd[10242]: daemon: removing 29
Nov 5 10:13:52 slapd[10242]: conn=51 fd=29 closed
Nov 5 10:13:52 slapd[10242]: daemon: select: listen=6 active_threads=1
tvp=NULL
Nov 5 10:13:52 slapd[10242]: daemon: select: listen=7 active_threads=1
tvp=NULL
Nov 5 10:13:52 slapd[10242]: daemon: select: listen=8 active_threads=1
tvp=NULL
Nov 5 10:13:52 slapd[10242]: daemon: select: listen=9 active_threads=1
tvp=NULL
Nov 5 10:13:52 slapd[10242]: daemon: activity on 1 descriptors
Nov 5 10:13:52 slapd[10242]: daemon: select: listen=6 active_threads=1
tvp=NULL
Nov 5 10:13:52 slapd[10242]: daemon: select: listen=7 active_threads=1
tvp=NULL
Nov 5 10:13:52 slapd[10242]: daemon: select: listen=8 active_threads=1
tvp=NULL
Nov 5 10:13:52 slapd[10242]: daemon: select: listen=9 active_threads=1
tvp=NULL
Daran meine ich zumindest zu erkennen, dass es erst gar nicht dazu kommt,
dasss im LDAP nach der uid gesucht wird. Das ganze bricht schon beim
Verbindungsaufbau ab. Und genau hier weiss ich nicht mehr weiter. Ich habe
das Web nun einen Tag durchsucht, aber nur einen gefunden, der ein ähnliches
Problem hat:
http://groups.google.com/groups?hl=de&lr=&threadm=DjsQc.3474%248%255.850%40prv-forum2.provo.novell.com&rnum=2&prev=/groups%3Fq%3DLDAPTrustedCAType%2Bpem%26hl%3Dde%26lr%3D%26selm%3DDjsQc.3474%25248%25255.850%2540prv-forum2.provo.novell.com%26rnum%3D2
Ich habe den Eintrag "TLS_REQCERT never" mal auf dem Webserver in die
/etc/ldap/ldap.conf eingetragen - aber ohne Erfolg.
Wenn man nun den VirtualHost-Eintrag auf dem Apache so ädert, dass das ganze
unverschüsselt laufen soll, dann klappt alles tadellos (anstatt ldaps:// nun
ldap://):
<VirtualHost *:80>
[...]
AuthLDAPEnabled on #
LDAP einschalten
AuthLDAPURL
ldap://ldapserver.domain.de/dc=q1ag,dc=de?uid?one
AuthLDAPAuthoritative on #
nur LDAP als Authentifizierung zulassen
[...]
</VirtualHost>
Es hapert wohl wirklich am TLS-Handshake. Und gerade das verstehe ich nicht,
weil es ja von der Kommandozeile funktioniert.
Hat jemand eine Idee?
Schöne Grüße,
-Thorsten-
--------------------------------------------------------------------------
Apache HTTP Server Mailing List "users-de"
unsubscribe-Anfragen an [EMAIL PROTECTED]
sonstige Anfragen an [EMAIL PROTECTED]
--------------------------------------------------------------------------
