ADCS und Intune — Gerätezertifikate end-to-end via NDES

Wie der SCEP-Weg von der eigenen CA bis aufs verwaltete Gerät wirklich läuft — und warum NDES das fragilste, am meisten exponierte Stück deiner PKI ist.

Kurzfassung vorab

NDES ist die Brücke, über die deine ADCS-Zertifikate auf Intune-verwaltete Geräte kommen — und gleichzeitig das gefährlichste Stück deiner PKI, weil es per Definition in der DMZ steht und SCEP-Requests aus dem halben Internet entgegennimmt. Meine klare Position: Wer NDES neu aufsetzt, prüft zuerst, ob PKCS-Connector oder Microsoft Cloud PKI denselben Zweck ohne exponierten Endpunkt erfüllen. Wenn NDES sein muss — etwa wegen geräteseitiger Schlüsselerzeugung oder Nicht-Windows-Plattformen —, dann nur mit eng geschnittenen Templates, denn ein NDES-Server mit einem zu großzügigen Template ist eine ESC1-Einladung mit Internet-Anbindung.

Abb. 1: Der vollständige Weg eines Gerätezertifikats — vom Intune-SCEP-Profil über NDES in der DMZ bis zur Issuing CA im internen Netz.

1. Was NDES eigentlich tut

NDES — Network Device Enrollment Service — ist die Microsoft-Implementierung von SCEP, dem Simple Certificate Enrollment Protocol. Ursprünglich für Netzwerkgeräte wie Router gedacht, die kein Domänenmitglied sind, ist es heute der Standardweg, um Intune-verwalteten Geräten Zertifikate aus einer eigenen ADCS zu geben. Der Clou: Das Gerät muss nicht in der Domäne sein und braucht keine direkte Sichtverbindung zur CA. Es spricht nur den SCEP-Endpunkt an, und NDES vermittelt nach innen zur Issuing CA.

Genau diese Vermittlerrolle macht NDES heikel. Der Endpunkt steht in der DMZ und ist von außen erreichbar — sonst könnten mobile Geräte ihn nicht nutzen. Ein Dienst, der von außen erreichbar ist und nach innen Zertifikate von der CA anfordert, ist ein lohnendes Ziel. Die einzige Schranke zwischen „beliebiges Gerät“ und „gültiges Zertifikat aus deiner internen CA“ ist die Challenge-Validierung über Intune.

2. Der SCEP-Ablauf Schritt für Schritt

Um NDES abzusichern, musst du verstehen, wer in diesem Tanz wem was glaubt. Der Ablauf hat sieben Stationen, und das Sicherheitsherz steckt in der Challenge.

Abb. 2: Der SCEP-Enrollment-Ablauf — die Challenge in Schritt 1, 2 und 4 entscheidet, ob NDES ein offenes Scheunentor oder ein kontrollierter Eingang ist.

Das Gerät bekommt von Intune ein SCEP-Profil samt einer signierten Challenge. Diese Challenge ist im Kern ein zeitlich begrenztes, an das Gerät gebundenes Geheimnis. Wenn das Gerät seinen CSR an NDES schickt, reicht es die Challenge mit. NDES — genauer der Intune Connector auf dem NDES-Server — validiert diese Challenge gegen Intune zurück, bevor es den CSR an die CA weiterreicht. Fällt diese Prüfung weg oder ist sie fehlkonfiguriert, wird NDES zur offenen Zertifikatsausgabe.

3. Brauchst du NDES überhaupt?

Bevor du einen NDES-Server in die DMZ stellst, lohnt die ehrliche Frage, ob es Alternativen gibt, die ohne exponierten Endpunkt auskommen. Microsoft bietet inzwischen mehrere Wege, Intune-Geräte mit Zertifikaten zu versorgen.

Abb. 3: NDES/SCEP, PKCS-Connector und Cloud PKI im Vergleich — die DMZ-Exposition ist das entscheidende Unterscheidungsmerkmal.

Meine Empfehlung für den Regelfall

Für reine Windows-Szenarien mit überschaubaren Anforderungen ist der PKCS-Connector oft die bessere Wahl: Er zieht Zertifikate ebenfalls aus deiner ADCS, braucht aber keinen von außen erreichbaren SCEP-Endpunkt. Für rein cloud-verwaltete Geräte, bei denen die Microsoft-Cloud als Quelle akzeptabel ist, kann Cloud PKI den NDES-Server komplett überflüssig machen. NDES bleibt die richtige Antwort, wenn du geräteseitige Schlüsselerzeugung brauchst, eine bunte OS-Landschaft inklusive iOS und Android bedienst oder einen Bestand hast, der bereits auf SCEP läuft.

4. NDES härten — Schicht für Schicht

Wenn NDES sein muss, dann richtig. Härtung läuft in Schichten von außen nach innen, und jede Schicht reduziert die Angriffsfläche eines Dienstes, der prinzipbedingt exponiert ist.

Abb. 4: Die fünf Verteidigungsschichten für NDES — Schicht 3, die eng geschnittenen Templates, ist die häufigste Audit-Lücke.

Mit PowerShell prüfst du die kritischste Schicht — ob die SCEP-Templates wirklich eng geschnitten sind und nirgends das gefährliche Flag zum freien Subject aus dem Request gesetzt ist:

Wenn die Spalte „SubjectAusRequest“ bei einem SCEP-Template auf True steht, hast du genau die ESC1-Konstellation an einem exponierten Dienst — und damit dringenden Handlungsbedarf. Das Subject sollte bei SCEP-Templates aus der Anforderung von Intune kommen, nicht frei vom Antragsteller wählbar sein.

5. Betrieb: der Connector als Single Point of Failure

Im laufenden Betrieb ist der Intune Connector auf dem NDES-Server die Komponente, die am häufigsten Ärger macht. Er muss seine Verbindung zu Intune halten, Challenges validieren und CSRs durchreichen. Fällt er aus oder läuft sein eigenes Zertifikat ab, bekommt kein Gerät mehr ein neues Zertifikat — und das fällt oft erst auf, wenn die ersten Geräte-Zertifikate ablaufen und Geräte aus dem WLAN oder VPN fliegen.

Deshalb gehört der Connector aktiv überwacht: Dienststatus, Verbindung zu Intune, und die Ablaufdaten der Connector-eigenen Zertifikate. Ein toter Connector ist ein schleichender Ausfall, der erst Wochen später als Welle abgelaufener Geräte-Zertifikate sichtbar wird.

Praxis-Beispiel: Musterwerk GmbH

Die Musterwerk GmbH wollte ihre rund 600 mobilen Geräte — Tablets in der Fertigung, Notebooks im Außendienst, dazu iOS-Smartphones — per Intune mit WLAN- und VPN-Zertifikaten aus der eigenen ADCS versorgen. Die erste Idee war ein klassischer NDES-Server. Im Health-Check fiel auf, dass das vorgesehene SCEP-Template das Subject aus dem Request zuließ — die berühmte ESC1-Konstellation, hier an einem geplanten DMZ-Dienst.

Wir haben zweierlei umgesetzt: Für die reinen Windows-Notebooks lief der PKCS-Connector, der ohne exponierten Endpunkt auskommt. Nur für die gemischte iOS- und Android-Flotte, die geräteseitige Schlüsselerzeugung verlangte, kam ein eng gehärteter NDES-Server zum Einsatz — eigene DMZ, App Proxy davor, dediziertes gMSA, ein SCEP-Template mit fester EKU und festem Subject aus der Intune-Anforderung, plus Connector-Monitoring. Statt eines fragilen NDES für alles gibt es jetzt den richtigen Weg je Geräteklasse, und die ESC1-Lücke ist gar nicht erst entstanden.

Verwandte Themen

Häufige Fragen (FAQ)

Wofür brauche ich NDES bei Intune überhaupt?

NDES ist der SCEP-Endpunkt, über den Intune-verwaltete Geräte Zertifikate aus deiner eigenen ADCS bekommen, ohne Domänenmitglied zu sein oder direkten CA-Zugriff zu haben. Es vermittelt aus der DMZ nach innen zur Issuing CA. Gebraucht wird es vor allem für geräteseitige Schlüsselerzeugung und gemischte OS-Landschaften wie iOS und Android.

Ist NDES ein Sicherheitsrisiko?

NDES ist prinzipbedingt exponiert, weil sein SCEP-Endpunkt von außen erreichbar sein muss. Das allein ist kein Drama, solange die Challenge-Validierung über Intune greift und die SCEP-Templates eng geschnitten sind. Gefährlich wird es, wenn ein Template das Subject aus dem Request zulässt — das ist ESC1 an einem von außen erreichbaren Dienst.

Gibt es eine Alternative zu NDES?

Ja, gleich zwei. Der PKCS-Connector zieht Zertifikate ebenfalls aus deiner ADCS, braucht aber keinen von außen erreichbaren Endpunkt und passt gut für Windows-Szenarien. Microsoft Cloud PKI kann den NDES-Server für reine Cloud-Geräte ganz überflüssig machen. Wer NDES neu plant, sollte beide zuerst prüfen.

Was ist die Challenge bei SCEP und warum ist sie wichtig?

Die Challenge ist ein zeitlich begrenztes, an das Gerät gebundenes Geheimnis, das Intune dem Gerät mitgibt und das NDES vor der Ausstellung gegen Intune validiert. Sie stellt sicher, dass nur ein von Intune autorisiertes Gerät ein Zertifikat bekommt. Ohne funktionierende Challenge-Prüfung wäre NDES eine offene Zertifikatsausgabe.

Wie härte ich NDES richtig ab?

In Schichten: eigene DMZ mit Reverse-Proxy davor, ein dediziertes gMSA mit minimalen Rechten, eng geschnittene SCEP-Templates mit fester EKU und festem Subject, erzwungene Challenge-Validierung und durchgängiges Audit-Logging. Die häufigste Lücke in Audits ist Schicht drei — zu großzügig konfigurierte Templates.

Warum bekommen meine Geräte plötzlich keine Zertifikate mehr?

Häufigste Ursache ist ein ausgefallener oder abgelaufener Intune Connector auf dem NDES-Server. Er validiert die Challenges und reicht CSRs durch; ist er tot, stoppt die Ausstellung lautlos. Das fällt oft erst Wochen später auf, wenn eine Welle von Geräte-Zertifikaten gleichzeitig die Erneuerung verpasst. Connector-Monitoring beugt dem vor.

Nächste Schritte mit boddenberg.de

NDES ist eines der Themen, bei denen ein falscher Klick im Template aus einem Komfort-Feature ein Einfallstor macht. Bevor der Server in die DMZ geht, lohnt sich ein prüfender Blick:

ADCS-Health-Check · Standortbestimmung deiner bestehenden PKI — inklusive Prüfung deiner SCEP-Templates auf die ESC1-Falle und der NDES-Exposition in der DMZ.

Architektur- oder Redesign-Workshop · Vom Ist-Zustand zur Zielarchitektur — hier fokussiert auf die Frage NDES, PKCS oder Cloud PKI und die passende Absicherung je Geräteklasse.

Implementierungs- oder Migrationsbegleitung · Beratung und technische Unterstützung beim Umsetzen — vom gehärteten NDES-Aufbau bis zum Connector-Monitoring im Betrieb.

Kontakt: Uli Boddenberg · boddenberg.de · Dortmund