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 Tue, 09 Nov 2004 18:02:07 GMT
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" <Thorsten.Goellner@Q1AG.de>
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" <rglauberman@michaeli-gymnasium.de>
> 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" <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
> --------------------------------------------------------------------------
>
>
>
> --------------------------------------------------------------------------
>                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