1.) Ja, das Zertifikat hat "644".
2.) Auch der LDAP-Server ist Linux (SuSE 9.0). Das von SuSE bereitgestellt
OpenSSL-Patch ist eingespielt.
3.) Die Verschlüsselung sollte schon sein. Wenn ich mit ldap://... arbeite,
klappt auch alles. Allerdings will ich die Übertragung verschlüsseln, weil
wir über einen Switch wandern, den ich nicht 100% kontrolliere :-) Eine
hardware-Lösung zur Absicherung haben wir leider nicht.
----- Original Message -----
From: "Ralf Glauberman" <[EMAIL PROTECTED]>
To: <users-de@httpd.apache.org>
Sent: Monday, November 08, 2004 6:02 PM
Subject: Re: confirm subscribe to users-de@httpd.apache.org
3 fragen:
1.) ist das zertifikat für den server lesbar? (rechte?)
2.) ist der ldap-server auch linux oder windows?
3.) ist eine verschlüsselte übertragung zwangsweise erforderlich.
normalerweise sollt die verbindung zwischen den servern schon hardwaremäßig
abhörsicher sei.
----- Original Message -----
From: "Thorsten Göllner" <[EMAIL PROTECTED]>
To: <users-de@httpd.apache.org>
Sent: Monday, November 08, 2004 11:29 AM
Subject: Re: confirm subscribe to users-de@httpd.apache.org
> 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]
> --------------------------------------------------------------------------
>
--------------------------------------------------------------------------
Apache HTTP Server Mailing List "users-de"
unsubscribe-Anfragen an [EMAIL PROTECTED]
sonstige Anfragen an [EMAIL PROTECTED]
--------------------------------------------------------------------------
--------------------------------------------------------------------------
Apache HTTP Server Mailing List "users-de"
unsubscribe-Anfragen an [EMAIL PROTECTED]
sonstige Anfragen an [EMAIL PROTECTED]
--------------------------------------------------------------------------
