.NET-LDAP-Bibliotheken mit NTLM-Unterstützung

Ich versuche, Microsoft DirectorySearcher in meiner Anwendung zu ersetzen, hauptsächlich weil es in unserem Anwendungsfall wirklich langsam ist (wenn ich nach einem einzelnen Benutzerkonto suche, um seinen givenName, sn und objectGUID verwendet den sAMAccountName als Filter, es dauert etwa 400 ms pro Benutzer, in einigen Fällen muss ich es für viele Benutzer bekommen)..NET-LDAP-Bibliotheken mit NTLM-Unterstützung

So versuchte ich Novell LDAP, sowohl die ursprüngliche Version als auch die .NET Standard. Leistung für das Original ist gut, aber .NET Standard ist noch besser. Der gleiche Fall, in dem Microsoft 400ms benötigt, dauert 3ms. So weit, ist es gut.

Um schnell zu diesem Punkt zu gelangen, habe ich meine Domain-Anmeldedaten fest programmiert. Jetzt, da ich versuche, die Implementierung von Microsoft in unserer Anwendung zu ersetzen, wurde mir klar, dass wir die NTLM-Authentifizierung verwenden, und ich möchte, dass diese Änderung für meine Benutzer transparent ist (sie müssen sie nicht nach ihren Domänenanmeldeinformationen fragen).

Mit Blick auf die Protokolldetails, LDAP-Aufrufe mit Wireshark und Novells Quellcode erkannte ich schnell, dass es etwas ist, das sie nicht implementiert haben. Also, ich bin wieder auf Platz eins ...

Ich brauche eine schnelle LDAP-Bibliothek, die NTLM (sasl gss-spnego) authentifizieren (binden) kann.

Gibt es so etwas? Ich habe nuGet gesucht und google gefragt, aber nicht viel gefunden.

Danke!

Quelle

2017-09-08 Cral DasProblem

In meiner Erfahrung ist DirectorySearcher die schnellste Option. Verwenden Sie [die Überladung, mit der Sie einschränken können, welche Eigenschaften geladen werden] (https://msdn.microsoft.com/en-us/library/1z8b03h0 (v = vs.110) .aspx)? Ich habe bemerkt, dass das einen wesentlichen Unterschied machen kann. – itsme86

Ja, ich habe nur die Eigenschaften geladen, die ich brauchte. Mein Problem endete mit der Verhandlung zwischen meinem Client und meinem Test Domain Controller/Active Directory. Jemand schlug vor, dass ich die gleichen Anmeldeinformationen von meiner echten Domäne auf meiner Testdomäne verwende, um zu vermeiden, dass ich mich wirklich anmelden muss ... und das war ein Fehler und war die Ursache für die Verlangsamung der NTLM-Authentifizierung. Ich konnte dieses Problem nicht replizieren, wenn es ordnungsgemäß in unserer Produktionsdomäne/activedirectory protokolliert wurde. In diesem Fall gab es keinen merklichen Unterschied zwischen einfacher Authentifizierung und NTLM. –

Wenn Sie SASL mit NTLM verwenden, werden Sie wahrscheinlich eine Langsamkeit mit einer LDAP-Lib feststellen.

Die einfache Bindung bedeutet, dass Sie nach dem TCP-Dreiweg-Handshake in einer Anfrage autorisiert sind. Unabhängig von der Lib, mit SASL und NTLM, haben Sie noch drei weitere Nachrichten, bevor Sie Ihre Suchanfrage senden können.

Ich habe festgestellt, dass der Namespace MS system.directoryservices.protocols eine sehr schnelle LDAP-Client-Bibliothek ist. Abhängig von Ihrem Anwendungsfall können Sie viele Optimierungen vornehmen. https://msdn.microsoft.com/en-us/library/ms808539.aspx

Ich würde Theitsme86 auf dem Verzeichnis Sucher bestreiten. Es verwendet ADSI, was bedeutet, dass es zuerst auf die LDAP-Clientseite konvertieren muss. Mit S.DS.P können Sie reines LDAP erstellen.

Quelle

2017-09-10 19:08:09 markgamache

Interessant. Ich werde weiter untersuchen und sehen, ob der Verlust von NTLM insgesamt einen signifikanten Unterschied macht. Wird nachher berichten :) Danke! –

Update: Nun, sieht aus wie ich suchte nach einer Lösung für das falsche Problem. Die 400ms/user, die ich bekam, ist nur auf meinem Test ActiveDirectory/Domain (unter einer VM). Ich machte eine Benchmark-Anwendung mit Anrufen mit S.DS, S.DS.P, Novell, Novell NET Standard ... der, der am besten mit der Leistung endete (zu meiner Überraschung) war S.DS ... ich entschied auch Um die Art und Weise zu ändern, wie ich meine Daten von mehreren Anrufen zu einem einzigen größeren Anruf abrufe, kann ich jetzt alle gewünschten Informationen in weniger als einer Millisekunde pro Benutzer abrufen (2280 Millisekunden für 3117 Benutzer). Danke, dass Sie mich auf den richtigen Weg gebracht haben! –

Wenn Sie das Testen Ihrer Perfusion sehr ernst nehmen, sollten Sie den AD zwischen den Tests neu starten. Es ist ein Champion beim Zwischenspeichern häufig verwendeter Teile des Verzeichnisses. – markgamache

.NET-LDAP-Bibliotheken mit NTLM-Unterstützung

Antwort

Verwandte Themen