ADCS von Server 2008 (SBS) zu Server 2016 migrieren

[knut4linux 0]

Hi @ll, 

 

ich plane die Ablösung unseres SBS 2008 und die Dienste auf mehrer Server aufzuteilen. In meiner Testumgebung bin ich nun auf ein kleines Problem bezüglich der Zertifizierungsstelle gestoßen.

 

Basierend auf folgenden Artikel (https://technet.microsoft.com/en-us/library/ff3f6ff4-7bd6-4a76-8eaf-0c69e17706ac) versuche ich die Migration auf einen Server 2016. In den unterstützten Migrationsszenarios ist allerdings von Server 2016 nichts zu lesen.  :confused:

 

Meine Frage an euch:

 

- Hat zufällig jemand von euch schon mal eine CA Migration von Server 2008 auf 2016 durchgeführt und evtl. einen Leitfaden für mich?

 

- Der SBS hält standardmäßig alle möglichen Rollen. Ist es notwendig die CA wieder auf einem Domain Controller auzurollen? Ich hätte ihn lieber dediziert auf einem Server, der keine weiteren Rollen hält (so wie es eigentlich auch üblich ist).

 

-  Die ADCS-Rolle auf den Server 2016 aus zu rollen, ist jetzt nicht der große Akt, das Problem ist vielmehr, dass ich die Sicherung der ursprünglichen CA nicht einfach so wiederherstellen kann, was rein theoretisch auch nicht optimal ist, da ich damit auch nicht mehr veröffentlichen kann, welche Zertifikate ausgestellt oder gesperrt sind.

 

- Die CA einfach nicht zu migrieren wäre auch meiner Sicht suboptimal, da ja die Gültigkeit der Zertifikate/Zertifikatskette nicht mehr geprüft werden kann.

 

Ich danke vorab für eure Anregung.  :wink2:

bearbeitet 7. April 2017 von knut4linux

[NilsK 2.940]

Moin,

 

zunächst sollte eine CA nicht auf einem DC installiert werden. Ich würde sogar sagen: Da gehört sie auf keinen Fall hin.

 

Dann: Vielleicht wäre es sinnvoll, die Umstellung zum Anlass zu nehmen, die PKI noch einmal konzeptionell zu überdenken. Für kleine Unternehmen kann eine einstufige PKI zwar ausreichen, aber das sollte man durchaus noch mal prüfen, ob das (noch) zutrifft.

 

Und schließlich: Abhängig davon, wie die PKI bislang genutzt wurde, könnte man sie auch einfach gar nicht migrieren und stattdessen eine neue aufbauen. Die vorhandenen Zertifikate ließe man dann einfach auslaufen - oft ist das ein gangbarer Weg. Für die Zeit muss man nur sicherstellen, dass das Root-Zertifikat und die CRL an mindestens einem Pfad verfügbar sind, der in den Zertifikaten angegeben ist. Dafür muss man die alte CA nicht online halten, es müssen nur die Pfade erreichbar sein, z.B. auf neuen/anderen Servern, die denselben Namen haben. Natürlich hängt das von einer Prüfung ab, ob dieser Weg möglich ist.

 

Falls migriert werden soll, dürften die für ältere Versionen dokumentierten Verfahren auch mit Windows Server 2016 noch funktionieren.

 

Gruß, Nils

[knut4linux 0]

Hi Nils,

 

danke für deine Ausführungen. Was den Standort der CA angeht, bin ich absolut der selben Auffassung, diese nicht auf einem Domain Controller zu installieren. Bei dem SBS ist das aber halt so.

 

Was die Verwendung der PKI angeht, so wurde diese lediglich verwendet um für den Exchange 2007 und dem IIS (Outlook Anywhere/ActiveSync) Zertifikate zu signieren.

 

Der übliche weg, eine PKI zu migrieren scheint auf dem Server 2016 nicht mehr zu funktionieren. Zwar lässt sich die ADCS-Rolle mit dem Zertifikat und dem Privaten Schlüssel der alten CA erfolgreich installieren, sobalb allerdings die Sicherung auf dem neuen Server wieder hergestellt wird, startet der Dienst Aufgrund eines Fehler dann nicht mehr. Er beendet den Dienst mit einem Ausnahmefehlet und verweist auf eine fehlende logdatei. (Current logfile missing). Eventuel war mein vorgehen falsch.

 

Über deinen zweiten Lösungsweg (die CA nicht zu migrieren und die Zertifikate auslaufen lasden) müsste ich mir evtl. Gedanken machen. An sich scheint mir diese Weg auch bequemer. Die Frage ist nur, was ist, wenn ich ein ausgestelltest Zertifikat tatsächlich sperren möchte?

 

Danke für deine Zeit und schönes WE, auch an alle Mitlesenden.

[NilsK 2.940]

Moin,

 

wie wahrscheinlich ist es denn, dass du ein Zertifikat sperren willst? Wenn du nur für Exchange welche ausgestellt hast, würdest du das Zertifikat im Fall eines Falles nicht sperren, sondern ein neues von deiner neuen CA einsetzen.

 

Das wäre in deinem Szenario ja ohnehin der Weg: Sobald die neue CA (die du ordentlich und koordiniert aufgesetzt hast) da ist, stellst du neue Zertifikate für dein Exchange und alle sonstigen Komponenten von dieser neuen CA aus. Dann kann der ganze alte Kram einfach weg.

 

Eine Migration wäre eigentlich nur dann von Interesse, wenn du in großem Stil Zertifikate zur Verschlüsselung ruhender Daten ausgestellt hättest oder sowas.

 

Gruß, Nils

[Nobbyaushb 1.474]

Anmerkung - in meiner Testumgebung lies sich die Root-CA nicht auf einem DC installieren.

 

Wir haben daher in userem Forest eine Root-CA auf einer eigenen (VM)-Maschine installiert.

 

Da wir für den Hyper-V-Cluster eh Datacenter-Lizenzen haben, spielt das keine Rolle, solange die Hardware mitspielt.

 

Sonst bin ich wie meistens bei Nils ;)

[testperson 1.692]

Hi,

 

@Nobbyaushb:

eine RootCA lässt sich auf einem DC installieren. Hab ich Mittwoch noch auf meiner "Azure-Spielwiese" gemacht. In einer der TPs ging das aber meine ich definitiv nicht.

 

@knut4linux:

Die Migration ist ebenfalls kein Problem. Wenn dein Server auf dem die CA läuft einen neuen Namen bekommen hast, musst du das Reg-File vor dem Import bearbeiten (Oder eben nach dem Import in der Registry) und den alten Servernamen auf den neuen Servernamen anpassen.

 

 

If the target CA's computer name is different from the source CA's computer name, search the file for the host name of the source CA computer. For each instance of the host name found, ensure that it is the appropriate value for the target environment. Change the host name, if necessary. Update the CAServerName value.

 

Important

If the host name is located in the .reg file as part of the CA name, such as in the Active value within the Configuration key or the CommonName value within the CAName key, do not change the setting. The CA name must not be changed as part of the migration. This means the new target CA must have the old CA's name, even if part of that name is the old CA's host name.

 

Gruß

Jan

[NilsK 2.940]

Moin,

 

ich möchte nur noch mal eben einwerfen, dass man zumindest prüfen sollte, ob man eine CA bei der Gelegenheit nicht lieber ordentlich konzipieren und installieren will. Bei solchen "Mal-eben"-Sachen kommt sonst schnell etwas heraus, was mit Sicherheit und Zuverlässigkeit nicht viel zu tun hat.

 

Gruß, NIls

[NorbertFe 2.050]

Wenns sowieso nur für den exchange war, sollte man das eine zertifikat einfach kaufen. Weniger Aufwand, besseres handling.

[knut4linux 0]

Hi @ll,

 

ich danke euch noch mal für eure Meinungen/Ideen.

 

Produktiv würde ich es so habdeln wie es Nils schon vorgeschlagen hatte. Die alten Zertifikate einfach auslaufen lassen und die neuen nur noch über den neuen ausgeben.

 

@NorbertFe

Ein Zertifikat kaufen ist vom habdling mit Sicherheit einfacher. Da ich OWA und ActiveSync aber eh nicht veröffentliche und den ganzen Käse nur intern und via VPN zur Verfügung stellen würde, kann ich mir das Geld auch sparen. Solange es intern ausgestellt und signiert wird, vertrauen die Clients auch dem Herausgeber, was für mich an dieser Stelle auch vollkommen ausreicht.

 

@Testperson

Danke für den Einwand

 

Euch allen noch einen sonniges WE :)

[testperson 1.692]

Wenn du die Einwände von NilsK beherzigst, wirst du einiges an Man-Power in deine PKI stecken (müssen), die wohl weitaus mehr Zeit und somit Geld kostet wie ein Zertifikat für Exchange (~100€ für 3 Jahre).

[NorbertFe 2.050]

Auch so musst du über von den Leuten entweder angewöhnen im Handy die Meldung über fehlerhafte Zertifikate zu ignorieren oder überall dein Root Zertifikat verteilen. Sinnvoll sieht für mich anders aus. Über den Sinn und Unsinn active Sync nur per VPN anzubieten sag ich besser nichts.

[Dukel 454]

Wenn das ganze nur intern mit verwalteten Geräten gemacht wird kann auch das Self-Signed Zertifikat des Exchange Server verteilt werden.

[NorbertFe 2.050]

Aha und du verteilst die dann wie genau auf ein mobile device? Abgesehen davon ist self signed nicht supported und hier geht's ja auch nicht um self signed, sondern um eine private CA. ;)

[knut4linux 0]

Guten Morgen an alle,

 

die CA konnte ich über den offiziell dokumentierten weg von MS in meiner Testumgebung erfolgreich migrieren. Danke noch mal an alle, die Ihre Zeit über das Wochenende diesem Thema gewidmet haben.  :thumb1:

 

Man liest sich, Knut