Von der frisch installierten CA zur VSC- und Entra-CBA-fähigen PKI

Worum es geht

Im Artikel zum VSC-Wizard habe ich gezeigt, wie Benutzer und Admins ihre virtuelle Smartcard bekommen. Damit das funktioniert, muss die PKI vorbereitet sein. Dieser Artikel beschreibt den Weg von einer frisch installierten Enterprise CA bis zu dem Punkt, an dem der Wizard Zertifikate für On-Prem-Smartcard-Anmeldung und für Entra CBA ausstellen kann.

Wichtig vorweg: Das hier ist keine Best-Practice-Anleitung für den Aufbau einer Enterprise-PKI. Themen wie eine zweistufige Hierarchie mit Offline-Root, HSM, Schlüssellängen, Härtung, Backup und Notfallplan der CA lasse ich bewusst weg. Es geht um den pragmatischen Weg, mit einer vorhandenen (oder frisch installierten) Enterprise CA ans Ziel zu kommen: virtuelle Smartcards für die Anmeldung on-prem und an Entra. Wenn du eine PKI für den produktiven Betrieb neu aufbaust, nimm dir Zeit für eine saubere Planung.

Zielbild:

1. CA-Grundlagen: CDP und AIA zuerst

Bevor das erste Zertifikat ausgestellt wird, müssen die Sperrlisten-Pfade stimmen – CDP und AIA werden in jedes Zertifikat eingebrannt und lassen sich nachträglich nur durch Neuausstellung ändern.

• Ein HTTP-CDP mit einer URL, die auch von außen erreichbar ist. Am einfachsten ist die externe URL des Application Proxy aus Abschnitt 6, z. B. http://crl-contoso.msappproxy.net/CertEnroll/… – sie ist öffentlich auflösbar und funktioniert damit intern wie extern, ganz ohne eigene Domain und Split-DNS. Die App-Proxy-App also vor diesem Schritt anlegen. Wenn du lieber einen eigenen Namen willst (http://pki.contoso.com/…), brauchst du dafür eine Custom Domain im App Proxy. Nachträglich ändern heißt Zertifikate neu ausstellen.
• Der LDAP-CDP spielt für Entra CBA keine Rolle: Entra unterstützt nur HTTP/HTTPS, kein LDAP und kein OCSP, und nutzt ohnehin die URL, die im Trust Store (->Entra) pro CA hinterlegt ist. Für Domänen-Clients darf LDAP bleiben – Microsofts (ältere) Doku empfiehlt für AD-Clients sogar LDAP an erster Stelle. Wenn du viele Clients ohne Domänenzugriff hast, setz HTTP nach vorn.
• HTTP statt HTTPS für die CRL: Microsoft empfiehlt das für Entra CBA ausdrücklich, weil HTTPS eine zirkuläre Abhängigkeit bei der Zertifikatsprüfung erzeugen kann.

# Example - adjust the host name (external App Proxy URL from section 6)
Add-CACrlDistributionPoint -Uri 'http://crl-contoso.msappproxy.net/CertEnroll/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl' `
    -AddToCertificateCdp -AddToFreshestCrl -Force
Add-CAAuthorityInformationAccess -Uri 'http://crl-contoso.msappproxy.net/CertEnroll/<ServerDNSName>_<CaName><CertificateName>.crt' `
    -AddToCertificateAia -Force
Restart-Service certsvc
# Short pause - the CA service needs a moment before it accepts certutil
Start-Sleep -Seconds 3
certutil -crl

Die Platzhalter in spitzen Klammern sind AD-CS-Variablen und bleiben genau so stehen – die CA setzt beim Ausstellen ihre eigenen Werte ein. Microsofts Core-Network-Guide setzt beide Häkchen („in CDP-Extension“ und „in CRLs“ für Delta-CRLs) auf dieselbe HTTP-URL; das entspricht -AddToCertificateCdp -AddToFreshestCrl. Ich habe das Skript in meinem Lab so durchgespielt. Zwei Punkte vor dem Ausführen klären:

• Die Standardeinträge (http://<ServerDNSName>/…, LDAP, file) bleiben bei Add-* erhalten. Soll der interne Servername nicht in jedem Zertifikat stehen, vorher mit Remove-CACrlDistributionPoint / Remove-CAAuthorityInformationAccess entfernen.
• Das Beispiel geht davon aus, dass der IIS auf der CA das lokale CertEnroll-Verzeichnis ausliefert. Liegt der Webserver woanders, braucht es zusätzlich einen Publish-Pfad (-PublishToServer -PublishDeltaToServer auf UNC/lokal).

Sperrlisten-Laufzeiten: Entra lädt die CRL selbst und cached sie. Ist im Trust Store eine CRL-URL hinterlegt, prüft Entra immer – unabhängig vom Schalter „Require CRL validation“. Eine abgelaufene CRL führt dann zu Anmeldefehlern – und weil Entra bei hinterlegter Delta-CRL beide gültig sehen will, zählt die kürzere Laufzeit. Ich nutze:

Einzustellen in der CA-Konsole unter Revoked Certificates → Properties, dort siehst du auch „Next update“. Per PowerShell bzw. certutil:

certutil -setreg CA\CRLPeriodUnits 4
certutil -setreg CA\CRLPeriod "Weeks"
certutil -setreg CA\CRLDeltaPeriodUnits 1
certutil -setreg CA\CRLDeltaPeriod "Weeks"
Restart-Service certsvc
Start-Sleep -Seconds 3
certutil -crl

Die Laufzeit ist ein Kompromiss, denn Entra hält die CRL bis zu ihrem „Next update“ vor – in beide Richtungen. So hat es sich in meinem Lab gezeigt:

• Ausfall: Fällt der Abrufweg (Connector, Webserver) aus, arbeitet Entra mit der zwischengespeicherten CRL weiter, aber nur bis zum „Next update“ der Delta-CRL. Je nach Zeitpunkt bleibt dir also bis zu einer Woche, im ungünstigsten Fall nur die kurze Überlappungszeit. Danach scheitert jede Zertifikatsanmeldung mit AADSTS500173 („Unable to download a Certificate Revocation List“). Ist die CRL wieder erreichbar, klappt die Anmeldung nach rund anderthalb Minuten wieder. Den Connector solltest du deshalb überwachen (Microsoft empfiehlt ohnehin mindestens zwei pro Gruppe).
• Sperrung: Ein gesperrtes Zertifikat lehnt Entra erst ab, wenn es die neue CRL holt – also ebenfalls erst am „Next update“ der zwischengespeicherten. Ein sofortiges certutil -crl beschleunigt das nicht. Mit einer Woche Delta kann ein gesperrtes Zertifikat also bis zu einer Woche weiter anmelden. Bei einem verlorenen Gerät reicht das Sperren des Zertifikats deshalb nicht: Zusätzlich das Konto deaktivieren (bei synchronisierten Konten im AD, dann Sync anstoßen) und die Sitzungen widerrufen. Das Deaktivieren hält neue Anmeldungen auf, im Lab nach weniger als einer Minute. Das Widerrufen beendet bestehende Sitzungen, eine neue Zertifikatsanmeldung verhindert es allein nicht.

Kürzere Laufzeiten sperren also schneller, lassen aber weniger Puffer bei einem Ausfall. Messwerte und Details stehen im Artikel zur Einführung von Entra CBA.

2. Vorlage für Hybrid-Benutzer (Online)

Ausgangspunkt ist die Vorlage „Smartcard Logon“ → Duplicate Template.

• Compatibility: CA mindestens auf Windows Server 2008 (Vorlagen-Version 3, CNG) – erst damit steht der Cryptography-Reiter mit Provider-Kategorie zur Verfügung. In der Praxis stellt man beides auf die älteste tatsächlich vorhandene Version, z. B. Server 2016 / Windows 10.
• General: Name (z. B. ContosoSmartCardLogonKSP), Gültigkeit, Verlängerungszeitraum.
• Request Handling: Zweck „Signature and smartcard logon“, „Prompt the user during enrollment“.
• Cryptography: Provider-Kategorie Key Storage Provider, Algorithmus RSA, Minimum key size 2048, „Requests must use one of the following providers“ → nur Microsoft Smart Card Key Storage Provider. Request hash auf SHA256 stellen, „Use alternate signature format“ nicht aktivieren.
• Subject Name: Build from this Active Directory information, UPN im Subject Alternative Name.
• Security: Enroll für die Gruppe der berechtigten Benutzer (bei Autoenrollment zusätzlich Autoenroll).

Warum nur RSA 2048? Die TPM-VSC von Microsoft kann nur RSA bis 2048 Bit – kein ECC, kein RSA 3072/4096, kein RSA-PSS (das ist das „alternate signature format“). Microsoft dokumentiert das nicht ausdrücklich; Hersteller von VSC-Alternativen nennen genau diese Grenzen. Der Request hash betrifft übrigens nur die Signatur des Antrags; mit welchem Hash die CA das Zertifikat signiert, legt die CA selbst fest (certutil -getreg CA\CSP\CNGHashAlgorithm, sollte SHA256 sein).

Danach auf der CA veröffentlichen: Certificate Templates → New → Certificate Template to Issue.

Warum Online? Seit KB5014754 verlangt der Domain Controller eine starke Zuordnung von Zertifikat zu Konto. Die CA schreibt bei Online-Vorlagen automatisch die SID des Kontos ins Zertifikat (Extension 1.3.6.1.4.1.311.25.2) – damit klappt die On-Prem-Anmeldung ohne weitere Pflege. Seit Februar 2025 gilt standardmäßig Full Enforcement, und mit den DC-Updates ab September 2025 gibt es auch keinen Kompatibilitätsmodus mehr: Zertifikate ohne starke Zuordnung werden abgelehnt (der DC protokolliert dann Event 39 im System-Log).

Dieses „stark“ betrifft nur den Domain Controller. Entra CBA wertet die SID-Extension nicht aus und hat eine eigene Bewertung, das Affinity Binding – mehr dazu in Abschnitt 7.

CSP oder KSP?

Beide funktionieren für die Smartcard-Anmeldung; mit dem CSP ist bei 2048 Bit Schluss. Microsofts eigener VSC-Walkthrough nutzt noch den CSP – er ist aber ausdrücklich als Konfiguration „for test purposes only“ gekennzeichnet. Der Wizard unterstützt beide; der Provider in den Einstellungen muss zur Vorlage passen.

Einordnung: Microsoft schreibt auf derselben Seite inzwischen: „Customers using virtual smart cards are encouraged to move to Windows Hello for Business or FIDO2. For new Windows installations, we recommend Windows Hello for Business or FIDO2 security keys.“ Ein Abkündigungsdatum für virtuelle Smartcards nennt Microsoft nicht. Wenn du sie als Ergänzung oder Alternative einsetzen möchtest, spricht also überhaupt nichts dagegen.

3. Vorlage für Cloud-only-Konten (Offline)

Ein Cloud-only-Konto existiert im AD nicht – es kann sich weder bei der CA authentifizieren noch kann die CA Subject und SID aus dem AD lesen. Lösung: eine zweite Vorlage mit Supply in the request. Subject und UPN im SAN kommen aus dem Antrag, eingereicht wird von einem auf die Vorlage berechtigten AD-Konto.

Achtung, ESC1: Eine Vorlage mit Smartcard-Logon-Zweck und Supply in the request erlaubt jedem Enroll-Berechtigten, Zertifikate für beliebige UPNs zu erzeugen – auch für Domänen-Admins. Defender for Identity meldet das zu Recht als Risiko. Absichern durch:

• Enroll-Recht nur für eine kleine, dedizierte Gruppe (nie Authenticated Users / Domain Users)
• CA certificate manager approval aktivieren – jeder Antrag wird manuell freigegeben
• kein Autoenroll

Der Wizard kann ausstehende Anträge nach der Genehmigung wieder abholen.

Wichtig: Offline ausgestellte Zertifikate bekommen keine SID-Extension. Für die On-Prem-Anmeldung sind sie damit ohne manuelles Strong Mapping (altSecurityIdentities) unbrauchbar – sie sind ausschließlich für Entra CBA gedacht. Genau dafür reichen sie.

4. Enrollment Agent – meist nicht nötig

Mit einem Enrollment-Agent-Zertifikat kann ein Admin Zertifikate im Auftrag anderer Konten beantragen (Enroll on Behalf Of, EOBO). Klingt praktisch, bringt bei virtuellen Smartcards aber wenig: Eine VSC ist an den TPM eines PCs gebunden. Die Karte muss also auf dem PC entstehen, an dem das Zielkonto später arbeitet – der Agent muss dafür ohnehin an genau diesem PC sitzen. Liegt der Agent-Schlüssel selbst auf einer VSC, geht EOBO sogar nur auf diesem einen Rechner.

Für den häufigsten Fall – du willst für deine eigenen Admin-Konten je eine Karte auf deiner Admin-Workstation – ist die Anmeldung als Zielkonto (der Wizard macht das per RDP-Zwischenschritt) einfacher und sicherer. Denn ein Agent-Zertifikat erlaubt Anmelde-Zertifikate für beliebige Konten und ist damit so schützenswert wie ein Domänen-Admin-Kennwort.

Sinnvoll wird EOBO, wenn ein Helpdesk-Mitarbeiter von PC zu PC geht und dort Karten für andere einrichtet. Dann gehört der Agent-Schlüssel auf portable Hardware – eine Smartcard mit Reader oder einen Security Key mit PIV-Funktion – und nicht auf einen Rechner.

Wenn du es trotzdem brauchst: was auf der CA nötig ist

1. Vorlage „Enrollment Agent“ duplizieren und veröffentlichen (EKU Certificate Request Agent, 1.3.6.1.4.1.311.20.2.1). Enroll-Recht nur für die wenigen Admins, die Karten für andere ausstellen dürfen.
2. Eigene Smartcard-Vorlage für den Agent-Weg (Duplikat der Online-Vorlage aus Abschnitt 2). Unter Issuance Requirements:
   • „This number of authorized signatures“ = 1
   • „Policy type required in signature“ = Application policy
   • „Application policy“ = Certificate Request Agent
3. Auf der CA Restricted Enrollment Agents konfigurieren – damit legst du fest, welcher Agent für welche Konten und Vorlagen ausstellen darf.

Wichtig: Mit der Signatur-Anforderung muss jeder Antrag über diese Vorlage von einem Agent signiert sein – Benutzer können sich darüber nicht mehr selbst einschreiben. Die Self-Service-Vorlage aus Abschnitt 2 bleibt deshalb unverändert. Damit Benutzer ein per Agent ausgestelltes Zertifikat selbst verlängern können, sieht Microsoft unter „Require the following for reenrollment“ die Option Valid existing certificate vor – getestet habe ich das nicht.

Der VSC-Wizard unterstützt EOBO, sobald ein EA-Zertifikat vorliegt; eine Schritt-für-Schritt-Anleitung spare ich mir hier aus den genannten Gründen.

5. Autoenrollment – und was davon für VSCs bleibt

Domänen- und Hybrid-joined PCs: Hier funktioniert der klassische Weg per GPO auch mit virtuellen Smartcards – getestet auf Windows 11 mit einer vorhandenen, leeren VSC:

1. Vorlage aus Abschnitt 2 duplizieren, unter Security zusätzlich Autoenroll für die Benutzergruppe; „Prompt the user during enrollment“ bleibt an.
2. GPO für die Benutzer: User Configuration → Policies → Windows Settings → Security Settings → Public Key Policies → Certificate Services Client – Auto-Enrollment → Enabled, „Renew expired certificates…“ und „Update certificates that use certificate templates“ aktivieren.

Beim nächsten Autoenrollment-Lauf (Anmeldung, alle paar Stunden oder sofort mit certutil -pulse -user) meldet sich Windows mit einer Benachrichtigung:

Ein Klick öffnet den Assistenten „Certificate Enrollment“, die Vorlage steht mit „Enrollment required“ bereit. Nach Enroll fragt Windows die PIN der virtuellen Smartcard ab, danach meldet der Assistent „Succeeded“:

Zwei Einschränkungen bleiben:

1. Ohne Klick des Benutzers passiert nichts – die PIN-Abfrage ist bei Smartcard-Vorlagen Pflicht, ein stilles Autoenrollment gibt es nicht.
2. Autoenrollment legt keine virtuelle Smartcard an – die Karte muss vorher existieren. Ohne Karte bleibt Windows bei „Connect a smart card“ stehen, es wird nichts ausgestellt:

Kontrolle: certutil -user -store My zeigt das neue Zertifikat mit Provider = Microsoft Smart Card Key Storage Provider und „Private key is NOT exportable“. In der Ereignisanzeige steht unter Applications and Services Logs → Microsoft → Windows → CertificateServicesClient-Lifecycle-User → Operational ein Event 1006 mit „Action: Enroll“ und der Vorlage.

Stolperfalle beim Neuanlegen: Wird eine Karte gelöscht, bleibt das Zertifikat ohne Schlüssel im Benutzerspeicher stehen. Autoenrollment hält es für gültig und tut nichts. Vorher also das verwaiste Zertifikat entfernen, z. B. mit certutil -user -delstore My <Thumbprint>.

Entra-joined PCs: Gruppenrichtlinien greifen dort nicht – Microsoft unterstützt auf EJ-Geräten nur MDM-Verwaltung. Eine Intune-Einstellung für AD-CS-Autoenrollment gibt es nicht; Microsofts Weg für EJ sind SCEP- oder PKCS-Zertifikatsprofile. Diese können den Schlüssel aber nur im TPM, in Windows Hello for Business oder in Software ablegen – nicht auf einer (virtuellen) Smartcard.

Der pragmatische Weg: Der VSC-Wizard bringt seine eigene Erneuerung mit: Nach der Installation (VscWizard.exe -Install, z. B. als Intune-App) startet ein Scheduled Task ihn bei jeder Anmeldung im Simple-Modus. Läuft das Smartcard-Anmeldezertifikat des Benutzers in weniger als 30 Tagen ab, öffnet sich der Assistent und stellt ein neues Zertifikat auf dieselbe Karte aus; alte Zertifikate räumt er auf Wunsch weg. Das funktioniert auf Hybrid- wie Entra-joined PCs, solange der Benutzer ein On-Prem-Kerberos-Ticket hat (Cloud Kerberos Trust).

Meine Empfehlung: Ich nutze die Erneuerung über den Wizard. Der entscheidende Vorteil ist, dass sie auf Entra-joined und Hybrid-joined PCs gleich funktioniert – ein Mechanismus statt zwei. Wenn du nur domänen- bzw. hybrid-joined PCs hast, ist GPO-Autoenrollment eine brauchbare Alternative – der Benutzer muss nur die Benachrichtigung anklicken und die PIN eingeben.

6. CRL ins Internet: Publishing über Entra Application Proxy

Entra CBA lädt die CRL aus der Cloud – eine nur intern erreichbare CRL bricht die Sperrprüfung. Anforderungen von Microsoft:

• HTTP oder HTTPS (HTTP empfohlen), ein CRL-Endpunkt pro CA
• Download in höchstens 10 Sekunden, CRL höchstens 20 MB
• Base- und Delta-CRL werden unterstützt; sind beide konfiguriert, müssen beide gültig und erreichbar sein
• die CRL Number muss mit jeder neuen CRL steigen; Entra wertet „Next CRL Publish“ aus

Mein Lieblingsweg ist Entra Application Proxy – nicht nur für das CRL Publishing, sondern auch für NDES (Troubleshooting Certificate Connector for Microsoft Intune). Die Konfiguration ist genauso simpel:

• Internal URL: der CertEnroll-Pfad des internen CRL-Webservers, z. B. http://ca01.contoso.local/CertEnroll/
• External URL: Protokoll http:// – das Admin Center bietet HTTP direkt in der Auswahl an, ein SSL-Zertifikat ist dann nicht nötig. Als Domain reicht die Standard-Domain msappproxy.net, also z. B. http://crl-contoso.msappproxy.net/CertEnroll/
• Pre Authentication: Passthrough – Entra lädt die CRL anonym
• Connector Group: eine Gruppe mit Connectors, die den CRL-Webserver erreichen

Dieselbe externe URL steht dann an zwei Stellen: im CDP der Zertifikate (Abschnitt 1) und im Trust Store von Entra (Abschnitt 7) – dort für die Base- und die Delta-CRL, z. B. http://crl-contoso.msappproxy.net/CertEnroll/Contoso%20Root%20CA.crl und …/Contoso%20Root%20CA+.crl. Leerzeichen im CA-Namen werden als %20 kodiert.

Test: Am einfachsten mit dem URL-Abrufprogramm von Windows:

certutil -URL http://crl-contoso.msappproxy.net/CertEnroll/Contoso%20Root%20CA.crl

Im Fenster „Sperrlisten (vom CDP)“ wählen und Abrufen. Erwartet: Basis- und Delta-Sperrliste über die msappproxy-URL mit Status OK. Ein gescheiterter LDAP-Eintrag ist normal, wenn der Testrechner nicht in der Domäne ist. Weil msappproxy.net öffentlich auflöst, läuft der Abruf auch aus dem internen Netz über den Application Proxy – der Test prüft also tatsächlich den Weg, den Entra nimmt.

App Proxy als CRL-Host ist von Microsoft nicht ausdrücklich dokumentiert – das ist ein Erfahrungswert aus der Praxis (Michael Niehaus hat den Weg schon im April 2020 beschrieben: Publish Certificate Services CRL and OCSP sites to the internet using Azure App Proxy).

7. Entra CBA einrichten

1. CA hochladen: im Entra Admin Center unter Entra ID → Identity Secure Score → Public key infrastructure – so steht es auch in Microsofts Doku. Die Seite selbst heißt dann im Breadcrumb „Security | Public key infrastructure“, warum auch immer (PKI-basierter Trust Store; Rolle Privileged Authentication Administrator). Dort eine PKI anlegen und darin mit Add certificate authority jede CA einzeln hinzufügen – Root und ggf. Issuing-CA. Pro CA: „Is this certificate authority the root?“, Certificate revocation list URL und Delta certificate revocation list URL (die externen aus Abschnitt 6) und optional Issuer hints. Einzeln hinzufügen geht mit jeder Lizenz; der Sammel-Upload als .p7b (Upload CBA PKI) braucht Entra ID P1/P2 und kann bis zu 30 Minuten dauern.
2. CBA aktivieren: Entra ID → Authentication methods → Certificate-based authentication → Enable (Rolle Authentication Policy Administrator genügt), zunächst nur für eine Gruppe, nicht für All users. Der Grund: Wer im Geltungsbereich von CBA steht, gilt für Entra als MFA-fähig. Hat er weder ein Zertifikat noch eine andere registrierte MFA-Methode, kann er keine nachregistrieren und ist ausgesperrt – Microsoft schreibt deshalb ausdrücklich „Don’t include All users for CBA“. Die Gruppe ist damit dein Rollout-Schalter: Wer seine VSC hat, kommt hinein. Als Notausgang für festsitzende Benutzer dient ein Temporary Access Pass.
3. Authentication Binding: Standard ist Single-Factor. Für Smartcard-Anmeldung sinnvoll: Regel nach Issuer oder Policy-OID auf Multi-Factor setzen – dann zählt die VSC-Anmeldung als phishing-resistente MFA.
4. Username Binding: Standard PrincipalName (UPN im SAN) → userPrincipalName. Das ist Low Affinity – und der Tenant-Standard „Required Affinity Binding: Low“ akzeptiert das. Siehe den Hinweis unten.
5. CRL-Prüfung: „Require CRL validation“ einschalten. Der Schalter betrifft nur CAs ohne CRL-URL im Trust Store: Ohne ihn prüft Entra für diese CAs gar keine Sperrung – im Lab kam ein gesperrtes Zertifikat so problemlos durch. Mit Schalter lehnt Entra die Anmeldung stattdessen ab (AADSTS2205018). Mit eingetragener URL prüft Entra ohnehin immer.
6. Netzwerk: keine TLS-Inspection auf *.certauth.login.microsoftonline.com (mit Issuer Hints: t<tenantId>.certauth.login.microsoftonline.com).

Sicherheitshinweis zum Username Binding: Die Zuordnung über den UPN ist Low Affinity – jedes Zertifikat deiner CA mit passendem UPN meldet den Benutzer an, mit Multi-Factor-Binding sogar als phishing-resistente MFA. Zusammen mit der Offline-Vorlage aus Abschnitt 3 hängt die Sicherheit damit an deren Enroll-Rechten und der Manager-Freigabe. Für den schnellen Start ist das vertretbar, wenn beides eng gefasst ist. Die Härtung mit High Affinity (certificateUserIds), den Rollout für alle Benutzer und die Fallen, mit denen man sich aussperren kann, beschreibe ich in einem eigenen Artikel zur Einführung von Entra CBA.

Windows-Anmeldung mit CBA: Auf dem Client musst du dafür nichts einrichten. Das Gerät muss Entra-joined oder Hybrid-joined sein, und der Benutzer braucht verwaltete Authentifizierung (oder ist im Staged Rollout) – mit Verbundanmeldung wie AD FS klappt es nicht. Microsoft nennt dabei ausdrücklich „physical or virtual smart card“, die VSC ist also vorgesehen.

Welchen Benutzernamen Windows an Entra schickt, hängt von der Join-Art ab. Auf einem Entra-joined Gerät liest Windows den UPN aus dem SAN des Zertifikats (fehlt er, die E-Mail-Adresse). Auf einem Hybrid-Gerät muss zuerst die Anmeldung am AD klappen, und Windows schickt dann den AD-UPN. Am einfachsten ist es deshalb, wenn der UPN im AD und in Entra gleich ist – also ein routbarer UPN-Suffix wie anna@contoso.com statt anna@contoso.local. Das ist ohnehin der empfohlene Weg für Hybrid-Umgebungen, und dann passen Windows-Anmeldung, Zertifikat und Standard-Username-Binding ohne Zusatzaufwand zusammen. (Wer das nicht kann: Entra sucht bei abweichendem UPN zusätzlich über onPremisesUserPrincipalName, und ein Username Binding PrincipalName → onPremisesUserPrincipalName ordnet auch das Zertifikat zu. Nach der ersten erfolgreichen Anmeldung merkt sich Windows den Entra-UPN.)

Hat Entra den Benutzer gefunden und das Zertifikat geprüft, bekommt das Gerät ein Primary Refresh Token und damit Single Sign-on für die Cloud-Apps. Ob dieses Token auch als MFA zählt, entscheidet das Authentication Binding aus Schritt 3: Nur mit Multi-Factor enthält es den MFA-Claim – sonst verlangt jede MFA-pflichtige Conditional-Access-Richtlinie noch einen weiteren Faktor.

Checkliste: ready for VSCs

• ☐ HTTP-CDP/AIA konfiguriert, CRL publiziert, von außen abrufbar (< 10 s)
• ☐ Online-Vorlage (KSP, Build from AD) veröffentlicht, Enroll-Gruppe gesetzt
• ☐ Offline-Vorlage für Cloud-only veröffentlicht, Enroll eng, Manager Approval aktiv
• ☐ Entra: CA im Trust Store mit CRL-URL
• ☐ Entra: CBA für Pilotgruppe aktiv, Bindings gesetzt, Affinity bewusst gewählt (Low + enge Offline-Vorlage oder High mit certificateUserIds)
• ☐ Testanmeldung on-prem (Hybrid) und an Entra (Cloud-only)
• ☐ VSC-Wizard: CA und Vorlagen in den Einstellungen eingetragen

Fazit

Der VSC-Wizard nimmt Benutzern und Admins die Arbeit am Client ab – die eigentliche Vorarbeit steckt in der PKI, und die ist überschaubar, wenn du sie in der richtigen Reihenfolge angehst: zuerst CDP und AIA, weil sie in jedes Zertifikat eingebrannt werden; dann zwei Vorlagen, eine für Hybrid-Konten und eine eng abgesicherte für Cloud-only; die CRL per Application Proxy ins Internet; zuletzt Entra CBA, erst für eine Pilotgruppe.

Damit hast du phishing-resistente Anmeldung mit Hardware-gebundenem Schlüssel für on-prem und Entra – ohne physische Smartcards und ohne neue Infrastruktur. Microsoft empfiehlt für neue Installationen Windows Hello for Business und FIDO2. Wenn du virtuelle Smartcards als Ergänzung oder Alternative dazu einsetzen möchtest, spricht nichts dagegen – und mit einer vorhandenen Enterprise CA bist du damit schnell am Ziel. Wie du Entra CBA anschließend für alle Benutzer und Admins ausrollst, beschreibe ich in einem eigenen Artikel.