Windows AD Certificate Authority – Cross Forest Deployment
Templates anpassen
Damit wir auf den Account-Forests auch Zertifikate anfordern können, müssen die Templates innerhalb der Certificate Authority an unsere Bedürfnisse angepasst werden. Da man hierbei keine allgemeingültige Aussage treffen kann, versuche ich das Vorgehen exemplarisch anhand eines Beispiels zu erklären.
Mein Server „account-client01“ hostet einen Webserver. Dieser Webserver soll innerhalb der Organisationen auch via SSL und somit HTTPs erreichbar sein. Dafür benötigt die Website allerdings auch ein Zertifikat und ein solches wollen wir von unserer Enterprise CA erstellen.
Dazu wechseln wir in der „Certificate Authority“ MMC und managen die Templates.
Je nach Anforderung erstellen wir eine Kopie eines bereits existierenden Templates. In unserem Fall nehme ich das Web Server Template als Referenz.
Hier können alle nötigen Einstellungen angepasst werden. Für mich wäre in erster Linie der Name und das Veröffentlichen im AD relevant. Alle weiteren Settings belasse ich auf den Standardwerten.
Nun müssen wir nur noch den jeweiligen Objekten oder auch Gruppen vom Account-Forest Zugriff auf das Template geben. Da ich in Zukunft auf eine automatisiertes Enrollment setzen möchte, verteile ich auch die Berechtigung „Autoenroll“.
Abschließend muss das zuvor erstellte Template auch noch zu den veröffentlichten Templates hinzugefügt werden.
Nachdem eine Änderung bei den Templates durchgeführt wurde, müssen wir diese auch wieder auf die Account Forests synchronisieren. Dafür verwenden wir erneut den folgenden Befehl am „account-dc01„:
.\PKISync.ps1 -f -Sourceforest resource.local -Targetforest account.forest
Zertifikat am Client anfordern
Am Client können wir nun das neue Zertifikat über das Zertifikats Snap-In anfordern.
Zuerst öffnen wir eine MMC und fügen darüber über das Menü das „Certificate“ Snap-In hinzu. Wichtig ist dabei, dass man das Snap-In mit dem Computer-Account öffnet.
Nachdem das Snap-In geladen wurde, kann über den Personal Store ein neues Zertifikat über das Active Directory bezogen werden. Dabei greift der Client via LDAP auf die Enterprise CA zu und generiert das entsprechende Zertifikat.
Abschließend sieht man das erfolgreich ausgestellte Zertifikat und kann es nun beispielsweise im IIS hinterlegen.
Fazit und abschließende Hinweise
Der Aufbau mag auf den ersten Blick etwas umständlich sein, wenn man die Situation allerdings näher betrachtet, kann man die ein oder anderen Vorteile daraus beziehen. Beispielsweise muss in diesem Fall nicht für jeden Forest eine eigene CA verwalten werden, sondern man besitzt nur eine zentrale Zertifizierungshierarchie. Das „PKISync.ps1“ Script muss nach jeder Änderung auf der Certificate Authority erneut auf allen Account-Forests getriggert werden. Es wird daher empfohlen, das Script automatisiert in regelmäßigen Abständen mithilfe des Task Schedulers auszuführen.
Wie um alles in der Welt fügt man der Gruppe „Zertifikatsherausgeber“ (Global Security) einen Account aus einer trusted Domain hinzu? Das geht nur bei einer Domain local!
Bei der „Zertifikatsherausgeber“ Gruppe handelt es sich allerdings um eine „Domain local“ Sicherheitsgruppe. Somit sollte das eigentlich kein Problem sein.