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 17:02:58 GMT
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
--------------------------------------------------------------------------


Mime
View raw message