Sektion 24: Device Configuration: Wi-Fi, VPN & Certificates

Einleitung: Konnektivität ist das Fundament jedes Managed Device

Bevor ein Gerät eine einzige Richtlinie empfängt, bevor ein Compliance-Status ausgewertet wird, bevor auch nur ein App-Deployment startet – muss das Gerät verbunden sein. Wi-Fi, VPN und Zertifikate sind die unsichtbare Infrastruktur jedes modernen Device Managements. Sie sind zugleich das Fachgebiet, auf dem die meisten Intune-Implementierungen in der Praxis scheitern – nicht weil Intune hier schwach wäre, sondern weil hier Netzwerktechnik, Kryptografie, Public Key Infrastructure und Cloud-Management aufeinandertreffen.

In dieser Sektion gehen wir deutlich tiefer als der Standard-Lehrstoff. Du lernst nicht nur, wo du in Intune ein Wi-Fi-Profil anlegst, sondern verstehst die vollständige Logik dahinter: Wie EAP-TLS wirklich funktioniert, wie die Zertifikatkette vom Root CA bis zum Client aufgebaut wird, wie SCEP und NDES zusammenarbeiten, wann PKCS die bessere Wahl ist, und wie du VPN-Profile so konfigurierst, dass sie im Feld zuverlässig funktionieren – inklusive Always On VPN, Microsoft Tunnel und zertifikatsbasierter Authentifizierung.

Grundkonzepte: Die drei Säulen der gerätebasierten Konnektivität

1. Wi-Fi-Profile: Struktur und EAP-Verfahren

Ein Wi-Fi-Profil in Intune ist letztlich nichts anderes als ein XML- oder JSON-Dokument, das an das Gerät übergeben und dort in die native Netzwerkkonfiguration injiziert wird. Für Windows wird ein WLAN-Profil im WCM-Schema erzeugt, für iOS/macOS in eine Konfigurationspllist (Configuration Profile), für Android in ein DevicePolicyManager-Objekt. Intune abstrahiert das für dich – aber du musst verstehen, was unter der Haube passiert, wenn Fehler auftreten.

Die entscheidende Weichenstellung ist die Wahl des Sicherheits- und Authentifizierungsverfahrens:

• WPA2/WPA3-Personal (PSK): Ein gemeinsames Passwort. Für Enterprise-Umgebungen praktisch tabu, aber Intune unterstützt es – inklusive der Möglichkeit, den Pre-Shared Key dynamisch über Gerätenamen oder Variablen zu generieren.
• WPA2/WPA3-Enterprise (802.1X): Serverseitige Authentifizierung über RADIUS (NPS, Aruba ClearPass, Cisco ISE, FreeRADIUS). Hier entscheidest du dich für ein EAP-Verfahren: EAP-TLS (zertifikatsbasiert, Goldstandard), EAP-TTLS/PAP oder PEAP-MSCHAPv2 (benutzername-/passwortbasiert).

Die Experten-Empfehlung ist eindeutig: EAP-TLS. Nur EAP-TLS eliminiert Passwörter aus dem Authentifizierungsfluss vollständig, unterstützt Machine-Authentifizierung (das Gerät authentifiziert sich, bevor sich ein Benutzer anmeldet) und ist Voraussetzung für saubere Szenarien wie Wi-Fi in OOBE oder kiosk-ähnlichen Setups.

2. Zertifikatprofile: Die Kryptografie hinter Konnektivität

Zertifikate sind der Klebstoff zwischen Wi-Fi, VPN und Zero Trust. Intune kennt vier relevante Zertifikatprofiltypen:

• Vertrauenswürdiges Zertifikat (Trusted Certificate Profile): Verteilt das Root-CA- und ggf. Intermediate-CA-Zertifikat in den geräteseitigen Vertrauensspeicher. Pflicht vor jedem SCEP- oder PKCS-Profil.
• SCEP (Simple Certificate Enrollment Protocol): Das Gerät generiert selbst ein Schlüsselpaar, der private Schlüssel verlässt das Gerät nie. Der Enrollment-Flow läuft über den Intune Certificate Connector → NDES → deine CA. Der Goldstandard für Gerätezertifikate.
• PKCS #12: Das Zertifikat inklusive privatem Schlüssel wird importiert und auf das Gerät ausgeliefert (typisch: Import aus einem PFX, oft aus einem Entrust- oder digicert-Connector oder via Intune PFX-Zertifikatconnector mit einer Dateifreigabe). Wichtig, wenn Zertifikate außerhalb von SCEP ausgestellt werden.
• Abgeleitete Zertifikate: Spezialfall für Online-SCEP auf Android-Enterprise-Geräten, die auf bestehende SCEP-Profile basieren – heute selten.

Das Herzstück ist die Zertifikatkette. Damit EAP-TLS gegen einen RADIUS-Server funktioniert, müssen auf dem Gerät drei Dinge gleichzeitig stimmen:

1. Das Root-CA-Zertifikat ist im Trusted-Store des Geräts (via Trusted Certificate Profile).
2. Der RADIUS-Server präsentiert ein Serverzertifikat, das von genau dieser Chain signiert ist – und die im Wi-Fi-Profil konfigurierten Trusted Server Certificate Names und die Zertifizierungsstellen-Hashes (Schwellenwert-Validierung) stimmen mit dem Serverzertifikat überein.
3. Das Client-Gerät besitzt ein eigenes Client-Zertifikat (via SCEP/PKCS), dessen EKU (Enhanced Key Usage) Client-Authentifizierung (OID 1.3.6.1.5.5.7.3.2) enthält und dessen SAN-Format der RADIUS-Regel entspricht (UPN für User-Zertifikate, DNS-Name für Device-Zertifikate).

Scheitert einer dieser drei Punkte, siehst du im Wi-Fi-Log des Clients nur „Authentifizierung fehlgeschlagen“ – ohne Hinweis, welcher der drei Schritte kaputt ist. Genau deshalb behandeln wir Troubleshooting später so ausführlich.

3. VPN-Profile: Vom einfachen Tunnel zu Always On

Intune kann native VPN-Clients von Windows, iOS, macOS und Android konfigurieren und über die Platform-Optionen auch Drittanbieter-Clients (Cisco AnyConnect, Palo Alto GlobalProtect, FortiClient, SonicWall, Check Point, Zscaler und weitere) mit geräteseitigen Profilen versorgen. Die zentralen Konzepte:

• Verbindungsart: IKEv2, L2TP, SSTP, Automatic (Windows), plus herstellerspezifische Typen.
• Authentifizierung: Benutzername/Passwort, Zertifikate, abgeleitete Zertifikate oder modern: EAP-TLS in Kombination mit Conditional Access.
• Always On / Trusted Network Detection: Der Tunnel baut sich automatisch auf und nur ab, wenn sich das Gerät außerhalb des Firmennetzes befindet – die Basis für Zero-Trust-Konnektivität ohne Benutzerinteraktion.
• Microsoft Tunnel: Intunes eigener Linux-basierter VPN-Gateway (MobiTunnels), speziell für iOS und Android Enterprise, betrieben in Docker auf einem Linux-Host. Für mobile Geräte ist das oft die sauberste Lösung, weil er Conditional Access und App-basierte Tunnel-Regeln (per-App VPN) direkt aus Intune heraus unterstützt.

Praxis-Implementierung: Schritt für Schritt zum produktiven Setup

Schritt 1: Die PKI vorbereiten

Bevor du Intune auch nur öffnest, brauchst du eine funktionierende AD CS-PKI (oder eine Drittanbieter-CA) mit drei Elementen:

• Root-CA, die auf allen Clients vertrauenswürdig sein wird (Online- oder Offline-Root – empfohlen: Offline-Root, ausgelagerte Intermediate).
• Eine Issuing CA, die Zertifikate per Network Device Enrollment Service (NDES) ausstellt.
• Eine Zertifikatvorlage mit sinnvollen Parametern: EKU Client-Authentifizierung (und Server-Authentifizierung, falls die CA auch RADIUS-Serverzertifikate signiert), SAN aus AD (UPN bzw. DNS-Name), Key Length RSA 2048 oder ECDSA P-256, Gültigkeitsdauer für Gerätezertifikate idealerweise 12 Monate, Exportable = nein bei SCEP (der private Schlüssel bleibt auf dem Gerät).

Wichtig, oft übersehen: In der Zertifikatvorlage muss unter „Subject Name“ die Option „Build from this Active Directory information“ stehen und der NDES-Dienstaccount (der Intune Certificate Connector läuft mit dessen Kontext) muss Enroll-Rechte auf der Vorlage haben.

Schritt 2: Den Intune Certificate Connector installieren

Der Intune Certificate Connector (Nachfolger des separaten NDES-Connectors und des PFX-Connectors, heute als „Microsoft Intune Certificate Connector“ vereint) wird auf einem Windows-Server installiert, der NDES-Server ist und Zugriff auf die CA hat. Die Installation läuft über den Microsoft Intune-Connector-Installer, den du im Azure-Portal herunterlädst (Intune → Tenant Administration → Connectors and tokens → Certificate Connectors).

Nach der Installation öffnest du das Connector-UI-Tool, meldest dich mit einem Intune-Administrator-Konto an und prüfst, dass der Connector als „Healthy“ erscheint. Fehler hier sind fast immer Proxy-, SSL-Inspection- oder Firewall-Themen – der Connector spricht mit *.manage.microsoft.com, cert.manage.microsoft.com und NDES über TCP 443/636.

Schritt 3: Trusted Certificate Profile ausrollen

In Intune: Devices → Configuration → Create → New Policy → Platform „Windows 10 and later“ → Profile „Trusted certificate“. Lade die exportierte Root-CA (.cer, Base64) hoch und optional ein zweites Profil für die Intermediate CA. Weise das Profil der Zielgruppe zu und prüfe den Report: bei SCEP-Fehlern ist die Ursache in einem Drittel der Fälle ein fehlendes oder falsches Trusted Cert Profile.

Schritt 4: SCEP-Profil konfigurieren

Das SCEP-Zertifikatprofil ist das technisch anspruchsvollste Profil in Intune. Die kritischen Felder im Detail:

• Certificate type: „Device“ (Authentifizierung als Maschine, SAN = DNS-Hostname) oder „User“ (SAN = UPN). Für Wi-Fi mit Machine-Authentifizierung: Device. Für VPN mit User-Authentifizierung: User – oder bei EAP-TLS für Geräte mit Zertifikat: beides.
• Subject name format: z.B. CN={{DeviceName}} oder CN={{AAD_Device_ID}} für Device-Zertifikate bzw. {{UserName}}/{{UPN}} für User-Zertifikate.
• SAN: UPN ({{UserPrincipalName}}) oder DNS ({{DeviceName}}.deinedomain.de). Der SAN muss exakt der Policy-Regel im NPS/RADIUS entsprechen – ein UPN-Format-Mismatch hier ist DER klassische Fehler.
• Certificate Authority: Wähle im SCEP-Profil die CA aus, die über den Connector erreichbar ist (der Discovery-Flow listet deine CAs auf). Tipp: Wenn deine CA hier nicht auftaucht, prüfe, ob der NDES-Registrierungs-Endpunkt (/certsrv/mscep/) erreichbar ist und der Connector die CA-Enumeration schafft.
• Key usage und EKU: Digital Signature + Key Encipherment; EKU Client Authentication. Für VPN-Serverzertifikate zusätzlich Server Authentication.
• Renewal threshold: 20% ist ein guter Startwert; das bedeutet, dass bei 20% Restlaufzeit automatisch erneuert wird – praktisch für Wi-Fi, weil das Gerät dann nicht plötzlich offline fällt, wenn ein Zertifikat abläuft.

Schritt 5: Das Wi-Fi-Profil für WPA2-Enterprise erstellen

Devices → Configuration → Create → Platform deiner Wahl (hier: Windows) → Profile „Wi-Fi“. Die Konfiguration für EAP-TLS:

• Wi-Fi type: Enterprise; SSID: z.B. CORP-WIFI; Connect automatically: Yes.
• Wi-Fi type security: WPA2-Enterprise (bzw. WPA3-Enterprise, wenn deine Infrastruktur es hergibt).
• EAP type: EAP-TLS.
• Authentication method: Client certs, und dann wählst du aus dem SCEP-Profil – Intune zeigt dir hier automatisch die Zertifikatprofile zur Auswahl an, die die passende EKU haben.
• Trusted server certificate names: exakter CN des RADIUS-Server-Zertifikats, z.B. radius.corp.deinedomain.de. Wildcards sind nicht erlaubt – nur exakte Einträge. Alternativ (oder zusätzlich): Certificate server names mit Hash-Validierung über „Certificate hashes“ (die Fingerabdrücke der Chain). Wenn hier ein Wert falsch ist, lehnt der Client die Verbindung ab, bevor überhaupt Client-Zertifikate fließen.
• Identity privacy: optional, wenn der RADIUS die anonyme Identität unterstützt.

Für die Zielgruppenzuweisung gilt bei gerätebasierten Szenarien: Nutze gerätebasierte Filterung, nicht benutzerbasierte – ein Wi-Fi-Profil mit Device-Zertifikat, das nur über eine User-Gruppe zugewiesen wird, funktioniert nur, wenn der Benutzer sich mindestens einmal angemeldet hat. Für Zero-Touch-OOBE-Szenarien brauchst du Gerätegruppen (oder dynamische Gruppen mit Geräten aus Autopilot).

Schritt 6: VPN-Profil mit Always On und EAP-TLS

Für Windows 10/11 legst du ein VPN-Profil mit Baseline „VPN“ an. Beispielkonfiguration für Always On mit IKEv2 und Zertifikaten:

• Connection type: IKEv2.
• Connection name: CorpVPN; Servers: vpn.corp.deinedomain.de.
• Authentication method: „Certificates“ → SCEP-Client-Zertifikat auswählen. Alternativ „Username and password“ oder „Derived credential“.
• Always On: Enable. Conditional trigger: bei „Trusted network detection“ die DNS-Suffix deines internen Netzes eintragen (z.B. corp.deinedomain.de) – nur dann bleibt der Tunnel deaktiviert, solange der Client im Firmennetz ist.
• Remember credentials: No (bei Zertifikaten irrelevant, aber sauber).

Du kannst dasselbe Profil auch als OMA-URI Custom Profile anlegen, wenn du Features brauchst, die die UI nicht abbildet. Beispiel für Always On mit Traffic Filter:

<Replace>
  <Item>
    <Target>
      <LocURI>./Device/Vendor/MSFT/VPNv2/CorpVPN/ProfileXML</LocURI>
    </Target>
    <Data><![CDATA[<VPNProfile>
      <NativeProfile>
        <Servers>vpn.corp.deinedomain.de</Servers>
        <NativeProtocolType>IKEv2</NativeProtocolType>
        <Authentication>
          <MachineMethod>Certificate</MachineMethod>
        </Authentication>
        <RoutingPolicyType>SplitTunnel</RoutingPolicyType>
      </NativeProfile>
      <AlwaysOn>true</AlwaysOn>
      <RememberCredentials>false</RememberCredentials>
      <TrustedNetworkDetection>corp.deinedomain.de</TrustedNetworkDetection>
    </VPNProfile>]]></Data>
  </Item>
</Replace>

Schritt 7: Prüfung mit PowerShell (Graph API)

Im Masterclass-Betrieb willst du Profile nicht nur klicken, sondern prüfen, versionieren und automatisieren. Der Microsoft Graph Beta-Endpoint bietet volle CRUD-Funktionalität für DeviceManagementConfigurationProfiles. Beispiel: alle Wi-Fi-Profile eines Tenants abrufen und deren Status auswerten:

# Verbindung zu Graph herstellen
Connect-MgGraph -Scopes "DeviceManagementConfiguration.Read.All"

# Alle Wi-Fi-Profile abrufen
$wifiProfiles = Get-MgBetaDeviceManagementConfigurationPolicy `
    -Filter "templateReference/TemplateFamily eq 'wifi'" `
    -ExpandProperty Assignments

$wifiProfiles | ForEach-Object {
    [PSCustomObject]@{
        Name        = $_.Name
        Platforms   = ($_.Platforms | ForEach-Object { $_.PolicyPlatformType }) -join ", "
        Assigned    = if ($_.Assignments.Count -gt 0) { "Yes" } else { "NO - unassigned!" }
        LastModified= $_.LastModifiedDateTime
    }
}

Und ein Beispiel, wie du den Gerätestatus eines Zertifikatprofils auswertest:

Get-MgBetaDeviceManagementConfigurationPolicyDeviceStateSummary -DeviceManagementConfigurationPolicyId $profile.Id

So kannst du in einem Tenant mit 5000 Geräten in Sekunden feststellen, wo ein Profil failed statt succeeded ist – anstatt 50 Einzelscreens durchzuklicken.

Best Practices: Was Profis anders machen

Zertifikat-Design

• Separate Zertifikate pro Zweck: Kein „Universalmasterzertifikat“. Nutze getrennte SCEP-Profile für Wi-Fi-Device-Auth und VPN-User-Auth, ggf. mit getrennten Templates und EKUs. Das reduziert die Angriffsfläche und macht Fehlersuche trivial.
• SAN-Format dokumentieren: Halte in deinem Runbook fest, welches SAN-Format (UPN vs. DNS vs. RFC822) du für welchen RADIUS-Connector konfiguriert hast. Bei Migrationen (z.B. Domain-Änderung, UPN-Änderung) bist du so in Minuten wieder einsatzbereit.
• Keine 4096-Bit-RSA-Zertifikate für mobile Geräte: Die Schlüsselgenerierung auf iOS-Hardware kann bei SCEP zu Timeouts führen. RSA 2048 oder ECDSA P-256 ist ausreichend und deutlich robuster.
• Renewal-Strategie: Setze das Renewal Threshold auf 20-25% und plane, dass Geräte, die 3 Monate offline sind, trotzdem erneuern – überlege, ob eine Verlängerung über Wi-Fi nicht besser über LAN/VPN erfolgen sollte.

Wi-Fi-Design

• Trusted Server Certificate Names IMMER setzen: Ohne diese Validierung akzeptiert der Client jeden RADIUS-Server, der ein Zertifikat von irgendeiner vertrauenswürdigen CA präsentiert – ein Angriffspunkt ( Evil Twin / Rogue AP). Mit gesetzten Namen wird der Serverzertifikat-CN explizit geprüft.
• Wi-Fi-Profil in der OOBE: Für Autopilot-Szenarien ist ein gerätebasiertes Wi-Fi-Profil Gold wert – der Rechner verbindet sich direkt nach der Registrierung, bevor sich ein Benutzer anmeldet. Das erfordert durchgehend Device-Zertifikate und Machine-Authentifizierung auf dem RADIUS.
• Android: Nutz App-Config über managed Google Play, wenn du Third-Party-Wi-Fi-Apps nutzt – native WPA2-Enterprise auf Android erfordert SCEP mit passender EAP-Config und ist fehleranfälliger als auf iOS/Windows.

VPN-Design

• Always On mit Trusted Network Detection statt User-Tunnel-Denken: Der Tunnel soll sich selbst verwalten, nicht der User. Achte darauf, dass Split-Tunnel mit klaren Routen konfiguriert ist – Full-Tunnel aus der Cloud heraus ist ein Performance-Killer.
• Microsoft Tunnel für mobile Endpunkte evaluieren: Er ist leichtgewichtig, in Intune nativ integriert und unterstützt Conditional Access und per-App-VPN out of the box. Für iOS/Android ist er oft die eleganteste Lösung im Vergleich zu klassischen VPN-Gateways.
• VPN niemals mit Passwort-Auth in Produktion: Wenn schon VPN, dann zertifikatsbasiert mit EAP-TLS und idealerweise über einen Conditional Access „grant requires compliant device“-Filter abgesichert.

Troubleshooting: Wenn es brennt

Der systematische Ansatz

Wi-Fi-/VPN-/Zertifikatprobleme sind immer ein Kettenproblem. Prüfe in dieser Reihenfolge – nie springen:

1. Trusted Cert Profile angewendet? Im Intune-Report: „Succeeded“? Auf dem Windows-Client prüfen mit certlm.msc → Trusted Root Certification Authorities.
2. SCEP-Zertifikat vorhanden? Im selben MMC-Snap-in unter „Personal“. Wenn nein: SCEP-Request ist gescheitert – weiter zu Punkt 5.
3. Zertifikat korrekt? EKU, SAN, Issuer, Gültigkeit prüfen (Doppelklick → Details).
4. Wi-Fi-Profil auf dem Gerät? Windows: netsh wlan show profiles. Wenn das Profil fehlt: Assignment/Filter-Problem, nicht Zertifikat-Problem.
5. SCEP-Fehler auswerten: Ereignislog auf dem Client (Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider), Intune-Report zum Profil, und NDES-Logs auf dem Connector-Server (%ProgramFiles%\Microsoft Intune\NDESConnectorSvc\Logs).

Die häufigsten Fehlercodes und ihre Bedeutungen

• 0x87d1fde8 (Remediation failed): Das Profil wurde angewendet, aber die Auswertung schlug fehl. Bei Zertifikatprofilen meist ein nicht erreichbarer NDES-Endpunkt, falsche CA-Auswahl im Profil oder ein Zertifikat-Template-Problem (fehlende Enroll-Rechte).
• 0x87d1fde9: Der Client konnte SCEP nicht abschließen – häufig ein Challenge-Passwort-Mismatch, abgelaufene Challenge oder SSL-Inspection auf dem Proxy-Pfad zum NDES.
• Wi-Fi verbindet, trennt, verbindet (Loop): Klassiker bei RADIUS-Mismatch: Die Trusted Server Certificate Names im Profil stimmen nicht mit dem CN des NPS-Serverzertifikats überein, oder die NPS-Netzwerkrichtlinie erwartet ein anderes SAN-Format (UPN vs. DNS), als das Client-Zertifikat mitbringt.
• „Es kann keine Verbindung hergestellt werden“ bei EAP-TLS ohne sichtbaren Fehler: Auf dem NPS die Ereignisanzeige (Security-Log, Event 6273) prüfen – dort steht das exakte Reason-Code (z.B. „Certificate chain not trusted“, „No certificate in Smart Card“, „SAN mismatch“).
• VPN-Profil erscheint, verbindet aber nie: Prüfe, ob das Client-Zertifikat wirklich die richtige EKU hat und ob der VPN-Server das SCEP-Profil als Trusted Issuer akzeptiert. Bei IKEv2: RRAS-Eventlog auf dem Server prüfen, Fehlercodes 13806/13801 (Authentifizierungsfehler) verweisen direkt auf Zertifikatsprobleme.

Diagnostic-Skript für den Client

Dieses PowerShell-Snippet sammelt auf einem Windows-Client alle relevanten Beweise in einer einzigen Ausgabe – perfekt für den Support per Remote-Sitzung:

# Wi-Fi-Profile des Geräts
netsh wlan show profiles

# Details eines konkreten Profils inkl. Auth-Parameter
netsh wlan show profile name="CORP-WIFI"

# Alle Zertifikate im Machine-Store mit EKU Client Auth
Get-ChildItem Cert:\LocalMachine\My | ForEach-Object {
    $cert = $_
    if ($cert.EnhancedKeyUsageList.ObjectId -contains "1.3.6.1.5.5.7.3.2") {
        [PSCustomObject]@{
            Subject   = $cert.Subject
            Issuer    = $cert.Issuer
            NotAfter  = $cert.NotAfter
            SAN       = ($cert.DnsNameList | ForEach-Object { $_.Unicode }) -join ","
            Thumbprint= $cert.Thumbprint
        }
    }
}

# Trust chain prüfen: ist der Issuer im Root-Store?
$cert = Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.EnhancedKeyUsageList -match "1.3.6.1.5.5.7.3.2" } | Select-Object -First 1
if ($cert) {
    $chain = New-Object System.Security.Cryptography.X509Certificates.X509Chain
    $chain.Build($cert)
    $chain.ChainStatus | ForEach-Object { "{0}: {1}" -f $_.Status, $_.StatusInformation }
}

Dieses Skript gibt dir in 10 Sekunden: Profil vorhanden? Zertifikat da? SAN korrekt? Chain vertrauenswürdig? – die vier Fragen, die 90% aller Wi-Fi-EAP-TLS-Tickets beantworten.

Fazit

Wi-Fi, VPN und Zertifikate sind kein „Nice-to-have“-Kapitel im Intune-Curriculum – sie sind das Fundament, auf dem Compliance, Zero Trust und jedes App-Deployment steht. Wer hier schlampert, zahlt später mit Support-Tickets, Geräten, die aus dem Management fallen, und Sicherheitslücken, die ein Auditar unangenehm auffallen.

Die Kernaussagen dieser Sektion in Kurzform:

• EAP-TLS mit SCEP-Gerätezertifikaten ist der Goldstandard – kein Passwort im Authentifizierungsfluss, Machine-Auth für OOBE-Szenarien, saubere Erneuerung über Renewal Thresholds.
• Die Zertifikatkette muss auf drei Ebenen gleichzeitig stimmen (Client-Zertifikat, Server-Zertifikat, Trust-Store) – und die Fehlerursache ist nie auf dem ersten Blick sichtbar, weshalb systematisches Troubleshooting (Client → Profile → Connector → NDES → CA) zur Pflicht gehört.
• Trusted Server Certificate Names sind ein Sicherheitsfeature, kein lästiges Pflichtfeld – sie schützen vor Evil-Twin-Access-Points.
• VPN ohne Always On und Zertifikat-Authentifizierung ist Reparatur-Arbeit – konfiguriere Tunnels so, dass sie sich selbst verwalten, und sichere sie über Conditional Access ab.
• Automatisiere die Prüfung über Graph, sobald dein Tenant eine gewisse Größe erreicht hat – manuelles Durchklicken skaliert nicht.

In der nächsten Sektion bauen wir auf genau diesem Fundament auf und widmen uns den fortgeschrittenen Konfigurationsmechanismen von Intune: Konfigurationsplattformen, Einstellungs-Katalog, administrative Templates und die Kraft der ADMX-Backed Policies. Halte deine Zertifikate bereit – wir steigen tiefer ein.