Vielen Dank für die Betrachtung: Hoffentlich hilft das nicht nur anderen später, sondern hilft uns jetzt! (und bitte sei sanft, das ist meine erste Frage zu Stack, obwohl ich lange Zeit Benutzer / Mitwirkender war)
Situation (SNAFU) Eine AD Site-aware-Anwendung zieht einige Informationen aus AD heraus. Diese Anwendung darf nur Verbindungen zu Controllern innerhalb des Active Directory-Standorts herstellen, auf dem der Server gehostet wird. Wenn keine Controller für diese Site gefunden werden, haben wir größere Probleme, aber Code wird diese Möglichkeit handhaben.
Um dies zu erreichen, beabsichtigen wir:
Also der PSEDUO-Code:
%Vor%, um den Namen der Site zu erhalten, auf der sich der Server befindet ... und dann durchschleifen
System.DirectoryServices.ActiveDirectory.DirectoryServices.ActiveDirectorySite
, bis wir eine Website gefunden haben, die dem erworbenen Namen entspricht. Jetzt, wo wir diese Sammlung haben, können wir einen bestimmten Server von der Server-Eigenschaft anfordern. schließlich mit dem Server, fordern Sie die benötigten AD Informationen.
DAS PROBLEM:
Der erste Schritt GetComputerSite().Name gibt einen Fehler zurück: ActiveDirectoryObjectNotFoundException
In unserer Entwicklungsumgebung hat das gut funktioniert. In unserer Produktionsumgebung würde es nicht.
Wir haben überprüft, dass der Server in der Domäne war und eine Website durch Überprüfung der in diesen anderen Stack-Artikel
Mehr Forschung führt uns zu einem technet-Artikel beschreibt ein ähnliches Problem. Wir haben das erwähnte Powershell-Skript verwendet, um zu sehen, was von unserem Webserver passieren würde:
[System.DirectoryServices.ActiveDirectory.ActiveDirectorySite]::GetComputerSite() es gab Server und die Liste von 8 Controllern zurück, die wir finden sollten; zusammen mit dem richtigen Site-Namen; wie in der Registrierung.
Dies führte uns zu Berechtigungsunterschieden zwischen dem Standardanwendungspool NetworkServices vs ApplicationPoolIdentity. Wie wir an dieser Stelle wussten, konnte der Webserver die Site und die Server sehen ... warum konnte die Webanwendung nicht?
Wir haben festgestellt, dass die Site durch den Wechsel von ApplicationPoolIdentity zu NetWorkServices wieder funktioniert (dies war das Entwicklungssetup und erklärt, warum die Dev-Funktion funktionierte, aber die Produktion nicht. Allerdings ist dies nicht mehr die Standardkonfiguration von IIS 7.5 (ApplicationPoolIdentity) ) und wir haben die Tendenz, zu versuchen, mit den Standardwerten zu bleiben, da Patches manchmal die Einstellungen zurück auf die Standardwerte zurücksetzen. Wir wollten eine robustere Langzeitantwort finden, die näher an der MSFT-Richtung ausgerichtet ist.
Die Frage (n):
Gibt es eine bessere Methode, um einen aktiven / responsiven Controller innerhalb der Server-Site zu erreichen und Zugriff auf die Informationen der Benutzerabteilung zu erhalten?
Welche Berechtigungen müssen ApplicationPoolIdentity hinzugefügt werden, damit dieser Anwendung Zugriff auf AD-Dienste gewährt wird?
Zusätzliche relevante Artikel
Leider haben wir bisher nur gefunden, dass wir Berechtigungen zum Anzeigen von Ordnern / Dateisystemen einrichten, aber nicht die AD-Server verwenden (oder müssen wir den Zugriff auf einen bestimmten Ordner gewähren, der die DLLs für die AD-Klassen enthält) benutzt?
Aktualisierung: Wir dachten, den Fehler gegeben, dass das Problem möglicherweise mit ApplicationPoolIdentity nicht Zugriff auf die System.DirectoryServices.dll residieren, so dass wir explizit Berechtigungen erteilt haben
%Vor%Es hat angefangen zu arbeiten !!!
Wir konnten es nicht glauben, also haben wir die Änderung rückgängig gemacht ... und IIS neu gestartet .... und es funktionierte immer noch ....
So scheint es, dass es sich magisch fixierte. wir haben sogar in der Produktion versucht, indem wir einfach von NetworkServices zu ApplicationPoolIdenity gewechselt haben und alles hat wieder funktioniert ... Wir sind ratlos, haben aber keine weiteren Fäden mehr für die Untersuchung. Wir werden vorerst überwachen und hoffen, dass das Problem nicht zurückkommt ... Nicht die beste Herangehensweise, aber da wir das Problem nicht so wie früher reproduzieren können, wissen wir nicht, was wir noch versuchen sollten.
Vorletzte Aktualisierung Wir haben festgestellt, dass die in IIS-Anwendung, die die Anwendungspoolidentität verwendet, referenzierte KB verliert primäres Token? war tatsächlich das Problem. Wir
Unsere nächsten Schritte bestehen darin, ähnliche Schritte durchzuführen, um zu bestätigen, dass der Hotfix das Problem tatsächlich korrigiert. Wir werden: .
Wenn alle Sites betriebsbereit sind, gehen wir davon aus, dass der Hotfix das getan hat, was er benötigt. Zu diesem Zeitpunkt scheint dies für das Gewinnen von 2008 Maschinen auf Service Pack 1 zu gelten.
Also für andere, die ein Problem haben und zu ApplicationPoolIdentity vs NetworkServices wechseln möchten ... Wenn Sie einen Server 2008 auf Service Pack 1 verwenden .... Ich verweise Sie auf Folgendes: IIS-Anwendung mit Anwendungspool-Identität verliert primäre Token? Frage. Gib der Antwort hier Kredit ... Es half uns!
Das Patch hat sich auch nach einem automatischen 30-Tage-Zyklus von Kontokorrentpasswörtern bewährt. Markierungsproblem geschlossen.
Ursache:
MSFT Bug im Anwendungspool Identität, wenn Active Directory vom Web innerhalb von 30 Tagen referenziert wird und 30 Tage später auf Windows 2008. (Standardeinstellungen vorausgesetzt)
Temporäre Arbeit (en):
FIX:
Tags und Links iis-7.5 .net active-directory directoryservices application-pool