Enterprise Alert (EA) ist eine dreistufige Anwendung, die aus einer Datenbankschicht, einer Anwendungsschicht und einer Präsentationsschicht besteht.
Die Datenbankschicht ist durch Microsoft SQL Server geprägt. Zugehörige Executables können unter bestimmten Benutzer- oder Maschinenkonten laufen, je nach Szenario und Sicherheitsanforderungen. Die Kommunikation mit dieser Schicht von Komponenten in den anderen Schichten funktioniert über das TCP/IP-Protokoll und spezifische Authentifizierungsschemata für DMBS-Assets. Aufgrund dieser Schnittstelle zur Datenbankschicht ist es für die EA-Anwendungsintegrität relativ gleichgültig, unter welchem Benutzerkonto die DMBS-Executables ausgeführt werden.
Lokales Administratorkonto für EA-Executables erforderlich
Eine andere Situation findet sich in der Präsentations- und der Anwendungsschicht. Die Komponenten von Enterprise Alert in diesen Schichten müssen unter einem lokalen System oder einem lokalen Administratorkonto ausgeführt werden. Der Hauptgrund für diese Anforderung ist, dass eine schichten- und komponentenübergreifende Kommunikation von zusammengehörigen EA-Komponenten ermöglicht werden soll.
Beispiel, bei dem Admin-Rechte unerlässlich sind
Lassen Sie uns ein Beispiel illustrieren, bei dem die Präsentationsschicht mit einer Webserver-Komponente kommuniziert, die zur Anwendungsschicht gehört. Die Webanwendungen und Web-APIs von Enterprise Alert müssen die Konfiguration des IIS-Webservers abfragen, um registrierte virtuelle Pfadzuordnungen zu erhalten. Diese Konfigurations-Leseabfrage der Webanwendungen schlägt fehl, wenn das zugehörige IIS-Anwendungspool-Run-as-Konto nicht als lokales System oder als lokaler Administrator ausgeführt wird. Stattdessen wird ein Fehler wie dieser in der EA-Webportal-Protokolldatei angezeigt:
Exception Details: System.UnauthorizedAccessException: Dateiname: redirection.config
Fehler: Konfigurationsdatei kann aufgrund unzureichender Berechtigungen nicht gelesen werden
Der Vorschlag zur Lösung dieses Problems ist, die Anwendung einfach unter einem lokalen System oder einem Administratorkonto auszuführen.
https://forums.iis.net/t/1154515.aspx?ServerManager+UnauthorizedAccessException
Fazit
Das dargestellte Beispiel, bei dem die Kommunikation von der Präsentationsschicht mit der Anwendung fehlschlägt, wenn Enterprise Alert-Komponenten als lokaler Administrator ausgeführt werden, ist nur ein Beispiel.
Enterprise Alert verwendet mehrere andere Komponenten und Ressourcen auf dem Rechner, z. B. für die Interprozesskommunikation (MSMQ) oder den Zugriff auf das Dateisystem.
Diese Komponenten arbeiten am besten zusammen, wenn sie unter dem lokalen System oder einem lokalen Administratorkonto ausgeführt werden. Da die VM selbst ausschließlich für EA gehostet werden muss, hat die Feinabstimmung der Zugriffsberechtigungen auf Maschinenebene ohnehin nur begrenzten Nutzen.
Die Isolierung des Maschinenkontos des Computers, der EA in Ihrer Netzwerkdomäne hostet, wird jedoch dringend empfohlen, da mit der Windows-Authentifizierung jede Arbeitslast, die als lokaler Administrator oder lokales System auf der EA-Maschine ausgeführt wird, sich als DOMAIN\EAMACHINE$ in Ihrem Netzwerk authentifiziert.
Es wird z. B. dringend empfohlen, die Zugriffsrechte für dieses Konto auf Ihrem SQL Server zu beschränken.