Windows AD Certificate Authority – Cross Forest Deployment
Windows Certificate Authority
CA installieren
Falls eure Resource Domäne noch keine eigenständige Enterprise CA besitzt, ist es nun an der Zeit eine zu installieren. Die Installation und Grundkonfiguration erfolgt über den Server Manager selbst und ist daher relativ einfach.
Dazu wechseln wir in den Server Manager und installieren die Server Rolle „Active Directory Certificate Services„.
Als Basis dient uns die „Certificate Authority“ selbst. Wer jedoch nicht auf die Web Enrollment Dienste verzichten möchte, kann diese an dieser Stelle natürlich gleich mit installieren.
Nachdem die Installation abgeschlossen ist, können wir die Konfiguration der CA gleich direkt aus dem Server Manager starten.
Falls ihr weitere Dienste mit installiert habt, wählt zum Start trotzdem nur die CA aus. Alles weitere kann anschließend konfiguriert werden.
Je nachdem ob ihr eine mehrstufige Hierarchie aufbauen möchtet, müsst ihr zuvor eine Offline Standalone CA erstellen und erst danach die Enterprise CA (Stichwort 2 Tier CA). In unserem Fall erstellen wir nur eine Root-CA und somit eine sehr flache und einfach Hierarchie.
Auch bei diesem Punkt ist es wieder entscheidend, welche CA-Hierarchie aufgebaut werden soll. Bleibt ihr bei der flachen Hierarchie, muss hier die „Root CA“ ausgewählt werden.
Wir erstellen einen neuen Private Key, welcher anschließend das Root Zertifikat unserer Zertifizierungsstelle signiert. Auch wenn Windows das Handling des Keys automatisch für euch übernimmt, ist es an dieser Stelle extrem wichtig, dass der Private Key niemals verloren geht. Falls das passiert, kann das Root Zertifikat der CA nicht mehr erneuert werden und eure CA muss von Grund auf neu aufgebaut werden. Daher ist es auch sehr wichtig, dass der Private Key niemals in falsche Hände gerät.
Die Key Length stellen wir auf 4096 Bit, als Hash Algorithmus lassen wir SHA256 ausgewählt.
Beim CN (Common Name) kann der vordefinierte Name übernommen oder ein eigener eingetragen werden.
Wir bereits vorhin kurz angerissen, muss das Root Zertifikate einer Zertifizierungsstelle in regelmäßigen Abständen erneuert werden. Denn sobald das Root Zertifikat abgelaufen ist und nicht erneuert wurde, gelten alle ausgestellten Zertifikate als nicht mehr vertrauenswürdig, da die Zertifikatskette unterbrochen wird. Clients innerhalb der Domäne bekommen das neu ausgestellte Root Zertifikat automatisch in den „Vertrauenswürdigen Stammzertifizierungsstellen“ Reiter importiert. Für alle anderen Clients muss das allerdings manuell übernommen werden und das geht dementsprechend mit einem erhöhten Aufwand einher. Daher stelle ich die Lebensdauer des Root Zertifikats auf 10 Jahre.
Anschließend ist die Grundkonfiguration der Certificate Authority bereits abgeschlossen.
Zu guter Letzt aktivieren wir noch den LDAP Referral Support mit folgendem Befehl in der Eingabeaufforderung:
certutil -setreg Policy\EditFlags +EDITF_ENABLELDAPREFERRALS
Dabei wird einfach nur ein zusätzlicher Registry Key gesetzt.
CA zur Cert Publisher Gruppe hinzufügen
Damit die Certificate Authority der resource.local auch dazu berechtigt ist, Zertifikate innerhalb der account.local auszustellen, muss das Computer Objekt der CA zur Gruppe „Cert Publishers“ im Account-Forest hinzugefügt werden. Falls ihr mehrere Account-Forests besitzt, muss dieser Schritt entsprechend bei allen Domänen ausgeführt werden.
Veröffentlichen der CA in den Account-Forests
Als nächstes muss die Windows CA in allen Account-Forests in den Service-Containern veröffentlich werden. Das ist ein notwendiger Schritt, um in späterer Folge Zertifikate direkt auf den Clients anzufordern.
Auf der VM der Certificate Authority führen wir folgenden Befehl innerhalb der Eingabeaufforderung aus:
C:\Users\Administrator>certutil -ca.cert C:\CA_Root.cer
Dabei wird das Root Zertifikate unter „C:\“ gespeichert. Diese Datei kopieren wir nun auf jeweils einen Domain Controller aller Account-Forests und speichern es ebenfalls unter „C:\„. Anschließend führen wir am Domain Controller des Account-Forests folgende Befehle aus:
C:\Users\Administrator>certutil -dspublish -f C:\CA_Root.cer RootCA C:\Users\Administrator>certutil -dspublish -f C:\CA_Root.cer NTAuthCA C:\Users\Administrator>certutil -dspublish -f C:\CA_Root.cer SubCA
Anschließend wird das neue Root Zertifikat automatisiert auf allen Clients innerhalb der Domäne verteilt. Dieser Vorgang kann allerdings mehrere Stunden dauern.
Wechselt man nach dem erfolgreichen Ausführen der Befehle in das MMC Modul „Sites and Services“, sollte man bereits folgende Einträge sehen können.
Damit nun auch noch Clients Zertifikate direkt über die MMC anfordern können, müssen wir noch alle relevanten LDAP Attribute vom Resource- in die Account-Forests übertragen. Dabei kommt uns das Script „PKISync.ps1“ von Microsoft zu Hilfe. Kopiert einfach den Inhalt in die Powershell ISE und speichert es am Account-Forest Domain Controller als „PKISync.ps1“ unter „C:\„. Anschließend kann das Script mit folgendem Befehl ausgeführt werden:
.\PKISync.ps1 -Sourceforest resource.local -Targetforest account.forest
Somit wurden alle Attribute erfolgreich in den Account-Forest übernommen. Wir können bereits über ein MMC mit importierten Zertifikats Snap-In schauen, ob wir ein Zertifikate anfordern können und siehe da, es werden uns bereits die vorhandenen Templates angezeigt.
Natürlich können wir an dieser Stelle noch kein Zertifikat anfordern, da wir im Account-Forest für keines der Templates die nötigen Berechtigungen besitzen.
Somit haben wir schon einmal die Basis geschaffen, damit wir zukünftige Zertifikate ausstellen und anfordern können. Auf der nächsten Seite passen wir die Zertifikatstemplates für die Account-Forests an.
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.