none
Fehlermeldung beim Zurückstufen eines SBS 2011 nach Migration der Rollen auf den Windows 2012 R2 RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo,

    unser alter SBS2011 soll jetzt endgültig aus unserem Netzwerk entfernt werden.
    Dieser hatte die letzten Jahren nur noch als Server für die Backsoftware gedient, welche jetzt auch auf einen neuen Server gewechselt ist.
    Als neuer DC wurde schon vor Jahren ein Windows Server 2012 R2 eingerichtet, auf welchem auch den Exchange Server 2016 läuft, welcher den Exchange Server 2010 vom SBS2011 abgelöst hat. Das lief jetzt auch über Jahre ohne Probleme.
    Auf diesen Windows 2012 R2 server wurden alle FSMO Rollen übertragen, das habe ich jetzt nochmal überprüft
    Schemabetriebsmaster Rolle übertagen = Okay
    RD/PDC/Infrastruktur Master übertragen = Okay
    Domänennamen Betriebsmaster übertragen = Okay
    Im letzten Schritt wollte ich den alten, jetzt nicht mehr benötigten SBS2011 Server über den Befehl "dcpromo” als Domänencontroller herabstufen. Dabei erhielt ich aber folgende Fehlermeldung: "Die Active Directory-Zertifikatdienste müssen entfernt werden, bevor die Active Directory.Domaänendienste installiert oder entfernt werden können."

    Meine Frage ist jetzt, kann ich die Zertifikatdienste auf dem SBS2011 so einfach installieren? Ich habe da die Befürchtung damit den Exchange Server 2016 mit dessen Zertifikaten zu beschädigen.

    Ich habe mir die Zertifikate Mal in der MMC anzeigen lassen und tatsächlich finde ich dort unter"Eigene Zertifikate" ein Zertifikat, welches für den Windows2012R2-Server ausgestellt ist und als "Ausgestellt von..." steht der alte SBS2011 Server. Als "beabsichtigte Zwecke" wird "Clientauthentifizierung und Serverauthentifizierung" angegeben.

    Kann mir jemand vielleicht weiterhelfen, wie ich jetzt weiter verfahren soll? Darüber wäre ich wirklich sehr Dankbar.

    mit freundlichen Grüßen,

    Heiko Witt

    Heiko

    Donnerstag, 16. Juli 2020 15:10
    |

Alle Antworten

  • Question
    Anmelden
    1
    Anmelden

    Moin,

    wenn Du die Zertifikatsdienste vom SBS deinstallierst (was Du sowieso musst, damit die Bezüge dahin sauber aus dem AD ausgetragen werden), passieren zwei Dinge:

    1. es können keine neuen Zertifikate mehr ausgestellt werden --> dafür installierst Du halt ne neue PKI auf dem 2012R2, ziehst die veröffentlichten Vorlagen von der SBS-CA zurück und veröffentlichst sie auf der 2012-CA. Danach kannst Du alle Zertifikate, die die SBS-CA ausgestellt hat, noch einmal von der 2012-CA ausstellen lassen und in den jeweiligen Systemen ersetzen. Irgendwann würden sie eh ablaufen ;-)
    2. es können die CRL-Informationen zu den alten Zertifikaten weder aktualisiert noch abgerufen werden. Wenn Du Punkt 1. aber sauber erledigst, werden ja nirgends mehr Zertifikate angeboten, welche gegen den SBS validiert werden müssten.

    Du könntest natürlich auch den langen Weg gehen und die CA migrieren. Das wäre mit einer Änderung des Maschinen-Namen verbunden und somit nicht von Microsoft supported. Funktionieren tut's aber, und dann hättest Du gar keinen Stress (wenn Du alles richtig machst). Wenn Du so eine Migration noch nie gemacht hast, spiel sie mal im Labor durch (die Versionen der beteiligten Server spielen dabei keine Rolle).

    Ich würde an Deiner Stelle in einer SBS-Umgebung keine CA-Migration machen, sondern eine neue hochziehen und Zertifikate neu ausstellen. 

    Evgenij Smirnov

    http://evgenij.smirnov.de

    Donnerstag, 16. Juli 2020 15:35
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Evgenij,

    vielen Dank für die Antwort.

    Ich habe schon so etwas befürtet. ;-)

    Leider habe ich keine Erfahrung mit einer PKI Installtion und der Übernahme der CA-Vorlagen.
    Trotzdem würde ich gene den von Dir empfohlene Weg gehen, eine neue Zertifizierungsstelle zu installieren und die Zertifikate nue auszustellen. (Einfach um auch die CA zu entrümpeln)

    Ich wäre sehr dankbar, wenn Du mir dazu vielleicht ein Tutorial oder ähnliches empfehlen könntest, bevor ich bei meienr Suche danach im Web was falsches heraussuche und dann einen großen Schaden anrichte.

    Viele Grüße,

    Heiko

    Heiko

    Freitag, 17. Juli 2020 08:25
    |
  • Question
    Anmelden
    1
    Anmelden

    das Tutorial muss ich wohl irgendwann selber schreiben. Alles, was ich bisher im Internet gesehen habe, setzt mehr Verständnis von der Materie voraus als das, was für Deine Aktion überhaupt notwendig ist.

    Ich denke, der Punkt, der Dir fehlt, ist die Tatsache, dass Vorlagen zwar über CAs veröffentlicht sind (damit ist eine CA befähigt, Zertifikate aus dieser Vorlage auszustellen), jedoch im AD zentral gespeichert sind. Sprich, wenn Du im Vorlagen-Zweig der CA-MMC-Konsole eine Vorlage löschst, ist sie nicht weg, sondern lediglich nicht mehr über diese CA veröffentlicht. Die kannst Du dann über eine andere CA im selben Forest veröffentlichen. In größeren Umgebungen ist es auch absolut Gang und Gäbe, dass ein und dieselbe Vorlage über mehrere CAs angeboten wird.

    Im Vorfeld sind für Dich zwei Punkte wichtig:

    1. Feststellen, wer alles der PKI vertrauen muss. Innerhalb des AD-Forests passiert es automatisch, aber externe Geräte müssen das Zertifikat der neuen Root-CA als vertrauenswürdig eingetragen bekommen, bevor Du Zertifikate daraus ausstellst.
    2. Feststellen, wer alles Zertifikate bekommen hat, und wie man sie dort jeweils tauscht.

    Und sobald Du Punkt 1. abgearbeitet hast und die benötigten Vorlagen ausschließlich über die neue PKI veröffentlicht sind, hast Du alle Zeit der Welt, Dich mit Punkt 2. zu beschäftigen und Zertifikate neu auszustellen und zu tauschen.

    Evgenij Smirnov

    http://evgenij.smirnov.de

    Freitag, 17. Juli 2020 08:57
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Evgenij,

    vielen Dank für die Tipps,

    Schade dass es dafür kein Tutorial gibt. ;-)

    Kannst Du mir aber vielleicht ein Tutorial für die Grundinstallation und Einrichtung der Zertifikatdienste in einer AD empfehlen?

    Ich habe bisher solch eine Installation noch nicht durchgeführt, sondern immer gleich bei der Ersteinrichtung einer AD mit erledigen lassen.

    Ich denke die einzigen, die dann dem neuen PKI vertrauen müssen, sind nur Geräte die sich in der AD-Forest befinden, also alle PC-Cleints und Server und die auf den PC-Clients befindlichen Outlook Installationen für den Zugriff auf den Exchange Server.
    Zum Glück nutzen wir keinen Zugriff von Außerhalb unserer AD heraus.

    Viele Grüße,

    Heiko

    Heiko

    Montag, 20. Juli 2020 12:41
    |
  • Question
    Anmelden
    0
    Anmelden


    Zum Glück nutzen wir keinen Zugriff von Außerhalb unserer AD heraus.

    Was ist mit z.B. Multifunktionsdruckern die LDAP-Abfragen tätigen und dabei LDAPS mit S verwenden?

    Evgenij Smirnov

    http://evgenij.smirnov.de

    Montag, 20. Juli 2020 12:46
    |
  • Question
    Anmelden
    0
    Anmelden


    Schade dass es dafür kein Tutorial gibt. ;-)

    Kannst Du mir aber vielleicht ein Tutorial für die Grundinstallation und Einrichtung der Zertifikatdienste in einer AD empfehlen?

    Hier zum Beispiel: https://sid-500.com/2017/03/31/active-directory-zertifikatsdienste-teil-1-installation-einer-enterprise-root-ca/ Ich bin nicht mit allen Punkten einverstanden, aber das sind Details, die in Deinem Fall vermutlich eh irrelevant sind.

    Evgenij Smirnov

    http://evgenij.smirnov.de

    Montag, 20. Juli 2020 12:48
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Evgenij,

    Ja, mit den Druckern könntest Du Recht haben.

    Bevor ich aber da was mache, werde ich eh alles vorher noch überprüfen, ncht dass ich noch was übersehe.

    Viele Grüße,

    Heiko

    Heiko

    Montag, 20. Juli 2020 12:54
    |
  • Question
    Anmelden
    0
    Anmelden

    Vielen Dank für den Link.

    Das werde ich dann Mal Durcharbeiten und im Labor ausproboeren.

    Gruß,

    Heiko

    Heiko

    Montag, 20. Juli 2020 12:55
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Evgenij,

    jetzt ist es passiert!!!

    Bevor ich mit dem ganzen Umzug/Neueinrichtung der Zertifikatedienste anfange, dachte ich dass ich vom alten SBS2011 ein Systemimage anfertige.

    Das war ein böser Fehler. Die Imagererstellung sollte die Nacht über laufen. Irgend wann hat sich sann aber der Server aufgehängt und lässt sich nun nicht mehr starten.

    Zur zeit können sich alle Nutzer noch an der Domäne anmelden, nur die Outlookverbindungen zum Exchange Server machen arge Probleme.

    Bei manchen hängt das Outlook bei "Profil wird verarbeitet..." und bei anderen startet das Outlook, wird aber nicht aktualisiert.

    ICh hoffe, dass Du mir da vielleicht eine Tipp geben kannst, wo ich mich da bei Microsoft hinwenden kann. Ich habe da schon Support gesucht, bin aber nicht fündig geworden. Der ganze Support ist da ziemlich verwirrend und für mich undurchsichtig.

    viele Grüße,

    Heiko

    Heiko

    Donnerstag, 23. Juli 2020 11:55
    |
  • Question
    Anmelden
    0
    Anmelden

    Moin,

    Microsoft? SBS2011? Das wird schwierig...

    Du musst mal schauen, dass der SBS überall als DNS rauskommt, das würde schon helfen. Und dann, wenn er nicht mehr startet, Metadaten-Bereinigung und Adieu. Zertifikate musst Du dann nacharbeiten, aber das waren ja nicht so viele.

    Evgenij Smirnov

    http://evgenij.smirnov.de

    Donnerstag, 23. Juli 2020 19:32
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Evgenij,

    vielen Dank für Deine Antwort.

    Ich habe den alten SBS2011 doch wieder zum Laufen gebracht.

    eine Festplatte aus dem RAID1-Verbund hatte sich beim Image-Backup verabschiedet. Jetzt habe ich zwar kein Systemimage, aber das System läuft wert einmal wieder. Wenn auch nur auf einer Festplatte.

    Da jetzt die Zeit etwas drängt, werde ich es zuerst doch mit einer direkten Migration, welche Du am Anfang der Beitrags erwähnt hattest, versuchen. Ich habe dazu, so denke ich ein paar gute Anleitungen gefunden.

    Nur in einem Punkt widersprechen sich die Anleitungen da Teilweise. In einigen wird beschrieben, dass der neue Server auf dem die neue Zertifizierungsstelle installiert wird, den gleichen Servernamen haben muss, wie der alte Server. In einer anderen Anleitung steht dagegen, dass das nicht notwendig ist, wenn man den entsprechenden Namenseintrag in der Registry, nach dem import der alten Registrydaten, entsprechend abändert.

    Auch schreiben einige, dass die neue Zertifizirungsstelle zwingend auf einem DC installiert werden muss, woanders schreiben aber einige, dass die auch auf einem "normalen" Mitgliedsserver installiert werden kann.

    Kannst Du mir da vielleicht weiterhelfen was davon richtig ist?

    Mein Plan sieht jetzt wie folgt aus:

    Ich werde einen neuen untergordneten Windows 2019 DC installieren. Der Windows 2012 R2 ist ja nach entfernen des alten SBS2011 ja der neue PDC.

    Dann werde ich den Zertifizierungsdienst auf dem neuen Windows 2019 DC installieren und die Migration der Zertifizierungsstelle vom SBS2011 auf diesen nach Anleitung versuchen.

    Ich sehe da aber zur Zeit 2 Probleme:

    1. Mit dem Namen: Wenn der neue Windows 2019 DC den geleichen Namen, wie der alte SBS2011 haben muss. Dann gibt es Probleme, denn 2 DC Server mit gleichen Namen, dass geht ja nicht. Da muss ich dann immer einen vom Netz nehmen und wenn ich alten SBS2011 runterstufe, kann es auf Grund der Namensdopplung passieren, dass da auch der neue mit runtergestuft wird. Oder irre ich mich da?

    2. Die Vorlagen aus der alten Zertifizierungsstelle. Die muss ich ja dann wohl trotzdem neu erstellen. Aber wie ist da der weg, dass die sich Nahtlos einpassen?

    Ich hoffe, Du hast noch den einen oder anderen Tipp für mich, für den ich mich schon einmal ganz herzlich bedanke.

    Viele Grüße,

    Heiko Witt

    Heiko

    Freitag, 24. Juli 2020 07:43
    |
  • Question
    Anmelden
    0
    Anmelden

    Moin Heiko,

    1. Namensgleichheit: Beide haben recht, jeder auf seine Art: Es ist möglich, durch Registry- und LDAP-Hacks den Servernamen zu ändern, aber es wird von MSFT nicht supported. Ich habe allerdings im englischen TechNet-Forum auch Microsoft-Forumsbetreuer gesehen, die auf den Registry Hack hingewiesen haben.
    2. CA auf DC installieren, ist leider supported. Ich würde es niemals empfehlen, wenn man die Wahl hat. Aber wenn man keine hat (z.B. weil nur ein Server zur Verfügung steht ;-) ), dann kann man das machen. 
    3. Die Vorlagen einer Unternehmens-PKI sind im AD gespeichert. Die musst Du nicht neu erstellen, sondern höchstens neu veröffentlichen. Wenn Du die Konfig übernimmst, noch nicht einmal das.
    4. Zwei Computer mit dem gleichen Namen kann es im selben Netz gar nicht geben.

    Du machst Dir wegen der CA zu viele Gedanken. Schau zu, dass Du wichtigere Dinge wie DNS, Replikation usw. nicht übersiehst, weil Du auf die CA fixiert bist.

    Evgenij Smirnov

    http://evgenij.smirnov.de

    Freitag, 24. Juli 2020 08:28
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Evgenij,

    Vielen  Dank für die Antwort.

    Wenn ich das richtig verstehe, dann muss ich den vorhanden virtuellen Windows 2019 Server zum DC heraufstufen.

    Ich kann also die CA direkt auf diesem Mitgliedsserver installieren?

    Viele Grüße,

    Heiko

    Heiko

    Freitag, 24. Juli 2020 08:52
    |
  • Question
    Anmelden
    0
    Anmelden

    Moin,

    wenn Du die CA auf einem Member installierst, wirst Du ihn nicht heraufstufen können. Wenn der Server am Ende also DC sein soll, dann zuerst zum DC promoten und dann die CA installieren.

    Evgenij Smirnov

    http://evgenij.smirnov.de

    Freitag, 24. Juli 2020 09:17
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Evgenij,

    Vielen Dank für die vielen Tipps.

    Es scheint funktioniert zu haben.

    Ich habe einen Mitgliedsserver zu einem DC hochgestuft und dann die Zertifizierungsstelle installiert und laut Anleitung die Migration durchgeführt. Da der neue Server ja einen anderen Namen hat, habe ich dann noch den entsprechenden Eintrag zum FQN in der registry angepasst.

    Die Zertifizierungstelle scheint zu laufen und auch alle Ausgestellte Zertifikate und Vorlagen werden angezeigt.

    Gibt es da eine Möglichkeit, das zu testen?

    Die Zertifizierungsstelle auf dem alten Server habe ich voererst deaktiviert.

    Das anscheinend einzige Problem, das ich noch habe, tritt auf, wenn ich den alten Server vom Netz trenne. Das betrifft aber den Exchange Server. Da werde ich aber Mal im entsprechenden Formum nachfragen, warum da das Autodiscover zuerst immer noch den alten server sucht.

    Vielen Dank,

    mit freundlichen Grüßen

    Heiko

    Heiko

    Freitag, 24. Juli 2020 15:03
    |
  • Question
    Anmelden
    0
    Anmelden

    Gibt es da eine Möglichkeit, das zu testen?


    Klar. Nimm irgendein vor dem Umzug der CA ausgestelltes Zertifikat, exportiere es als .cer und führe dann aus:

    certutil -f -urlfetch -verify c:\temp\mycert.cer
    Achte auf die Ausgabe, ob da irgendwelche nicht erreichbaren CDP-Pfade drin vorkommen.

    Evgenij Smirnov

    http://evgenij.smirnov.de

    Freitag, 24. Juli 2020 15:20
    |
  • Question
    Anmelden
    0
    Anmelden

    warum da das Autodiscover zuerst immer noch den alten server sucht.

    Schau mal in den Service Connection Point im AD. Dort steht die URL drin. Wenn der alte Server nach alphabetischem Vergleich vor dem neuen Server steht, wird auch zuerst "sein" SCP probiert...

    Evgenij Smirnov

    http://evgenij.smirnov.de

    Freitag, 24. Juli 2020 15:26
    |
  • Question
    Anmelden
    0
    Anmelden

    Haloo Evgenij,

    Nochmals vielen, vielen dank für deine Hilfe.

    Ich habe, wie von Dir vorgeschlagen, Ein ausgestelltes Zertifikat ausgegeben und dann mit dem von Dir angegeben Befehl überprüft.

    Meiner Einschätzung nach, ging da alles Fehlerfrei durch.
    Oder kannst Du ein Problem erkennen?

    Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. Alle Rechte vorbehalten.

C:\Windows\system32>certutil -f -urlfetch -verify c:\temp\mycert.cer
Aussteller:
    CN=ttdatdom-SBS2011-SRV-CA
  Namenshash (sha1): 8fcaeaa88ecfbd247367ff408dea0692ce62c969
  Namenshash (md5): a1c64c0c6cf00d22e45c87ae8d4669b5
Antragsteller:
    CN=ttdatdom-SBS2011-SRV-CA
  Namenshash (sha1): 8fcaeaa88ecfbd247367ff408dea0692ce62c969
  Namenshash (md5): a1c64c0c6cf00d22e45c87ae8d4669b5
Zertifikatseriennummer: 5e7dcaa9772366a44f00ed49a9229617

dwFlags = CA_VERIFY_FLAGS_ALLOW_UNTRUSTED_ROOT (0x1)
dwFlags = CA_VERIFY_FLAGS_IGNORE_OFFLINE (0x2)
dwFlags = CA_VERIFY_FLAGS_FULL_CHAIN_REVOCATION (0x8)
dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN (0x20000000)
HCCE_LOCAL_MACHINE
CERT_CHAIN_POLICY_BASE
-------- CERT_CHAIN_CONTEXT --------
ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
ChainContext.dwRevocationFreshnessTime: 18 Hours, 50 Minutes, 48 Seconds

SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
SimpleChain.dwRevocationFreshnessTime: 18 Hours, 50 Minutes, 48 Seconds

CertContext[0][0]: dwInfoStatus=10c dwErrorStatus=0
  Issuer: CN=ttdatdom-SBS2011-SRV-CA
  NotBefore: 27.04.2017 11:55
  NotAfter: 27.04.2022 12:05
  Subject: CN=ttdatdom-SBS2011-SRV-CA
  Serial: 5e7dcaa9772366a44f00ed49a9229617
  e862bbafd7b476da4fb74a62878820318226f7b8
  Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
  Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)
  Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
  ----------------  Zertifikat abrufen  ----------------
  Keine URLs "Keine" Zeit: 0
  ----------------  Zertifikat abrufen  ----------------
  Keine URLs "Keine" Zeit: 0
  ----------------  Basissperrliste veraltet  ----------------
  Abgelaufen "Deltasperrliste (0be9)" Zeit: 0
    [0.0] ldap:///CN=ttdatdom-SBS2011-SRV-CA(1),CN=SBS2011-SRV,CN=CDP,CN=Public%
20Key%20Services,CN=Services,CN=Configuration,DC=ttdatdom,DC=local?deltaRevocati
onList?base?objectClass=cRLDistributionPoint

  ----------------  Zertifikat-OCSP  ----------------
  Keine URLs "Keine" Zeit: 0
  --------------------------------
    CRL 0be9:
    Issuer: CN=ttdatdom-SBS2011-SRV-CA
    ThisUpdate: 23.07.2020 16:45
    NextUpdate: 31.07.2020 05:05
    19b93adce34460c6a96f6c1d63129119b5194080
    Delta CRL 0bec:
    Issuer: CN=ttdatdom-SBS2011-SRV-CA
    ThisUpdate: 26.07.2020 16:45
    NextUpdate: 28.07.2020 05:05
    9937f500308edd32f837d2c1019a1546c64433eb

Exclude leaf cert:
  8bee99b10ddcdbcf33742fbb5a2f19a4a47b781f
Full chain:
  a33b35af5eb9b9e4c3c8d754185aab7eddd1783a
------------------------------------
Verfizierte Ausstellungsrichtlinien: Alle
Verfizierte Anwendungsrichtlinien: Alle
Zertifikat ist ein Zertifizierungsstellenzertifikat
Sperrstatussüberprüfung des untergeordneten Zertifikats erfolgreich abgeschlosse
n.
CertUtil: -verify-Befehl wurde erfolgreich ausgeführt.

C:\Windows\system32>

    Viele Grüße,

    Heiko Witt

    Heiko

    Montag, 27. Juli 2020 10:04
    |
  • Question
    Anmelden
    0
    Anmelden

    Moin,

    das ist ja das Zertifikat der CA selber. Ich dachte da eher an eins, das die CA für jemand anderes ausgestellt hat ;-)

    Evgenij Smirnov

    http://evgenij.smirnov.de

    Montag, 27. Juli 2020 10:11
    |
  • Question
    Anmelden
    0
    Anmelden

    Oh,... ;-)

    Hier das Ergebnis vom Zertifikat eines anderes DC der gleichen AD. Die Zertifizierungsstelle liegt auf einem anderen DC:

    Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. Alle Rechte vorbehalten.

C:\Windows\system32>certutil -f -urlfetch -verify c:\temp\test.cer
Aussteller:
    CN=ttdatdom-SBS2011-SRV-CA
  Namenshash (sha1): 8fcaeaa88ecfbd247367ff408dea0692ce62c969
  Namenshash (md5): a1c64c0c6cf00d22e45c87ae8d4669b5
Antragsteller:
    CN=Win2016-DC.ttdatdom.local
  Namenshash (sha1): 1bed47d0996fe046cc23a7b8760a799fcf01e0ce
  Namenshash (md5): a64c68780da1313bd125fdb40a3d1e1a
Zertifikatseriennummer: 1996ae1f00010000016d

dwFlags = CA_VERIFY_FLAGS_ALLOW_UNTRUSTED_ROOT (0x1)
dwFlags = CA_VERIFY_FLAGS_IGNORE_OFFLINE (0x2)
dwFlags = CA_VERIFY_FLAGS_FULL_CHAIN_REVOCATION (0x8)
dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN (0x20000000)
HCCE_LOCAL_MACHINE
CERT_CHAIN_POLICY_BASE
-------- CERT_CHAIN_CONTEXT --------
ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
ChainContext.dwRevocationFreshnessTime: 20 Hours, 30 Minutes, 41 Seconds

SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
SimpleChain.dwRevocationFreshnessTime: 20 Hours, 30 Minutes, 41 Seconds

CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=0
  Issuer: CN=ttdatdom-SBS2011-SRV-CA
  NotBefore: 23.12.2019 06:24
  NotAfter: 22.12.2020 06:24
  Subject: CN=Win2016-DC.ttdatdom.local
  Serial: 1996ae1f00010000016d
  SubjectAltName: Anderer Name:DS-Objekt-Guid=04 10 aa 3d ea 0e bf 2b ca 41 83 f
4 48 8d f3 b1 82 29, DNS-Name=Win2016-DC.ttdatdom.local
  Template: DomainController
  2b56b67fb32ca589c47edbc2a96b21ec3a08ac23
  Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
  Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
  ----------------  Zertifikat abrufen  ----------------
  Überprüft "Zertifikat (0)" Zeit: 0
    [0.0] ldap:///CN=ttdatdom-SBS2011-SRV-CA,CN=AIA,CN=Public%20Key%20Services,C
N=Services,CN=Configuration,DC=ttdatdom,DC=local?cACertificate?base?objectClass=
certificationAuthority

  ----------------  Zertifikat abrufen  ----------------
  Überprüft "Basissperrliste (0be9)" Zeit: 0
    [0.0] ldap:///CN=ttdatdom-SBS2011-SRV-CA(1),CN=SBS2011-SRV,CN=CDP,CN=Public%
20Key%20Services,CN=Services,CN=Configuration,DC=ttdatdom,DC=local?certificateRe
vocationList?base?objectClass=cRLDistributionPoint

  Abgelaufen "Deltasperrliste (0be9)" Zeit: 0
    [0.0.0] ldap:///CN=ttdatdom-SBS2011-SRV-CA(1),CN=SBS2011-SRV,CN=CDP,CN=Publi
c%20Key%20Services,CN=Services,CN=Configuration,DC=ttdatdom,DC=local?deltaRevoca
tionList?base?objectClass=cRLDistributionPoint

  ----------------  Basissperrliste veraltet  ----------------
  Abgelaufen "Deltasperrliste (0be9)" Zeit: 0
    [0.0] ldap:///CN=ttdatdom-SBS2011-SRV-CA(1),CN=SBS2011-SRV,CN=CDP,CN=Public%
20Key%20Services,CN=Services,CN=Configuration,DC=ttdatdom,DC=local?deltaRevocati
onList?base?objectClass=cRLDistributionPoint

  ----------------  Zertifikat-OCSP  ----------------
  Keine URLs "Keine" Zeit: 0
  --------------------------------
    CRL 0be9:
    Issuer: CN=ttdatdom-SBS2011-SRV-CA
    ThisUpdate: 23.07.2020 16:45
    NextUpdate: 31.07.2020 05:05
    19b93adce34460c6a96f6c1d63129119b5194080
    Delta CRL 0bec:
    Issuer: CN=ttdatdom-SBS2011-SRV-CA
    ThisUpdate: 26.07.2020 16:45
    NextUpdate: 28.07.2020 05:05
    9937f500308edd32f837d2c1019a1546c64433eb
  Application[0] = 1.3.6.1.5.5.7.3.2 Clientauthentifizierung
  Application[1] = 1.3.6.1.5.5.7.3.1 Serverauthentifizierung

CertContext[0][1]: dwInfoStatus=10c dwErrorStatus=0
  Issuer: CN=ttdatdom-SBS2011-SRV-CA
  NotBefore: 27.04.2017 11:55
  NotAfter: 27.04.2022 12:05
  Subject: CN=ttdatdom-SBS2011-SRV-CA
  Serial: 5e7dcaa9772366a44f00ed49a9229617
  e862bbafd7b476da4fb74a62878820318226f7b8
  Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
  Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)
  Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
  ----------------  Zertifikat abrufen  ----------------
  Keine URLs "Keine" Zeit: 0
  ----------------  Zertifikat abrufen  ----------------
  Keine URLs "Keine" Zeit: 0
  ----------------  Basissperrliste veraltet  ----------------
  Abgelaufen "Deltasperrliste (0be9)" Zeit: 0
    [0.0] ldap:///CN=ttdatdom-SBS2011-SRV-CA(1),CN=SBS2011-SRV,CN=CDP,CN=Public%
20Key%20Services,CN=Services,CN=Configuration,DC=ttdatdom,DC=local?deltaRevocati
onList?base?objectClass=cRLDistributionPoint

  ----------------  Zertifikat-OCSP  ----------------
  Keine URLs "Keine" Zeit: 0
  --------------------------------
    CRL 0be9:
    Issuer: CN=ttdatdom-SBS2011-SRV-CA
    ThisUpdate: 23.07.2020 16:45
    NextUpdate: 31.07.2020 05:05
    19b93adce34460c6a96f6c1d63129119b5194080
    Delta CRL 0bec:
    Issuer: CN=ttdatdom-SBS2011-SRV-CA
    ThisUpdate: 26.07.2020 16:45
    NextUpdate: 28.07.2020 05:05
    9937f500308edd32f837d2c1019a1546c64433eb

Exclude leaf cert:
  bf7cda11c17c17cca17e68b3514ea9badbbc978b
Full chain:
  52ba42e6b1621ba974a172e634e74389fe0c2a89
------------------------------------
Verfizierte Ausstellungsrichtlinien: Kein
Verfizierte Anwendungsrichtlinien:
    1.3.6.1.5.5.7.3.2 Clientauthentifizierung
    1.3.6.1.5.5.7.3.1 Serverauthentifizierung
Sperrstatussüberprüfung des untergeordneten Zertifikats erfolgreich abgeschlosse
n.
CertUtil: -verify-Befehl wurde erfolgreich ausgeführt.

C:\Windows\system32>

    Ich habe mir auch Mal die SCP im AD für das Autodiscover angesehen. Es ist tatsächlich so, wie von Dir vermutet. Der alte SBS2011 steht dort vor dem neuen Win2016-DC, "S" kommt eben vor "W" wenn es da nach dem Namen geht, dehalb wird zuerst ewig nach dem nicht mehr existierenden SVBS2011 gesucht, bis es mit dem neuen "Win2016-FS" weitergeht. Weisst Du, ob man das irgendwie ändern kann?

    Viele Grüße,

    Heiko

    Heiko

    Montag, 27. Juli 2020 11:25
    |
  • Question
    Anmelden
    0
    Anmelden

    Moin,

    Re SCP: Wenn der dazugehörige Exchange nicht mehr ist, einfach im AD bearbeiten :-)

    Evgenij Smirnov

    http://evgenij.smirnov.de

    Montag, 27. Juli 2020 11:48
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Evgenij,

    Noch existiert ja der alte SBS2011. Nur wollte ich ja testen, was passsiert, wenn er nicht mehr da ist.

    Wäre es vielleicht auch möglich, den url-Aufruf vom alten SBS2011 mittels des Befehls:

    Set-ClientAccessServer -Identity sbs2011 -AutoDiscoverServiceInternalUri https://Win2016-FS.ttdatdom.local/Autodiscover/Autodiscover.xml

    den gleiche Aufruf zu verpassen, den der neue Exchange Server 2016 auf dem Win2016-fs hat?

    Viele Grüße

    Heiko Witt

    Heiko

    Montag, 27. Juli 2020 14:39
    |
  • Question
    Anmelden
    0
    Anmelden
    Ja, wenn der Exchange vom SBS noch lauffähig ist, wäre das genau die richtige Vorgehensweise.

    Evgenij Smirnov

    http://evgenij.smirnov.de

    Montag, 27. Juli 2020 14:56
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Evgenij,

    Ich habe gestern zum Feierabend desn URL-Aufruf des alten Exchange Server 2010 vom SBS2011 auf den gleichen Wert, wie den neuen exchange Server 2016 gegegeben und dann den alten SBS2011 Server vom Netzwerk getrennt.
    Bisher läuft alles ohne Probleme.
    Wenn es bis Anfang der nächsten Woche so bleibt, werde ich den alten Server dann endgültig entfernen und runterfahren können.

    Vielen Dank nochmals für Deine tolle Tipps und Hilfe.

    Viele Grüße,

    Heiko Witt

    Heiko

    Mittwoch, 29. Juli 2020 07:36
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo,

    Ich hatte gehofft, das das leidige Problem mit den Zertifikaten nach dem Umzug auf den neuen Server erledigt ist. Leider ist dem nit so.

    Seit Ende Juli lief die neue Serverumgebug meiner Ansicht nach ohne Problem und stabil. Nachdem der alte SBS2011 Server durch einen Hardwaredefekt Ende Juli nun doch ausgefallen war.

    Zum Glück hatte ich alle Domainserverrollen für das Active Direktory, die Zertifizierungsstelle und den Exchange Server geschafft vorher auf neue Server zu migrieren.

    Ich hatte sogar den Eindruck, dass das Netzwerk stabiler lief als bisher. Keine Verbindungprobleme von Ouloiok mit dem Exchange Server mehr mit wegen Autosicover ua.

    Jetzt habe ich zum Ende des Jahres festgestellt, dass das "selbsterstellte" Zertifikat des PDC und Exchangeservers in wenigen Tagen ausläuft.

    Dieses wollte ich verlängern. Erhielt aber bei versuch der die fehlermeldung, dass der Zertifizierungsserver nicht errichbar ist oder dieser keine passende Vorlage enthält.

    Da habe ich die nach langer Zeit den die Zertifizierungsstelle gestrtet und wollte mir die Vorlagen ansehen. Leider erhalte ich dann folgendes Bild.Wenn ich versuche über das Kontextmenür "Neu -> Auszustellende Zertifikatvorlagen" auszuwählen, um die fehlenden Zertifikatvorlagen hizuzufügen, so geht das nicht, da dieser menüpunkt ausgegraut ist und damit nicht anwählbar ist.

    Gehe ich aber auf den Menüpunkt "Verwalten" und wähle den "schreibbaren Domaincontroller herstellen" aus, so werden mir die Vorlagen des DC mit der Zertifizierungsstelle angezeigt.

    Nur nutzen tut er diese eben nicht.Hat vielleicht jemand eine Idee, was da kapuitt gegangen ist, und wie das reparieren kann?

    Den einzigen Hinweis, den ich dazu in den Ereignisprotokollen gefunden habe war folgender:

    - System
    - Provider
    [ Name] Microsoft-Windows-CertificationAuthority
    [ Guid] {6A71D062-9AFE-4F35-AD08-52134F85DFB9}
    EventID 134
    Version 0
    Level 4
    Task 0
    Opcode 0
    Keywords 0x8000000000000000
    - TimeCreated
    [ SystemTime] 2020-12-18T09:19:10.803245100Z
    EventRecordID 33242
    Correlation
    - Execution
    [ ProcessID] 8744
    [ ThreadID] 11216
    Channel Application
    Computer Win2012-CADC.ttdatdom.local
    - Security
    [ UserID] S-1-5-18
    - EventData
    CACommonName ttdatdom-SBS2011-SRV-CA
    ErrorCode Ein erforderliches Zertifikat befindet sich nicht im Gültigkeitszeitraum gemessen an der aktuellen Systemzeit oder dem Zeitstempel in der signierten Datei. 0x800b0101 (-2146762495 CERT_E_EXPIRED)
    CACertIdentifier 0

    gefolgt von dem fehler:

    - System
    - Provider
    [ Name] Microsoft-Windows-CertificationAuthority
    [ Guid] {6A71D062-9AFE-4F35-AD08-52134F85DFB9}
    EventID 44
    Version 0
    Level 2
    Task 0
    Opcode 0
    Keywords 0x8000000000000000
    - TimeCreated
    [ SystemTime] 2020-12-18T09:19:10.865751700Z
    EventRecordID 33243
    Correlation
    - Execution
    [ ProcessID] 8744
    [ ThreadID] 11216
    Channel Application
    Computer Win2012-CADC.ttdatdom.local
    - Security
    [ UserID] S-1-5-18
    - EventData
    PolicyModuleDescription Windows-Standard
    MethodName Initialize
    ErrorCode 0x80070490 (1168)
    param4 Die erforderlichen Active Directory-Informationen konnten von den Active Directory-Zertifikatdiensten nicht gefunden werden.
    ErrorString

    Element nicht gefunden.

    Ehlich gesagt, bin ich ratlos, wie ich das wieder hinbekommen soll.

    mit vielen Grüßen,

    Heiko Witt

    Heiko

    Freitag, 18. Dezember 2020 10:22
    |