You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users-de@httpd.apache.org by Boris Glawe <bo...@boris-glawe.de> on 2005/05/24 23:58:06 UTC

Authentifizierung bei ADS mit sehr großer Benutzerdatenbank

Hallo,

wir haben einen ADS mit einem Umfang von mehreren tausend 
Benutzern/Einträgen.

Ich versuche nun unter Linux einen Apache aufzusetzen, der sich bei 
diesem ADS authentifiziert. Genauer: es soll ein Subversionserver sein, 
der über WebDAV/Apache/mod_dav_svn den Zugriff auf Repositories erlaubt.

Es müssen grundsätzlich alle Benutzer die Möglichkeit haben, sich zu 
authentifizieren. Wer auf ein bestimmtes Repository, also ein bestimmtes 
Verzeichnis zugreifen darf, bestimmt deren Gruppenzugehörigkeit.

Dazu muss ich (korrigiert mich, wenn ihr andere Vorschläge habt)

- als AuthLDAPUrl den Knoten angeben, der alle Benutzer unter sich hat
- die Direktive "require group" auf den DN der Gruppe setzen.

Jetzt passiert folgendes: Setze ich die AuthLDAPUrl auf einen Teilbaum, 
der nur ca. 45 Einträge hat, dann funktioniert alles, wie es soll.
Setze ich diese Direktive wieder auf die "Wurzel", dann klappt nichts mehr.

Ich habe mit dem Tool ldapsearch, welches mit openldap mitgeliefert 
wird, einfach mal eine Suche ohne Filter auf der "Wurzel" des 
Verzeichnisses gestartet. Das auffällige ist, dass genau 1000 Einträge 
geliefert werden - der Server schneidet also nach 1000 Einträgen ab.
(siehe auch: 
http://support.microsoft.com/default.aspx?scid=kb;en-us;315071&sd=tech#XSLTH3129121122120121120120
unter den Stichwort "maxPageSize")

Es ist sehr wahrscheinlich, dass hier die Ursache für unser Problem zu 
suchen ist. Allerdings finde ich nirgendwo eine Lösung zu unserem Problem.


Ich habe versucht, mit der Direktive

require ldap-attribute memberOf="CN=testgroup,OU=test,DC=ourdomain,DC=de"

den Umfang der Ergebnisse einzuschränken, aber leider nicht mit Erfolg. 
Mache ich dasselbe mit ldapsearch werden zwar nur noch wenige Einträge 
geliefert, aber apache verweigert mit dem diesem Ansatz die 
Authentifzierung (wobei ich hier nicht weiß, warum und auch nicht weiß, 
wie apache diese Direktive in eine Suchabfrage übersetzt).

Der Vollständigkeit halber hier die Fehlermeldung, wie sie in 
/var/log/httpd/ssl_error_log zu finden ist (privates ausgestrichen):

[Tue May 24 23:12:37 2005] [warn] [client xxx.xxx.xxx.xxx] [25000] 
auth_ldap authenticate: user testuser authentication failed; URI 
/xxxxx/xxxxx [ldap_search_ext_s() for user failed][Operations error]

Eine Lösung wäre, die maximale Anzahl an Antworten hochzusetzen, da aber 
unser Verzeichnis weit mehr als 1000 Einträge hat, ist das nicht 
unbedingt das gelbe vom Ei.

Ich bin sehr dankbar für jeden Hinweis und jede Idee, die ihr habt !!

Viele Grüße

Boris


--------------------------------------------------------------------------
                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
--------------------------------------------------------------------------


Re: Authentifizierung bei ADS mit sehr großer Benutzerdatenbank

Posted by Boris Glawe <bo...@boris-glawe.de>.
Ich habe mit Ethereal mal ein wenig den Netzwerkverkehr untersucht: Der 
Suchfilter, der von Apache an den ADS geschickt wird, ist 
(&(objectClass=*)(sAMAccountName=testuser))

Das das Attribut sAMAccountName eigentlich mit einem eindeutigen Wert 
belegt sein sollte, dürfte entweder nur genau ein oder kein Ergebnis 
geliefert werden. Demnach ist meine Theorie mit dem zu langen 
Suchergebnis falsch!

Der Server meldet eine "Operations Error", wie man es auch in der log 
Datei des Apache sehen kann. Was ist das? Wo kann ich weitersuchen?

Vielen Dank schon mal

Boris

--------------------------------------------------------------------------
                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
--------------------------------------------------------------------------