AD - Zertifizierungsstelle migrieren

[wznutzer 32]

Guten Morgen,

 

ich plane die Migration für eine meiner AD-Domänen. Nun hat sich mir eine, für euch wahrscheinlich, blöde Frage gestellt.

 

Die installierte Zertifizierungsstelle hat keine ausgestellten Zertifikate (die wenigen Zertifikate sind gekauft). Nun kam die Idee, dass es dann auch nichts zu migrieren gibt und ich mir diese Schritte sparen kann.

 

Würde folgendes funktionieren?

• Neuer DC installieren (von W2K12R2 nach W2K22), hochstufen, FSMO-Rollen übertragen
• Zertifizierungsstelle einfach neu auf einem der W2K22 installieren (AD-integriert) oder ganz weglassen (wurde ja nicht gebraucht)
• Zertifizierungsstelle auf dem alten W2K12R2 deinstallieren und diese herunterstufen.

 

Ich hätte ja kurzzeitig zwei integrierte Zertifizierungsstellen, das macht mir etwas sorgen, andererseits können ja auch keine Zertifikate ungültig werden, gibt ja keine.

 

Könnt Ihr mir helfen den Knoten im Kopf zu lösen?

[Dukel 436]

Wenn es nicht genutzt wird, dann lass es weg.

[NorbertFe 1.805]

vor 22 Minuten schrieb wznutzer:

hat keine ausgestellten Zertifikate

Was merkwürdig ist, denn per Default ziehen sich die Domaincontroller hardcoded ein zertifikat auf Basis der DomainController-Vorlage. ;) Und wenn deine DCs kein Zertifikat haben, gibts per default auch kein LDAPs.

[wznutzer 32]

vor 30 Minuten schrieb NorbertFe:

Was merkwürdig ist, denn per Default ziehen sich die Domaincontroller hardcoded ein zertifikat auf Basis der DomainController-Vorlage. ;) Und wenn deine DCs kein Zertifikat haben, gibts per default auch kein LDAPs.

Mein Fehler, falsch ausgedrückt. Es gibt keine Zertifikate deren Ausstellung ich selbst angetriggert habe. Es gibt ein paar Basis EFS Zertifikate und die der Domaincontroller. Warum die Basis EFS Zertifikate ausgestellt sind, weiß ich nicht. Ich weiß aber sicher, dass EFS nicht verwendet wird.

 

Bedeutet das, dass ich besser doch eine Migration machen sollte(https://learn.microsoft.com/de-de/troubleshoot/windows-server/identity/move-certification-authority-to-another-server), weil ich sonst die Domäne schrotte?

[NorbertFe 1.805]

vor 5 Minuten schrieb wznutzer:

Warum die Basis EFS Zertifikate ausgestellt sind, weiß ich nicht. Ich weiß aber sicher, dass EFS nicht verwendet wird.

Offensichtlich wurde es aber mal verwendet, denn die werden automatisch gezogen, sobald irgendwann/irgendwer mal auf "verschlüsseln" geklickt hat. Ob das jetzt ein grundsätzliches Problem darstellt, musst du rausfinden. Wenn das Zertifikat weg ist, sind im worst case auch die verschlüsselten Daten weg.

 

Die Domain schrottest du damit nicht, nur maximal die Daten die per EFS verschlüsselt wurden. ;) Wenn man EFS verhindern will, muss man es explizit per GPO verbieten!

 

Bye

Norbert

[wznutzer 32]

vor 25 Minuten schrieb NorbertFe:

Offensichtlich wurde es aber mal verwendet, denn die werden automatisch gezogen, sobald irgendwann/irgendwer mal auf "verschlüsseln" geklickt hat.

Danke. Ich bin selber darunter. Naja, die Haare sind schon grau, evtl. unbeabsichtigt.

 

Die Zertifikate für die Domaincontroller werden bei einer Neuinstallation einfach neu ausgestellt, also wenn ich die Zertifizierungsstelle neu installiere?

 

Aber wahrscheinlich denke ich hier zu kompliziert und in die falsche Richtung. In der Zwischenzeit hätte ich das ja wahrscheinlich schon migriert und die Fragen stellen sich dann gar nicht.

[NorbertFe 1.805]

vor 3 Minuten schrieb wznutzer:

Die Zertifikate für die Domaincontroller werden bei einer Neuinstallation einfach neu ausgestellt, also wenn ich die Zertifizierungsstelle neu installiere?

Ja, wobei empfohlen wird, besser das Zertifikat auf Basis der Kerberos Vorlage auszustellen, dazu muss man dann aber ein wenig mehr konfigurieren.

 

naja sieht eher nach setup enter enter installation aus. Kann man zwar machen, aber …

[wznutzer 32]

Am 19.6.2023 um 13:07 schrieb NorbertFe:

naja sieht eher nach setup enter enter installation aus. Kann man zwar machen, aber …

Evtl. stehe ich etwas auf dem Schlauch. Zusammenfassend kann man sagen:

• Wenn man nicht migriert sind halt evtl. die verschlüsselten Daten der EFS-Zertifikate verloren. Wobei sich niemand daran erinnern kann, das absichtlich verwendet zu haben. Will man dieses Risiko ausschließen, muss man halt migrieren.
• Die ausgestellten Zertifikate für die DCs sind kein Problem, werden neu erzeugt, wenn eine AD-integrierte Zertifizierungsstelle installiert wird.
• Für die DCs sollte man eine Kerberos-Vorlage verwenden:
  https://learn.microsoft.com/de-de/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-pki
  Bereits ausgestellte Zertifikate werden so ersetzt.
• Die in meinem Ausgangspost beschriebene Reihenfolge ist falsch. Man muss zuerst die alte Zertifizierungsstelle deinstallieren *bevor* man die neue installiert. Das gilt für die AD integrierte CA. Macht man das andersrum ist die neue CA nicht mehr funktionsfähig.
• Es ist kein Problem mal kurzzeitig keine CA zu haben. Die Zertifikate sind ausgestellt und dem Root-Zertifikat wird weiterhin vertraut.

Danke für die Tipps.

[wznutzer 32]

@cj_berlin Und a propos - bitte installiere keine CA auf einem DC und installiere auch nicht das Web Enrollment!

(Das Zitat habe ich aus einem anderen Thread kopiert.)

 

Warum sollte man das nicht tun (CA auf DC)? Gibt es einen Grund, dass es dann eine Funktionseinschränkung gibt oder geht die Überlegung eher in die Richtung, dass ein DC nur ein DC sein sollte? In Bücher, Schulungsvideos wird das immer erwähnt, allerdings ohne Begründung.

bearbeitet 22. Juni 2023 von wznutzer

[chrismue 90]

Hi, 

 

ein DC ist ein DC und nichts anderes. 

 

Wenn du weitere Rollen/Dienste auf einem DC installierst, hast du ggf. eine höhere Angriffsfläche durch Sicherheitslücken. 

 

Außerdem kannst du einen dc ohne weitere Rollen im Fehlerfall in 60-90 min neu machen, was bei zusätzlichen Diensten /Rollen das neumachen meist erschwert. 

 

 

Gruß 

chrismue 

bearbeitet 22. Juni 2023 von chrismue

[NorbertFe 1.805]

vor 50 Minuten schrieb wznutzer:

In Bücher, Schulungsvideos wird das immer erwähnt, allerdings ohne Begründung.

Weil ein DC der NUR ein DC ist mal eben ersetzt werden kann. Sobald weitere Dienste drauf laufen ist das meist nicht mehr der Fall. Zusätzlich kommt immer auch das Thema Security eines DCs dazu.

[wznutzer 32]

OK, verstanden. Ich gehe davon aus, dass ihr Lizenzkosten nicht als valides Argument gelten lässt. Wenn ich nun möglichst alles nach "best practices" haben will und trotzdem die Kosten im Blick haben muss, muss ich ja irgendwann anfangen, dass eine VM mehrere Rollen übernimmt. Je größer das Netzwerk, desto mehr wird man wohl trennen. Aber was kann ich denn guten Gewissens zusammenlegen? Bisher trenne ich nach Infrastruktur und Workern und nichts kurzfristiges mit etwas das ich langfristig brauche.

 

Nur mal so als Beispiel. Eine CA und das Bereitstellen des DFS hätte ich jetzt auch zusammengepackt, ihr nicht?

bearbeitet 22. Juni 2023 von wznutzer

[NorbertFe 1.805]

vor 42 Minuten schrieb wznutzer:

Eine CA und das Bereitstellen des DFS hätte ich jetzt auch zusammengepackt, ihr nicht?

Nö, denn eine CA ist eine CA genauso wie ein DC ein DC und ein Hyper-V Host ein Hyper-V Host ist. Ob das für die jeweilige Umgebung paßt, sei mal dahingestellt, aber da wird man dann eben anhand der Umgebung entscheiden müssen. Die vorherigen Aussagen sind ganz klar als best practice zu verstehen. Wenn man die nicht einhalten kann oder will, dann kann man das tun, aber das ist dann eben nicht mehr best practice. ;)

[wznutzer 32]

OK, „best practice“ und geringe Lizenzkosten passt nicht zusammen. Dann bleibt nichts anderes als abzuwägen, mit was man gut zurecht kommt, wenn die VM, warum auch immer, mal neu gemacht werden muss. Ich verstehe was Ihr meint. Wenn eine Rolle Ärger macht und diese neu gemacht werden muss und deswegen ein noch einwandfrei funktionierender Dienst auch eingeschränkt wird, ist das schlecht.

 

Vielen Dank für euren Input.

[NorbertFe 1.805]

Hmm den Nachsatz zum Thema Security hast du jetzt lieber nicht bewusst wahrgenommen, oder? ;)