Erstellen eines Python-Dienstes zum Abfragen von AD-Attributen
Ich integriere unser AD in Webdienste, auf denen Python unter Linux ausgeführt wird, und verwende Python-LDAP über SASL (DIGEST-MD5), um AD 2012-Benutzerattribute (Abteilung, Abteilung, Telefonerweiterung, E-Mail usw.) abzufragen. Nachdem ich die für meinen Dienst spezifischen Probleme mit einem AD 2003 behoben hatte, trat bei unserem neuen AD 2012 ein SPN-Fehler auf, bei dem der Digest-Uri nicht mit den SPNs auf dem Server übereinstimmte. Ich habe die SPN-Liste für beide Server referenziert und sie enthalten identische Analoga voneinander.
Der Fehler: Die Digest-URL entspricht nicht den für diesen Server registrierten LDAP-SPNs
Die Reparatur?
Dies wurde behoben durch Ausführen von:
setspn -A ldap/<Domain_Name> <Computer_Name>
Beachten Sie, dass das Erstellen eines Dienstkontos meinen SPN-Fehler nicht behoben hat, selbst wenn der folgende Befehl ausgeführt wurde:
setspn -A ldap/<Domain_Name> <Domain_Name>/<Service_Account_Name>
simple_bind_s () benötigt keinen SPN, sasl_interactive_bind_s () benötigt SPN
Nur das Hinzufügen des SPN zur SPN-Liste des lokalen Computers funktionierte für meinen Python-LDAP-Dienst mit sasl_interactive_bind_s (). Ich sollte auch beachten, dass der SPN-Schritt übersprungen werden kann, wenn ich simple_bind_s () verwende, diese Methode jedoch Anmeldeinformationen im Klartext sendet, was nicht akzeptabel ist.
Ich habe jedoch festgestellt, dass der Datensatz nur etwa eine Minute auf der SPN-Liste bleibt, bevor er verschwindet. Es gibt keine Fehler, wenn ich den Befehl setspn ausführe, die Ereignisprotokolle sind vollständig leer, es gibt nirgendwo Duplikate, die mit der Wald-weiten Suche auf der Basis dn überprüft wurden und nichts. Ich habe den SPN hinzugefügt und versucht, ihn erneut hinzuzufügen, zu entfernen und von Objekt zu Objekt zu verschieben, um sicherzustellen, dass er sich nirgendwo versteckt. In der Sekunde, in der ich das Objekt irgendwo hinzufüge und dann versuche, es erneut hinzuzufügen, werde ich über ein Duplikat informiert. Ich bin also sehr zuversichtlich, dass irgendwo kein Duplikat versteckt ist.
Der Hack
Im Moment habe ich eine geplante Aufgabe, die den Befehl erneut ausführt, um die Aufzeichnung in der Liste zu halten, damit mein Dienst mit dem passenden Namen "SPN Hack" funktioniert.
cmd.exe /C "setspn -A ldap/<Domain_Name> <Computer_Name>"
bis ich herausfinden kann, warum der SPN von der Liste gestrichen wird.
Ich bin nicht der Hauptadministrator für diese bestimmte AD. Könnte der Administrator einen Dienst ausführen, der den SPN von einem anderen Dienst auf der AD synchronisiert, und sich dessen nicht bewusst sein? Mein Titel ist Web Developer, nicht als Entschuldigung, sondern um meine Unwissenheit über Active Directory zu erklären. Mir wurde gesagt, dass ich die AD zur Hauptbenutzer-Datenbank machen soll, und ich habe viel gelesen, aber ich kann nirgendwo finden, wo Leute ein Problem damit haben, dass der SPN regelmäßig "überschrieben" oder "bereinigt" wird und keiner der Administratoren sind mit SPN außerhalb von SQLServer-Einträgen sehr vertraut.
Warum brauche ich den Hack?
Bisher scheint mein Hack keine Probleme für Benutzer oder Dienste verursacht zu haben und hat keine Fehler generiert. Der Administrator sagt also, er lasse es einfach laufen und ich werde weiter suchen. Aber dann befinde ich mich in der prekären Situation, einen Dienst zu schreiben, auf dessen Implementierung aufgebaut ist, im Wesentlichen ein Cron-Hack / Shiver ... Also wäre jede Hilfe dankbar.
Aktualisieren
Nach einem Gespräch mit dem Systemadministrator hat er zugestimmt, dass das Erstellen eines Dienstes auf einem Hack keine Lösung darstellt. Daher hat er mir die Erlaubnis erteilt, einen lokalen Dienst mit Endpunktverschlüsselung zu starten, den ich für meine Zwecke verwenden kann. Das Ergebnis ist dasselbe . Ich werde ein Auge darauf werfen, was dazu führt, dass der SPN gelöscht wird. Lokale Bindungen sind mit Python-LDAP kein Problem, und der lokale Dienst ist bereits nach etwa einer Stunde betriebsbereit. Es ist bedauerlich, dass ich im Wesentlichen Funktionen einbinde, die in LDAP integriert sind, aber wir tun, was wir tun müssen.
