Zum Inhalt wechseln


Foto

ADCS von Server 2008 (SBS) zu Server 2016 migrieren

SBS - Small Business Server

  • Bitte melde dich an um zu Antworten
13 Antworten in diesem Thema

#1 knut4linux

knut4linux

    Newbie

  • 42 Beiträge

 

Geschrieben 07. April 2017 - 15:42

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.micr...af-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, 07. April 2017 - 15:47.

Ich habe zwar keine Lösung aber ich bewundere das Problem...


#2 NilsK

NilsK

    Expert Member

  • 12.347 Beiträge

 

Geschrieben 07. April 2017 - 15:52   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


Nils Kaczenski

MVP Cloud and Datacenter Management
... der beste Schritt zur Problemlösung: Anforderungen definieren!

Kostenlosen Support gibt es nur im Forum, nicht privat!


#3 knut4linux

knut4linux

    Newbie

  • 42 Beiträge

 

Geschrieben 07. April 2017 - 18:21

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.

Ich habe zwar keine Lösung aber ich bewundere das Problem...


#4 NilsK

NilsK

    Expert Member

  • 12.347 Beiträge

 

Geschrieben 07. April 2017 - 19:03

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


  • knut4linux gefällt das

Nils Kaczenski

MVP Cloud and Datacenter Management
... der beste Schritt zur Problemlösung: Anforderungen definieren!

Kostenlosen Support gibt es nur im Forum, nicht privat!


#5 Nobbyaushb

Nobbyaushb

    Board Veteran

  • 2.637 Beiträge

 

Geschrieben 07. April 2017 - 22:00

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


Mfg aus Bremen

 

Norbert (der andere :))

MVP Exchange Server


#6 testperson

testperson

    Board Veteran

  • 4.515 Beiträge

 

Geschrieben 08. April 2017 - 06:58

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


Good morning, that's a nice TNETENNBA!

#7 NilsK

NilsK

    Expert Member

  • 12.347 Beiträge

 

Geschrieben 08. April 2017 - 19:53

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


Nils Kaczenski

MVP Cloud and Datacenter Management
... der beste Schritt zur Problemlösung: Anforderungen definieren!

Kostenlosen Support gibt es nur im Forum, nicht privat!


#8 NorbertFe

NorbertFe

    Expert Member

  • 30.609 Beiträge

 

Geschrieben 08. April 2017 - 20:58

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

Make something i***-proof and they will build a better i***.


#9 knut4linux

knut4linux

    Newbie

  • 42 Beiträge

 

Geschrieben 09. April 2017 - 11:56

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

Ich habe zwar keine Lösung aber ich bewundere das Problem...


#10 testperson

testperson

    Board Veteran

  • 4.515 Beiträge

 

Geschrieben 09. April 2017 - 12:18

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


  • NilsK gefällt das
Good morning, that's a nice TNETENNBA!

#11 NorbertFe

NorbertFe

    Expert Member

  • 30.609 Beiträge

 

Geschrieben 09. April 2017 - 12:54

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.
  • NilsK gefällt das

Make something i***-proof and they will build a better i***.


#12 Dukel

Dukel

    Board Veteran

  • 9.264 Beiträge

 

Geschrieben 09. April 2017 - 20:43

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


Stop making stupid people famous.


#13 NorbertFe

NorbertFe

    Expert Member

  • 30.609 Beiträge

 

Geschrieben 09. April 2017 - 20:47

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

Make something i***-proof and they will build a better i***.


#14 knut4linux

knut4linux

    Newbie

  • 42 Beiträge

 

Geschrieben 10. April 2017 - 06:37

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 


Ich habe zwar keine Lösung aber ich bewundere das Problem...




Auch mit einem oder mehreren der folgenden Tags versehen: SBS - Small Business Server