Migration von ADCS zu Microsoft Cloud PKI in Intune

Von Mirko Peters · 2026-08-13

Erfahren Sie, wie Sie von der klassischen ADCS-Infrastruktur zu Microsoft Cloud PKI in Intune migrieren. Vereinfachen Sie die Geräteauthentifizierung, verzichten Sie auf NDES-Server und sichern Sie WLAN und VPN ab.

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

Die Migration von der klassischen Active Directory Certificate Services zu Microsoft Cloud PKI macht lokale Zertifikatconnectors, NDES-Server und komplexe Reverse-Proxy-Konfigurationen überflüssig. Indem Sie die Zertifizierungsstelle direkt in Microsoft Intune verlagern, können IT-Administratoren die Geräteauthentifizierung für Windows, macOS und mobile Geräte vereinfachen, ohne eigene Serverhardware betreiben zu müssen.

Das Wichtigste in Kürze

• Microsoft Cloud PKI ersetzt die lokale ADCS-Infrastruktur unter Windows Server durch eine cloudnative Zertifizierungsstelle, die direkt in Intune verwaltet wird.
• Die Migration beseitigt klassische Engpässe wie NDES-Server, interne Zertifikatconnectors und öffentlich erreichbare Reverse Proxys.
• Die Geräteauthentifizierung nutzt SCEP, um private Schlüssel auf verwalteten Laptops und mobilen Geräten zu erzeugen und abzusichern.
• Die Migration hilft Organisationen, gemeinsam genutzte WLAN-Kennwörter abzuschaffen und den Remotezugriff über VPN mit individuellen Gerätezertifikaten abzusichern.
• Eine sorgfältige Planung setzt voraus, die Intune-Lizenzberechtigungen zu prüfen und die Vertrauensketten der Root- und ausstellenden CAs vor dem Rollout zu validieren.

Die versteckten Infrastrukturkosten klassischer ADCS-Umgebungen

Jahrzehntelang nutzten Organisationen Windows Server und Active Directory Certificate Services, um ihre interne Public-Key-Infrastruktur zu betreiben. ADCS ist zwar robust, verursacht aber erheblichen Wartungsaufwand. Eine lokale Zertifizierungsstelle bedeutet, Serverbetriebssysteme zu verwalten, Patches einzuspielen, Hardware-Backups zu konfigurieren und Ablaufdaten im Blick zu behalten, damit es nicht zu folgenschweren Ausfällen am Montagmorgen kommt.

Hinzu kommt: Wenn cloudverwaltete mobile und remote genutzte Endgeräte an eine lokale CA angebunden werden sollen, steigt die architektonische Komplexität deutlich. Administratoren müssen Intune Certificate Connectors bereitstellen, NDES-Rollen (Network Device Enrollment Service) einrichten, Web Application Proxies für den externen Zugriff konfigurieren und sorgfältig Ausnahmen in den Unternehmensfirewalls schaffen. Für schlanke IT-Teams wird damit aus einer einfachen Anforderung wie zertifikatbasiertem WLAN eine dauerhafte betriebliche Belastung.

Wie Microsoft Cloud PKI die Unternehmensarchitektur vereinfacht

Microsoft Cloud PKI verlagert den Großteil der Zertifikatverwaltung aus lokalen Rechenzentren in die Microsoft Cloud. Statt Windows-Server-VMs bereitzustellen, können Administratoren im Microsoft Intune Admin Center direkt eine vollständig verwaltete Hierarchie aus Root CA und ausstellender CA einrichten. Microsoft schützt die zugrunde liegenden kryptografischen Schlüssel mit Hardware Security Modules (HSMs), ohne dass IT-Teams physische Sicherheitsgeräte installieren oder patchen müssen.

In diesem modernen Modell sind die Verantwortlichkeiten klar verteilt. Microsoft Entra ID verwaltet die Benutzeridentitäten, Intune steuert die Gerätekonformität und die Konfigurationsprofile, und Cloud PKI stellt die vertrauenswürdigen digitalen Zertifikate aus, die für den sicheren Netzwerkzugriff benötigt werden. Da der Dienst nativ in Intune integriert ist, erhalten Geräte ihre Zertifikate automatisch während der Registrierung, ohne manuelles Eingreifen durch Mitarbeitende oder Administratoren.

Ihre Migrationsstrategie entwickeln

Der Wechsel von einer etablierten ADCS-Umgebung erfordert einen methodischen, anwendungsfallorientierten Ansatz. Statt über Nacht eine unternehmensweite PKI-Transformation anzustoßen, konzentrieren sich erfolgreiche Migrationen auf ein einziges, konkretes Ziel.

1. Ihre erste Workload identifizieren

Wählen Sie für Ihre erste Pilotphase ein bestimmtes Problem aus, das Sie lösen möchten. Typische Ausgangspunkte sind der Austausch gemeinsam genutzter WLAN-Kennwörter durch eindeutige Gerätezertifikate, die Konfiguration einer zertifikatbasierten Authentifizierung für ein Unternehmens-VPN oder die Beschränkung des Zugriffs auf eine kritische interne Webanwendung, sodass nur verwaltete Firmenlaptops darauf zugreifen können.

2. Vertrauensketten und SCEP konfigurieren

Bevor Intune Gerätezertifikate ausstellt, muss es die erforderlichen Vertrauenszertifikate an Ihre Endpunkte verteilen. So erkennen die Clientgeräte Ihre neue Cloud-PKI-Stammzertifizierungsstelle und die ausstellenden Zertifizierungsstellen an. Sobald das Vertrauen hergestellt ist, verwenden die Geräte das Simple Certificate Enrollment Protocol (SCEP) als sicheren Anforderungsweg. Der Endpunkt erzeugt seinen privaten Schlüssel lokal, sodass das sensible kryptografische Geheimnis niemals das Netzwerk durchquert. Cloud PKI prüft die Anforderung über Intune und signiert das öffentliche Zertifikat.

3. Erneuerungs- und Widerrufsprozesse validieren

Bevor Sie den Rollout auf alle Benutzer ausweiten, testen Sie gründlich, wie sich Zertifikate in Ihrer Umgebung erneuern und widerrufen lassen. Cloud PKI und Intune automatisieren die Erneuerung von Zertifikaten im Hintergrund, bevor das Ablaufdatum erreicht ist. So kommt es nicht zu unerwarteten Zugriffsunterbrechungen. Stellen Sie außerdem sicher, dass Administratoren wissen, wie sie ein Zertifikat schnell widerrufen, wenn ein Gerät verloren geht, gestohlen wird oder einem Mitarbeiter zugewiesen ist, der das Unternehmen verlässt.

Fazit

Die Migration von einer klassischen Windows-Server-PKI zu Microsoft Cloud PKI ist ein großer Schritt nach vorn bei der Modernisierung der Sicherheit im Unternehmen. Durch den Wegfall lokaler Server, Connectors und Proxys kann Ihr IT-Team zertifikatbasierte Authentifizierung für WLAN, VPNs und interne Anwendungen nahtlos bereitstellen und den administrativen Aufwand deutlich senken. Eine ausführlichere Erklärung, wie diese cloudnativen Komponenten zusammenarbeiten, finden Sie in der vollständigen Folge: Die vollständige Folge anhören. Hören Sie rein, um praxisnahe Strategien zu entdecken, mit denen Sie den digitalen Arbeitsplatz Ihrer Organisation vereinfachen können.

Häufige Fragen

Ersetzt Microsoft Cloud PKI eine bestehende lokale ADCS-Umgebung vollständig?

Nein. Microsoft Cloud PKI ist speziell dafür konzipiert, Zertifikate für Intune-verwaltete Geräte auszustellen und zu verwalten. Es soll nicht jede Zertifikatslast in Ihrem Unternehmen ersetzen, etwa jene für nicht verwaltete Computer, isolierte Systeme, öffentlich erreichbare Webserver oder Appliances von Drittanbietern.

Welche Geräteplattformen unterstützt Microsoft Cloud PKI?

Cloud PKI unterstützt die wichtigsten Gerätesysteme, die über Microsoft Intune verwaltet werden, darunter Windows-Laptops und -Desktops, macOS-Geräte, iOS/iPadOS-Geräte und unterstützte Android-Endgeräte.

Wie werden private Schlüssel bei der Zertifikatregistrierung geschützt?

Endpunkte erzeugen ihre privaten Schlüssel lokal auf der Geräte-Hardware und speichern sie dort sicher. Über SCEP übermittelt das Gerät nur die öffentlichen Informationen, die für die Zertifikatsignatur erforderlich sind. So wird der private Schlüssel niemals offengelegt oder über das Netzwerk übertragen.

Benötige ich externe Zertifikat-Connectors für Cloud PKI?

Nein. Anders als bei klassischen lokalen PKI-Bereitstellungen, die NDES-Server und Intune Certificate Connectors erfordern, arbeitet Microsoft Cloud PKI vollständig als cloudverwalteter Dienst innerhalb von Intune. Proxyserver oder virtuelle Connector-Maschinen sind dadurch nicht mehr nötig.