Jump to content

ADCS von Server 2008 (SBS) zu Server 2016 migrieren


Direkt zur Lösung Gelöst von NilsK,
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

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 von knut4linux
Link zu diesem Kommentar
  • Beste Lösung

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

Link zu diesem Kommentar

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.

Link zu diesem Kommentar

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

Link zu diesem Kommentar

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 ;)

Link zu diesem Kommentar

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.

 

clear.gifImportant

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

Link zu diesem Kommentar

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 :)

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...