httpd-users-de mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf Glauberman" <rglauber...@michaeli-gymnasium.de>
Subject Re: confirm subscribe to users-de@httpd.apache.org
Date Mon, 08 Nov 2004 20:17:23 GMT
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" <Thorsten.Goellner@Q1AG.de>
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".
> 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" <rglauberman@michaeli-gymnasium.de>
> 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" <Thorsten.Goellner@Q1AG.de>
> 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 webmaster@domain.de
>>
>>        # 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 users-de-unsubscribe@httpd.apache.org
>>           sonstige Anfragen an users-de-help@httpd.apache.org
>> --------------------------------------------------------------------------
>>
>
>
> --------------------------------------------------------------------------
>                Apache HTTP Server Mailing List "users-de"
>      unsubscribe-Anfragen an users-de-unsubscribe@httpd.apache.org
>           sonstige Anfragen an users-de-help@httpd.apache.org
> --------------------------------------------------------------------------
>
>
>
> --------------------------------------------------------------------------
>                Apache HTTP Server Mailing List "users-de"
>      unsubscribe-Anfragen an users-de-unsubscribe@httpd.apache.org
>           sonstige Anfragen an users-de-help@httpd.apache.org
> --------------------------------------------------------------------------
> 


--------------------------------------------------------------------------
                Apache HTTP Server Mailing List "users-de" 
      unsubscribe-Anfragen an users-de-unsubscribe@httpd.apache.org
           sonstige Anfragen an users-de-help@httpd.apache.org
--------------------------------------------------------------------------


Mime
View raw message