Teil 2 der Artikelserie über die Automatisierung mit Ansible.

Vorwort

In Teil 2 der Artikelserie über die Automatisierung mit Ansible anhand des Beispiels “Patch Deployment auf Windows” implementieren wir eine interne Zertifizierungsstelle (Stichwort: Enterprise Certificate Authority) mit den Active Directory Certificate Services.

Meine Windows-Infrastruktur für dieses Beispiel sieht folgendermassen aus:

• FQDN: S-901-0104.lh128.local
  • Rolle: Active Directory Controller (ADC), DNS
  • Betriebssystem: Windows Server Standard 2012r2 Core
• FQDN: S-901-0105.lh128.local
  • Rolle: Active Directory Controller (ADC), DNS
  • Betriebssystem: Windows Server Standard 2012r2 Core
• FQDN: S-901-0106.lh128.local
  • Rolle: Management
  • Betriebssystem: Windows Server Standard 2012r2 Desktop Experience
• FQDN: S-901-0107.lh128.local
  • Rolle: WSUS
  • Betriebssystem: Windows Server Standard 2012r2 Core
• FQDN: S-901-0108.lh128.local
  • Rolle: Zertifizierungsstelle (zukünftig)
  • Betriebssystem: Windows Server Standard 2012r2 Core

Die Entscheidung für Windows 2012r2 war übrigens Zufall gepaart mit Faulheit – die VM’s wurden von einem Migrations-Test eines Kunden rezykliert.

Ob Du nun Windows Server Core oder Desktop Experience für die interne Zertifizierungsstelle verwendest ist prinzipiell egal. Denke bitte nur daran, dass die Zertifizierungsstelle das Rückgrat Deiner internen Vertrauensbeziehungen darstellt. Du musst Deiner Zertifizierungsstelle jederzeit vertrauen können.

Wurde Deine Zertifizierungsstelle kompromittiert ist damit auch jegliche interne mit TLS/SSL veschlüsselte Kommunikation kompromittiert!

Meiner Meinung nach bietet Windows Server Core eine weitaus kleinere Angriffsfläche als Windows Server Desktop Experience, einerseits weil der Footprint einfach kleiner ist und andererseits weil die Hemmschwelle den Server “zu betreten und daran zu arbeiten” für einen vielleicht etwas unbedarften Kollegen (oder den Kunden!) auf Core-Servern einfach höher ist.

Nichtsdestotrotz muss ich darauf hinweisen, dass ein Core Server alleine nicht als Schutz für ein sensibles System wie eine Zertifizierungsstelle ausreicht!

Implementation der Zertifizierungsstelle

Bitte öffne auf dem Server, den Du als Zertifizierungsstelle nutzen möchtest, die PowerShell (als Administrator). Mit dem folgenden Befehl installierst Du die Zertifizierungsstelle:

PS> Install-WindowsFeature -Name ADCS-Cert-Authority

Success Restart Needed Exit Code Feature Result
------- -------------- --------- --------------
True    No             NoChangeNeeded {}

Falls ein Neustart angefordert wird, starte bitte den Server neu.

Auf dem Management-Server öffnest Du ebenfalls die PowerShell und installiert mit folgendem Befehl die Verwaltungstools der Zertifizierungsstelle:

PS> Install-WindowsFeature -Name RSAT-ADCS-Mgmt

Success Restart Needed Exit Code Feature Result
------- -------------- --------- --------------
True    No             NoChangeNeeded {}

Wir öffnen nun die “Certificate Autority”-MMC, Du findest sie im Startmenü, im Server-Manager und in den Administrative Tools. Dass nach dem Ausführen selbiger ein Fehler angezeigt wird, wenn sich die Zertifizierungsstelle auch einem anderen Server befindet, ist normal:

Falls nötig wählen wir “Retarget Certificate Authority” …

… und selektieren im darauf folgenden Dialogfeld den korrekten FQDN der Zertifizierungsstelle:

Wie Du siehst, ist die Zertifizierungsstelle noch ziemlich leer – lediglich die ADC’s ziehen sich nach ein paar Stunden Zertifikate.

Wir müssen nun sicherstellen, dass sich jeder Server (oder jeder Computer) der Active Directory ein Zertifikat zieht. In kleinen Umgebungen lässt sich das händisch machen…

Aber – ist das wirklich eine gute Idee? Möchtest Du einmal pro Jahr (oder so) Deinen Servern nachrennen und die Zertifikate austauschen? Nein! Das lässt sich wunderbar automatisieren.

Das automatische beziehen von Zertifikaten implementieren

Zwischenfrage: Wie übersetzt man eigentlich “Automatic certificate enrollment” korrekt auf Deutsch? Mir ist leider nur das eingefallen und ich habe keine deutsch lokalisierten Server hier…

Das automatic certificate enrollment kannst Du mittels einer Gruppenrichtlinie implementieren. Erstelle dazu bitte ein neues Gruppenrichtlinienobjekt und bearbeite es. Im Pfad “Computer Configuration\Policies\Windows Settings\Security Settings\Public Key Policies” findest Du die Einstellung “Certificate Services Client – Auto-Enrollment”.

Gemäss der Dokumentation des Herstellers setzen wir das “Configuration Model” auf “Enabled” und beide Haken. Die Einstellungen sollten Selbsterklärend sein.

In die Organisationseinheit(en) der Server verknüpfen wir nun die gerade erstellte Gruppenrichtlinie:

Eigentlich sollte es nun (bzw. nach einer Aktualisierung der Gruppenrichtlinien) funktionieren, oder? Leider nein. Wir benötigen noch eine Zertifikatsvorlage, welche “Auto Enrollment” erlaubt.

Dazu wechseln wir wieder ins “Certificate Autonrity”-MCC und öffnen die Templates. Mittels “Manage” kannst Du die Zertifikatsvorlagen verwalten:

Die Zertifikatsvorlage, welche automatisch gezogen werden soll, muss in in den Sicherheits-Eigenschaften “Autoenroll” erlaubt haben. Das lässt sich leider mit der mitgelieferten Computer-Vorlage nicht durchführen, daher duplizierst Du sie bitte:

Passe im Tab “General” mindestens den Namen der Vorlage an:

Im Tab “Security” gewährst Du der Gruppe “Domain Computers” bitte das Recht “Autoenroll”:

Die anderen Optionen der Vorlage kannst Du falls gewünscht anpassen. Sei Dir aber sicher, was Du tust!

Zurück in der in den Templates im “Certificate Authority”-MMC hohlst Du mit “Certificate Template to Issue”  die eben erstellte Vorlage:

Überprüfen der Implementation

Wenn wir nun alles richtig gemacht haben, ziehen sich nun in den nächsten 90 Minuten alle Server nach und nach ein Zertifikat. Du kannst das im “Certificate Authority”-MMC unter “Issued Certificates” überprüfen:

Damit sind wir am Ende des 2. Teil. Weiter geht’s demnächst mit der Implementation vom WinRM mit https.