Müssen alle Dienste von ADCS unter demselben Dienstkonto auf demselben Server ausgeführt werden?

Müssen alle Dienste von ADCS unter demselben Dienstkonto auf demselben Server ausgeführt werden?

Beim Bereitstellen von ADCS empfiehlt Microsoft in der Dokumentation die Verwendung von Dienstkonten für die Dienste, aus denen ADCS besteht. Das Problem besteht darin, dass nicht darauf eingegangen wird, ob diese einzeln verwaltet werden sollten, ob sie einen Host gemeinsam nutzen könnten, noch wird der Verlust des Zugriffs von einem Remote-Server-Manager angesprochen, da eine Kerberos-Delegierung beteiligt ist.

Ich habe vor einiger Zeit gelernt, wie man das behebt, weil es das gleiche Problem ist, wennADFS*bereitgestellt wird: Die Kontrolle über den Computer wird vom Dienstkonto gestohlen, aber,wie du wahrscheinlich weißt,Es kann zurückgewonnen werden, indem einfach Active Directory-Aliase (CNAMEs) zum Computerkonto hinzugefügt werden. zB:

        …wenn die CA LOCKSMITH hieße

netdom computername locksmith /add:ceslocksmith.domain.tld
netdom computername locksmith /add:ceplocksmith.domain.tld
netdom computername locksmith /add:nedeslocksmith.domain.tld

        …oder vielleicht sogar Subdomains; (auf diese Idee bin ich noch nie gekommen)

netdom computername locksmith /add:ces.locksmith.domain.tld

Ich habe mich also gefragt,WennIch füge Aliase für jedes der Service-Konten hinzu, die ADCS möglicherweise verwendet (CES, CEP, NDES). Ich könnte jedes davon gemäß der Empfehlung ausführen, aber auf derselben Maschine —wahrscheinlich gegen bewährte Methoden, aber wissen Sie— außer dass ich dieses Ding in einem Forum gefunden habe, wo es hieß, dassmehrere Instanzen von CES(ich nehme an, in einer Farm) sollten alle mit demdasselbe Dienstkonto. Die anderen Dienste wurden nicht erwähnt. Aber sollten sie auch dasselbe Dienstkonto teilen, oder ist es OK für einzelne Dienstegebunden an eineeinzelUnternehmenszertifizierungsstellesoll jeder es unter seinem eigenen Servicekonto ausführen?

Danke.


*: eigentlich ist es für ADFS schlimmer, weil die Dokumentation seit mehreren Jahren fälschlicherweise darauf hinweist, dass das falsche Kerberos verwendet wird service/PRINCIPAL. Es wird hostanstelle des httpDienstes angegeben. Die Kontrolle überhttpzu einem Konto sperrt Sie höchstens aus der Remote-Administration/PowerShell-Remoting, aber wenn Sie die Kontrolle über den Host vom Konto der Maschine weggeben, bleibt er von der Domäne verwaist. Schlimmer noch ist, dass dies wörtlich wiederholt wird vonBester Spielers und andere in ihren eigenen Blogs.

Antwort1

Angesichts der Zeitverzögerung und der fehlenden vollständigen Antwort ist dies jetzt wahrscheinlich irrelevant, aber los geht’s:

Der NDES-Connector (für SCEP) sollte nicht auf einem ausstellenden CA-Server installiert werden, daher ist das nicht relevant. Er sollte als eigenes Dienstkonto mit den entsprechenden an die CA delegierten Rechten zum Ausstellen von Zertifikaten sowie den anderen Anforderungen ausgeführt werden.die Dokumentation.

Für CES/CEP installieren Sie diese nur bei Bedarf - z. B. für domänenübergreifende oder nicht domänengebundene Maschinen/externe Benutzerzertifikatsregistrierungen. Persönlich bin ich zufriedener, wenn sie nicht auf dem CA-Server sind, aber SiedürfenStellen Sie sie dort bereit. Standardmäßig verwenden sie die Anwendungspoolidentität für den Webdienst, aber Sie können (und sollten) dies in ein Domänenbenutzerkonto ändern. Beachten Sie auch, dass Sie zum Ausführen der Dienste ein (g)MSA verwenden können.Diese Dokumentationist zwar recht alt, aber immer noch das vollständigste.

In der Dokumentation wird darauf hingewiesen, dass bei der Installation von CES/CEP auf der CA das folgende Problem auftreten kann. Aus diesem Grund würde ich diese Dienste persönlich woanders ausführen.Wennsie sind erforderlich.

Wenn andere Kerberos-authentifizierte http/https-Dienste auf demselben Host ausgeführt werden wie ein Certificate Enrollment Policy Web Service oder ein Certificate Enrollment Web Service, der für die Kerberos-Authentifizierung konfiguriert ist, können Registrierungsfehler aufgrund einer SPN-Kollision auftreten. Die Lösung besteht darin, alle Dienste so zu konfigurieren, dass sie unter demselben Benutzerkonto ausgeführt werden.

Schließlich ist es nicht klar, welche Dokumentation Sie befolgen oder welche Version von ADCS Sie bereitstellen, aber denken Sie daran, die CA-Server gegen NTLM-Relay-Angriffe zu sichern, perKB5005413. Idealerweise bedeutet dies, die NTLM-Authentifizierung auf den Domänencontrollern (in den meisten Unternehmensumgebungen ziemlich schwierig) oder alternativ auf jedem CS-Server (d. h. CA- oder CES-Servern) zu deaktivieren. Die minimalen Problemumgehungen bestehen darin, https zu erfordern und Extended Protection for Authentication (EPA) auf den Registrierungs-Webdiensten zu konfigurieren.

verwandte Informationen