Ldap Authentifizierung gegen Globalen Katalog

[Lörres 0]

Hallo zusammen,

 

ich bin neu hier, habe jedoch gleich ein nicht ganz triviales Anliegen. Ich habe in unserer Firma eine Forest Struktur mit zwei Standorten aufgebaut, da wir in einem Standort eine andere DNS Struktur haben, befinden sich nun zwei Domänen in diesem Forest.

Die Benutzer liegen dabei in einer Office-Domäne, sollen jedoch im anderen Standort zur Authentifizerung von Windows-Servern, Webapplikationen und Linux-Servern genutzt werden können. Für die Windows-Server ist das ohne größere Schwierigkeiten über die Vertrauensstellungen des Forests möglich.

 

Die Authentifizierung über Kerberos war für Team-Mitglieder und Vorgesetzte nicht gerne gesehen, da es das Konfiguratinsmanagement bei uns verkomplizieren würde. Für die Linux-Server und Webapplikationen habe ich angedacht die Authentifizierung gegen den globalen Katalog laufen zu lassen, da dieser Katalog, meiner Meinung nach, nix anderes als ein LDAP-Server mit ausgewählten Attributen aller Domänen ist. In meiner Testumgebung hat die Konstellation gut funktioniert.

 

In der aktuellen Pilotphase in der Produktionsumgebung habe ich jetzt allerdings das Problem, dass LDAP-Binds in manchen Fällen sehr lange brauchen. Ich habe den Traffic mal mitgesnifft und gesehen, dass zwischen LDAP bind requests und LDAP bind responses manchmal bis zu 40 Sekunden liegen.

 

Hat von euch jemand schon einmal Erfahrungen mit dieser Thematik gesammelt?

Persönlich halte ich es für ein Problem des Globalen Kataloges.. Ich habe zum Vergleich mal einfache ldapsearches gegen 389 und gegen 3268 ausgeführt und gesehen das die binds bisher nur bei 3268 (globaler Katalog) lange gedauert haben.

Ist der Globale Katalog evtl für LDAP-Authentifizierungen ungeeignet und wenn ja, wisst ihr warum? Kennt ihr evtl andere Lösungsansätze für mein Problem.. Ich denke hier sind wahre Experten gefragt ;-)

 

Viele Grüße

Lörres

[blub 115]

Ist der Globale Katalog evtl für LDAP-Authentifizierungen ungeeignet und wenn ja, wisst ihr warum? Kennt ihr evtl andere Lösungsansätze für mein Problem.. Ich denke hier sind wahre Experten gefragt ;-)

Tut mir leid, aber deinen Ausführungen kann ich vom ersten bis zum letzten Satz nicht folgen!

 

Jedenfalls

1) gibt es keine LDAP-Authentifizierungen

2) authentifiziert sich niemand gegen einen Global Catalog,

 

Es gibt z.B. eine Kerberos-, NTLM-, Digest, Schannel oder Simple-Bind- Authentifizierung. Im Trace müsstest du sehen, wie du authentifiziert bist.

Bist du z.B. gegen den KDC authentifiziert, kannst LDAP-Queries auf 389 oder 3268 ausführen.

 

Vielleicht lieg ich falsch, aber es hört sich jedenfalls so an, dass das Verständnis für  Forest, Domäne, LDAP, Global Catalog, Kerberos, Authentifizierung etc. bei euch nicht wirklich vorhanden ist.

 

blub

[Lörres 0]

Eine kurze recherche im Internet wird dir aufzeigen, dass es möglich ist, sich über Ldap zu authentifizieren (sogar das es eine grundlegende Funktionalität von Ldap ist). In meiner letzten Firma haben wir 30k user gegen ldap authentifiziert. Wenn du das geschriebene nicht verstehst, keine konkreten Lösungsvorschläge hast, oder nichts konstruktives beitragen willst, musst du nicht auf dieses Thema antworten. Das du niemanden kennst, der sich gegen einen gc authentifiziert, muss auch nicht bedeuten das es niemanden gibt der das evtl tut. Ich jedenfalls kann deine beiden aussagen durch einen gegenbeweis widerlegen...

Grüße lörres

[blub 115]

Gegen meine DCs (das sind natürlich GlobalCatalog Server) funktionieren jedenfalls LDAP-Queries auf allen Ports in Bruchteilen einer Sekunde, auch von Linuxrechnern außerhalb der Domäne.

[Dunkelmann 96]

Moin und lass mal etwas Dampf aus dem Kessel,

 

formal betrachtet, ist LDAP nur ein Anwendungsprotokoll. Mit Ausnahme von simple bind und sasl plain text gibt es im LDAP keine Authentifizierung.

Da weder das AD noch andere seriöse X.500 kompatible Verzeichnisdienste die Kennwörter in Plantext ablegen, wird immer ein zusätzlicher Authentifizierungsmechanismus benötigt.

 

Wenn Du aus einer 30k User Umgebung kommst und Probleme mit den Basics hast, würde ich mal über professionelle Hilfe nachdenken.

[Lörres 0]

Wenn Du aus einer 30k User Umgebung kommst und Probleme mit den Basics hast, würde ich mal über professionelle Hilfe nachdenken.

edit:

 

Das mein Fachwissen bezüglich Forests/GC noch ausbaubar ist, ist durchaus wahr, weshalb ich mich dazu durchgerungen habe nach "professioneller Hilfe" in einem "MCSE"-Board zu suchen.

 

Sowohl in der 30k Umgebung (openldap), als auch in der neuen Firma, verwenden wir Simple Bind über TLS.

Die Frage ist nun, gibt es noch jemanden der ähnliches schon einmal gegen den GC gemacht hat? Gibt es Gründe die dagegen sprechen? Denn technisch ist es möglich, allerdings habe ich wie gesagt in seltenen Fällen mit langen Antwortzeiten zu kämpfen. Die habe ich allerdings auch schon bei einfachen Ldapsearches.

bearbeitet 17. November 2016 von Lörres

[blub 115]

Ist der Globale Katalog evtl für LDAP-Authentifizierungen ungeeignet und wenn ja, wisst ihr warum?

Ich will dir ja helfen und die Antwort zumindest auf diese, deine letzte Frage kann nur sein

-schau dir an was ein GC ist

-schau dir an was LDAP ist

-schau dir an, was eine Authentifizierung ist

und dann wirst du auch herausfinden, warum deine Abfrage manchmal 40s dauert. Vielleicht liegts am DNS, am Signing, an der Abfrage selbst, an 100 anderen möglichen Ursachen

[daabm 1.366]

Sind es 40 Sekunden oder eher 30? Bei LDAPS fällt mir revocation checking ein, das hat nen Timeout in der Größenordnung

[blub 115]

Bei LDAPS fällt mir revocation checking ein, das hat nen Timeout in der Größenordnung

hast du dazu mal einen Link?

[Doso 77]

Bei uns sind alle DCs auch GC. Haben 2 Domänen im Forest. Wir haben einige Dienste die dann LDAP Auth per SSL machen gegenüber den FQDN der Domänen, was ja dann letztlich wieder die DCs sind. 60.000 Nutzer, so um die 2000-3500 Auths pro Tag. Verstehe nicht so recht was ihr hier mit dem GC vor habt und nicht direkt an die DCs ran geht.

[zahni 554]

Falls der Server via SSL ein Revocation-Check macht und dabei nicht ins Internet kommt, kann es eine Weile dauern. Grund kann ein versuchtes Update der Root-CAs bzw. deren CRLs sein.

Abhilfe schafft nur per GPO den  Revocation-Check abzustellen. 

[daabm 1.366]

hast du dazu mal einen Link?

Nö, das ist ja nicht LDAPS spezifisch, sondern allgemein bei Zertifikaten :-) Wenn die im Zertifikat angegebene CRL- oder OCSP-Adresse nicht erreichbar ist (weil z.B. per Firewall geblockt), dann rennt der Revocation Check in einen Timeout von 30 Sekunden.

 

Hatten wir mal beim IE, wo ein CA-Zertifikat (Infonotary) als CRL nicht http:// verwendet hat, sondern ldap:// - und das wurde natürlich nicht durchgelassen, sondern verworfen. Lösung war, die zu der ldap-Adresse gehörenden IPs in der lokalen Windows-Firewall zu blocken, dann geht's sofort.

[blub 115]

ja, das ist mir schon soweit klar.

Nur wo genau ein 30s Timeout steckt, hätte mich interessiert

 

Die CRL-Datei wird von einem CDP vor deren Ablauf lokal heruntergeladen. Entweder funktioniert die CRL-Aktualisierung und das Certificate kann verwendet werden, oder eben nicht.

Bei einem DC Server-Zertifikat sollte die CRL-Lebensdauer außerdem recht lange sein.

 

Der To ist wohl schon weg: Von LDAPS hatte er aber nichts geschrieben, sondern nur von "ldapsearches gegen 389 und gegen 3268"

[daabm 1.366]

Die CRL-Datei wird von einem CDP vor deren Ablauf lokal heruntergeladen. Entweder funktioniert die CRL-Aktualisierung und das Certificate kann verwendet werden, oder eben nicht.

 

Ja, und in unserem Fall war das eben keine Datei, sondern eine LDAP-URL. Der Timeout steckt irgendwo im Webzugriff, wenn der Request gedroppt wird, konnten wir im Trace gut sehen.

[NilsK 2.958]

Moin,

 

Nö, das ist ja nicht LDAPS spezifisch, sondern allgemein bei Zertifikaten :-) Wenn die im Zertifikat angegebene CRL- oder OCSP-Adresse nicht erreichbar ist (weil z.B. per Firewall geblockt), dann rennt der Revocation Check in einen Timeout von 30 Sekunden.

 

standardmäßig sind es 20 Sekunden - über alle verfügbaren Pfade. Dabei nutzt der Client die Hälfte der Zeit für den ersten Pfad und versucht erst dann den zweiten. Nach der Hälfte der verbleibenden Zeit den dritten usw. Wenn also erst am Ende ein erreichbarer Pfad steht, kann es sein, dass die Zeit nicht mehr für den Download reicht.

 

Die CRL-Pfade sind also auch eine wichtige Designfrage. Der erste sollte immer verfügbar sein.

 

Gruß, Nils