MIGRATION · ADCS UND NDES
Den letzten Zertifikatsserver abschalten.
ADCS überlebt meist aus drei Gründen: NDES für Intune, Autoenrollment für domänengebundene PCs und die Kerberos-Zertifikate der Domänencontroller. SCEPman deckt alle drei aus deinem Azure-Tenant ab, sodass die CA, der CDP-Webserver und der NDES-Server wegfallen können, einen Anwendungsfall nach dem anderen.
- Kein NDES
- Gruppenrichtlinien-Autoenrollment ohne Client-Software
- Domänencontroller-Zertifikate
- Intermediate CA unter deiner bestehenden Root
VERGLEICH
Was der Betrieb von ADCS, NDES und SCEPman erfordert
Der Aufwand jeder Option, wie er in unserer Dokumentation beschrieben ist.
| Microsoft CA mit PKCS-Connector | NDES mit SCEP | SCEPman | |
|---|---|---|---|
| Einrichtung | 2 to 3 days and more: CRL-Verteilungspunkte, Templates, GPOs, Dienstkonten, Connector-Versionen | 2 more days and more: NDES-Server, einer pro Zertifikatstyp, zwei weitere Templates, schwer zu debuggen | under 30 minutes für den Kerndienst |
| Wartung | CDP-Monitoring, Connector-Monitoring, Betriebssystem-Updates | All das, plus manuelles Erneuern des Enrollment-Agent-Zertifikats | Health-Monitoring in Azure; App Service aktualisiert die Plattform |
| Sperrung | Manuell; die Suche in der CA-Datenbank ist aufwendig | Manuell | Automatisch über Entra ID, Intune und Jamf; manuell im Certificate Master |
| Verfügbarkeit | Mehrere Fehlerpunkte: Virtualisierung, OS, CDP-Webserver, Connector | Dasselbe, plus NDES | App Service, optional in zwei Regionen hinter dem Traffic Manager |
| Skalierung | Erfordert ein CA-Cluster, manuell | Redundante NDES-Server | Autoscaling oder wenige Klicks |
| Backup | CA-Datenbank, CA-Schlüssel und Konfiguration, regelmäßig | Dasselbe | Kerndienst zustandslos; Schlüssel im Key Vault; optionales Storage-Backup |
| Angriffsfläche | Ein Tier-0-Server kommuniziert über den Connector mit dem Internet | Eingehender Zugriff auf NDES, ein Tier-0-Asset | Entra-authentifizierte Endpunkte, Key Vault und Storage hinter privaten Endpunkten |
| MDMs | Nur Intune | Mehrere, jeweils mit einer eigenen NDES-Instanz | Intune, Jamf Pro und weitere MDMs |
ENTERPRISE EDITION · SEIT 3.0
Zertifikate für domänengebundenes Windows ohne ADCS
Windows-Clients in deiner Domäne wissen bereits, wie sie sich einschreiben: Die Gruppenrichtlinie verweist sie auf einen Enrollment-Dienst, Kerberos bestätigt ihre Identität, und das Autoenrollment erledigt den Rest. Der Active-Directory-Endpunkt von SCEPman ist genau dieser Dienst. Du registrierst einen Service Principal in deinem AD, richtest die Gruppenrichtlinie auf SCEPman aus, und Computer sowie Benutzer melden sich mit den in Windows integrierten Werkzeugen an. Auf den Clients muss nichts installiert werden.
- Templates für user, computer, RDP server and domain controller, jedes einzeln aktiviert.
- Clients erneuern selbstständig, wenn weniger als 20% der Gültigkeitsdauer verbleiben.
- Enrollment auf Mitglieder bestimmter AD-Gruppen beschränken.
- SCEPman fügt die SID-Extension hinzu, sodass die Zertifikate das starke Mapping erfüllen, das Domänencontroller seit KB5014754 vorschreiben.
KERBEROS
Zertifikate für deine Domänencontroller
Domänencontroller benötigen ein Kerberos-Authentifizierungszertifikat, damit Entra-gebundene und hybrid-gebundene Geräte auf lokale Ressourcen zugreifen können, und Windows Hello for Business im Hybrid-Key-Trust-Modus ist ebenfalls darauf angewiesen. SCEPman stellt es über das Domänencontroller-Template des Active-Directory-Endpunkts aus oder über den dedizierten DC-Endpunkt. Das Zertifikat enthält die Extended Key Usages Client Authentication, Server Authentication, Kerberos Authentication und Smart Card Logon.
KOEXISTENZ
SCEPman als Intermediate CA unter deiner Root einbinden
Du musst deine Root nicht von Anfang an ersetzen. In der Enterprise Edition kann SCEPman als Intermediate CA betrieben werden: Deine bestehende Root signiert das CA-Zertifikat von SCEPman, das in deinem Key Vault verbleibt. Geräte, die deiner Root vertrauen, vertrauen den Zertifikaten von SCEPman sofort, und du kannst Anwendungsfälle migrieren, solange ADCS die übrigen noch ausstellt.
Ein Migrationsweg in fünf Schritten
Stimme die Reihenfolge mit deinem Netzwerkteam ab: RADIUS-Server und VPN-Gateways müssen der neuen Root vertrauen, bevor das erste Gerät ein SCEPman-Zertifikat vorlegt.
- Root festlegenRoot festlegenEine neue SCEPman-Root, verteilt über MDM und Gruppenrichtlinie, oder SCEPman als Intermediate unter deiner aktuellen Root.
- SCEP-Profil hinzufügenSCEP-Profil hinzufügenEin neues SCEP-Profil in deinem MDM, das auf SCEPman zeigt, neben dem alten; das NDES-Profil entfernen, sobald die Geräte ihre neuen Zertifikate haben.
- Windows migrierenWindows migrierenDen Active-Directory-Endpunkt aktivieren und die Autoenrollment-Richtlinie Template für Template darauf ausrichten.
- Server migrierenServer migrierenServer-Zertifikate über Certificate Master, EST oder die API; Domänencontroller über ihr Template.
- ADCS außer Betrieb nehmenADCS außer Betrieb nehmenVerbleibende Zertifikate sperren, eine letzte CRL veröffentlichen und CA, CDP sowie NDES außer Betrieb nehmen.
Fragen zum Abkehren von ADCS
01Können SCEPman und ADCS parallel betrieben werden?
Ja. Es sind separate CAs; Geräte können während der Migration Zertifikate von beiden besitzen.
02Benötigen wir dafür die Enterprise Edition?
Für den Active-Directory-Endpunkt, Domänencontroller-Zertifikate, Certificate Master und die Intermediate CA: ja.
03Was ist mit Zertifikaten für Benutzer, die niemals mit deinem MDM in Berührung kommen?
Domänengebundene Benutzer erhalten ihre Zertifikate über den Active-Directory-Endpunkt; alle anderen über Certificate Master oder Self-Service-Enrollment.
04Muss SCEPman in unserem Netzwerk betrieben werden?
Nein. Clients erreichen SCEPman über HTTPS; der Active-Directory-Endpunkt authentifiziert sie per Kerberos über den Service Principal, den du registrierst.
Plane deinen Wechsel von ADCS.
Beginne mit deinem MDM und NDES, dem Teil, der am meisten Aufwand macht, und behalte ADCS, bis das letzte Template migriert ist.