ich hatte irgendwo gelesen, dass iplanet nicht alle certs akzeptiert, aber so, weiß ich auch nicht wirklich. steht im apache-errorlog noch was interressantes? notfalls mal bei apache das loglevel auf debug setzten. ansonsten fällt mir nur noch ein, das ganze unabhängig vom eingebauten ssl durch stunnel zu schicken. ist zwar nicht sehr elegant, müsste aber funktionieren. frag vieleicht bei der emglischen mailing-liste nochmal nach, da ist wesentlich mehr los, vieleicht weiß da jemand rat.
Gruß Ralf
----- Original Message ----- From: "Thorsten Göllner" <[EMAIL PROTECTED]>
To: <users-de@httpd.apache.org>
Sent: Wednesday, November 10, 2004 10:54 AM
Subject: Re: confirm subscribe to users-de@httpd.apache.org
Ich finde "openldap". Und nun?
----- Original Message ----- From: "Ralf Glauberman" <[EMAIL PROTECTED]>
To: <users-de@httpd.apache.org>
Sent: Tuesday, November 09, 2004 7:02 PM
Subject: Re: confirm subscribe to users-de@httpd.apache.org
Gute Frage, wie du das SDK rausfindest.
such mal in deinem system nach dateien mit ldap im namen, entweder mit
locate oder mit find, da wirst du an den opadensehen, welches es ist, müsste
entweder openldap, novellldap oder iplanet(netscape) irgendwo auftauchen.
----- Original Message ----- From: "Thorsten Göllner" <[EMAIL PROTECTED]>
To: <users-de@httpd.apache.org>
Sent: Tuesday, November 09, 2004 9:45 AM
Subject: Re: confirm subscribe to users-de@httpd.apache.org
In der /etc/apache2/apache2.conf habe ich 2 Zeilen eingefügt: LDAPTrustedCA /etc/apache2/ldap_cert/cacert.pem LDAPTrustedCAType BASE64_FILE
Wie bekomme ich denn raus, welches SDK ich benutze?
Der CA-Typ sollte - wie oeben eingestellt - richtig sein ... glaube ich. Die
Datei sieht wie folgt aus:
-----BEGIN CERTIFICATE-----
MIICpjCCAg+gAwIBAgIBADANBgkqhkiG9w0BAQQFADBHMQswCQYDVQQGEwJERTEM
MAoGA1UECBMDTlJXMQswCQYDVQQHEwJEVTELMAkGA1UEChMCUTExEDAOBgNVBAMT
...
-----END CERTIFICATE-----
----- Original Message ----- From: "Ralf Glauberman" <[EMAIL PROTECTED]>
To: <users-de@httpd.apache.org>
Sent: Monday, November 08, 2004 9:17 PM
Subject: Re: confirm subscribe to users-de@httpd.apache.org
sind LDAPTrustedCA /certs/certfile.der LDAPTrustedCAType DER_FILE eingestellt? welches ldap-sdk verwendest du (Netscape/iPlanet ?)? welcher ca-typ?
----- Original Message ----- From: "Thorsten Göllner" <[EMAIL PROTECTED]>
To: <users-de@httpd.apache.org>
Sent: Monday, November 08, 2004 6:54 PM
Subject: Re: confirm subscribe to users-de@httpd.apache.org
1.) Ja, das Zertifikat hat "644".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
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:
-
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] --------------------------------------------------------------------------
-------------------------------------------------------------------------- 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] --------------------------------------------------------------------------
--------------------------------------------------------------------------
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]
--------------------------------------------------------------------------