Auswahl der Identität für den IIS Anwendungspool des Registrierungsdienstes für Netzwerkgeräte (NDES)

Installiert man einen Registrierungsdienst für Netzwerkgeräte (NDES), steht man vor der Frage, unter welcher Identität der IIS-Anwendungspool betrieben werden soll. Nachfolgend werden die einzelnen Optionen näher beleuchtet, um eine Auswahl zu erleichtern.

Der Registrierungsdienst für Netzwerkgeräte (Network Device Enrollment Service, NDES) bietet eine Möglichkeit, Geräten, welche nicht über eine Kennung im Active Directory verfügen (beispielsweise Netzwerkgeräte wie Router, Switches, Drucker, Thin Clients oder Smartphones und Tablets), Zertifikate von einer Zertifizierungsstelle zu beantragen. Für eine detailliertere Beschreibung siehe Artikel "Grundlagen Registrierungsdienst für Netzwerkgeräte (Network Device Enrollment Service, NDES)".

Annahmen

Bei der Entscheidungsfindung gehen wir von folgenden Rahmenbedingungen aus:

NDES wird auf einem separaten Server installiert (nicht zusammen mit einer Zertifizierungsstelle oder anderen Rollen auf dem gleichen Server).
Es werden keine weiteren Rollen auf dem NDES Server installiert.
Es ist möglich, dass es mehrere Zertifizierungsstellen im Netzwerk gibt, an die verschiedene NDES-Server angebunden werden.

Die Möglichkeiten

Insgesamt gibt es drei Möglichkeiten, wie der IIS Anwendungspool konfiguriert werden kann.

Verwenden der IIS Anwendungspool-Identität
Verwenden eines Domänenkontos
Verwenden eines Group managed Service Account (gMSA)

Details: IIS Anwendungspool

Die Verwendung des IIS Anwendungspools hat folgende Vorteile:

Es ist praktisch keine Konfiguration zur Einrichtung erforderlich.
Es muss keine regelmäßige Passwortänderung vorgenommen werden, da sich das Passwort des zugrundeliegenden Computerkontos automatisch erneuert. Somit sind Angriffe wie Kerberoasting von vornherein ausgeschlossen.
Es ist eine Kerberos-Authentisierung gegenüber dem vollqualifizierten Hostnamen des NDES-Servers möglich. Wird kein Alias verwendet, muss auch kein Dienstprinzipalname verwendet werden.

Für NDES wird die Verwendung der IIS Anwendungspool-Identität nach offizieller Lesart von Microsoft allerdings nicht empfohlen. Warum dies in der Praxis aber unproblematisch ist wird nachfolgend geklärt.

However, the recommended configuration is to specify a user account, which requires additional configuration
Network Device Enrollment Service Guidance (Microsoft Corporation)

Die gleiche Aussage macht der Konfigurationssassistent für die NDES-Rolle:

Im Gegenzug empfiehlt die IIS Verwaltungskonsole jedoch explizit die Verwendung des IIS Anwendungspools. Was stimmt also?

Die Empfehlung, für NDES nicht die IIS Anwendungspool-Identität zu verwenden, ist dadurch begründet, dass andere eventuell auf dem gleichen Server vorhandene Anwendungspools, die auch die jeweilige Identität des Anwendungspools verwenden, bei Zugriff auf andere Hosts (d.h. im konkreten NDES-Fall die verbundene Zertifizierungsstelle) auch auf das Computerkonto zurückfallen würden und dadurch entsprechend zur Zertifikatbeantragung berechtigt wären. Somit wären andere IIS Anwendungspools, die auf dem gleichen Server laufen, ebenfalls für die Zertifikatbeantragung für die konfigurierte Gerätevorlage berechtigt.

Die Verwendung der IIS-Anwendungspool-Identität ist in erster Linie für die Isolation verschiedener Anwendungen auf dem lokalen Host gedacht. Da es empfohlen ist, NDES abseits der Zertifizierungsstelle und ohne andere Rollen auf einem dedizierten Server zu installieren, spielt dieser Aspekt in der Praxis jedoch keine Rolle. Abgesehen davon wird empfohlen, die Gerätevorlage entsprechend zu konfigurieren, nur Zertifkatanforderungen zu akzeptieren, die mit dem entsprechenden Registration Authority Zertifikat signiert wurden (auf dessen privaten Schlüssel hat bei korrekter Konfiguration wiederum nur die Identität des "SCEP" Anwendungspools Zugriff).

Clustering ist unter Verwendung der IIS Anwendungspool-Identität nicht möglich. Da NDES aber ohnehin kein Clustering unterstützt, ist dies in der Praxis ebenfalls nicht relevant.

Ein eventueller, wenn auch geringer, Nachteil kann sein, dass das Computerkonto des NDES-Servers auf den Geräte-Zertifikatvorlagen für die Zertifikatbeantragung berechtigt werden muss. Entsprechend verursacht eine eventuelle Neuinstallation oder ein Umzug der NDES Rolle auf einen anderen Server den Bedarf, den neuen Server auf der Geräte-Vorlage wieder zu berechtigen, was bei den beiden anderen Optionen nicht notwendig wäre.

Der IIS Anwendungspool muss per Script auf die privaten Schlüssel der Registration Authority Zertifikate berechtigt werden, was bei den beiden anderen Optionen nicht nötig ist (dort kann es über Zertifikatvorlagen gesteuert werden). Somit ist keine automatische Beantragung und Erneuerung der RA Zertifikate mir Bordmitteln (Autoenrollment) möglich. Da nach der Zertifikaterneuerung aber ohnehin der NDES-Dienst neu gestartet werden muss, spielt dies in der Praxis keine Rolle. Ebenso ist es mit Bordmitteln nicht möglich, die Registration Authority Zertifikate gezielt von der richtigen Zertifizierungsstelle zu beziehen, da die Auswahl per Zufallsprinzip erfolgt, wenn es mehrere Zertifizierungsstellen mit angebundenen SCEP-Servern in der Umgebung gibt. Beide Aufgaben können aber durch ein Script, das regelmäßig ausgeführt wird, automatisiert werden.

Details: Domänenkonto

Ein Domänenkonto muss aktiv verwaltet werden, sprich das das Passwort muss regelmäßig gewechselt werden. Damit die Kerberos Authentisierung funktioniert, muss ein Dienstprinzipalname (engl. Service Principal Name, SPN) registriert werden, der wiederum Kerberoasting ermöglichen kann.

Clustering ist mit Domänenkonten zwar möglich, wird von NDES aber ohnehin nicht unterstützt.

Ein Domänenkonto kann dazu verleiten, auf mehreren NDES-Servern das gleiche Dienstkonto zu hinterlegen, was wiederum die Gesamt-Sicherheit reduzieren kann.

Es gibt allerdings Fälle, welche ein Domänenkonto für NDES zwingend erfordern. Beispielsweise funktioniert der Connector für Microsoft Intune nur, wenn NDES ein Domänenkonto verwendet.

Details: Group-managed Service Account (gMSA)

gMSA haben wir die integrierte Anwendungspool-Identität den Vorteil, dass keine regelmäßige manuelle Passwortänderung erforderlich ist. Der gMSA verwaltet sein Kennwort automatisch. Somit sind Angriffe wie Kerberoasting von vornherein ausgeschlossen.

Clustering ist mit einem gMSA zwar möglich, wird von NDES aber ohnehin nicht unterstützt.

Sofern NDES in Verbindung mit Microsoft Intune verwendet wird, wird die Verwendung eines gMSA allerdings nicht unterstützt.

While the NDES role can be configured to run using a GMSA, the Intune Certificate Connector was not designed nor tested using a GMSA and is considered an unsupported configuration.

Fazit

An wenigsten Einrichtungs- und Betriebsaufwand verursacht die Verwendung der IIS-Anwendungspool-Identität für NDES. Dann sollten aber keine anderen Rollen und Dienste auf dem SCEP-Server betrieben werden.

Die "optimalste" Option ist der Group-managed Service Account, zieht allerdings auch den größten Einrichtungsaufwand nach sich und ist nicht in allen Fällen verwendbar.

Weiterführende Links:

Externe Quellen

Network Device Enrollment Service Guidance (Microsoft Corporation)
Application Pool Identities (Microsoft Corporation)
Understanding identities in IIS (Microsoft Corporation)
Service Accounts Step-by-Step Guide (Microsoft Corporation)
New in IIS 7 – App Pool Isolation (Ken Schaefer)