AUS DEM MARKT
Microsofts Standard ist nicht falsch: er ist unvollständig
Wo Windows Hello for Business aufhört, das Problem zu lösen, und was die Lücke füllt
Roman Kuznetsov @ 16.07.2026
Folgen Roman Kuznetsov on LinkedIn
Wer 2026 Active Directory administriert, hört von Microsoft seit gut einem Jahrzehnt dieselbe Botschaft: Passwortlose Authentifizierung ist die Zukunft, diese Zukunft heißt Windows Hello for Business, und Sie sollten es ausrollen. Der Rat ist nicht falsch. WHfB ist eine glaubwürdige passwortlose Lösung, für die Szenarien, für die es entworfen wurde. Der Haken: „die Szenarien, für die es entworfen wurde" decken das Wenigste von dem ab, was ein AD-Administrator tatsächlich authentifizieren muss.
Dieser Beitrag ist eine ehrliche Bestandsaufnahme: wo sich WHfB bezahlt macht, wo es aufhört, und was in einer realen hybriden Umgebung die Lücke füllt.
Dieser Beitrag ist eine ehrliche Bestandsaufnahme: wo sich WHfB bezahlt macht, wo es aufhört, und was in einer realen hybriden Umgebung die Lücke füllt.
Was WHfB gut macht
Ehre, wem Ehre gebührt. WHfB ist die ausgereifteste native passwortlose Implementierung, die Microsoft je für Windows ausgeliefert hat.
Es ist beinahe echte Mehr-Faktor-Authentifizierung: Der Benutzer authentifiziert sich lokal mit PIN oder Biometrie, was einen TPM-gebundenen privaten Schlüssel freigibt, mit dem anschließend eine Authentifizierungsanfrage signiert wird. („Beinahe", weil der eine Faktor vom anderen abhängt; wer MFA streng auslegt, könnte hier ein Problem sehen.) Zwei Faktoren (Wissen oder Biometrie plus Besitz des TPM-geschützten Schlüssels), kein gemeinsames Geheimnis auf der Leitung. Phishing-resistent im eigentlichen Sinne: Es gibt keine Anmeldeinformation, die man abgreifen und wiedereinspielen könnte. Na ja, die PIN vielleicht schon.
Es ist außerdem, für einen bestimmten Typ von Bereitstellung, ausgesprochen reibungsarm. Ein Benutzer meldet sich an seinem eigenen Notebook mit PIN oder Gesicht an. Das Notebook gehört ihm. Die Anmeldeinformation ist an dieses Notebook gebunden, an diesen Benutzer, an dieses TPM. Das Modell ist sauber und ergonomisch, solange die Annahme trägt.
Genau diese Annahme ist der wunde Punkt.
Es ist beinahe echte Mehr-Faktor-Authentifizierung: Der Benutzer authentifiziert sich lokal mit PIN oder Biometrie, was einen TPM-gebundenen privaten Schlüssel freigibt, mit dem anschließend eine Authentifizierungsanfrage signiert wird. („Beinahe", weil der eine Faktor vom anderen abhängt; wer MFA streng auslegt, könnte hier ein Problem sehen.) Zwei Faktoren (Wissen oder Biometrie plus Besitz des TPM-geschützten Schlüssels), kein gemeinsames Geheimnis auf der Leitung. Phishing-resistent im eigentlichen Sinne: Es gibt keine Anmeldeinformation, die man abgreifen und wiedereinspielen könnte. Na ja, die PIN vielleicht schon.
Es ist außerdem, für einen bestimmten Typ von Bereitstellung, ausgesprochen reibungsarm. Ein Benutzer meldet sich an seinem eigenen Notebook mit PIN oder Gesicht an. Das Notebook gehört ihm. Die Anmeldeinformation ist an dieses Notebook gebunden, an diesen Benutzer, an dieses TPM. Das Modell ist sauber und ergonomisch, solange die Annahme trägt.
Genau diese Annahme ist der wunde Punkt.
Die drei Vertrauensmodelle, kurz gefasst
WHfB authentifiziert sich in einem von drei Vertrauensmodellen gegen Active Directory. Cloud Kerberos Trust ist Microsofts aktuelle Empfehlung und die einzige hybride Variante, die ganz ohne Zertifikate auskommt, um den Preis einer Abhängigkeit von Entra Kerberos und einem aus der Cloud synchronisierten Kerberos-Objekt. Key Trust schreibt den öffentlichen Schlüssel des Benutzers ins Active Directory und braucht weiterhin eine PKI als Vertrauensanker. Certificate Trust ist der Altpfad, gehalten vor allem dort, wo bereits in AD CS investiert wurde und zertifikatsbasierte Authentifizierung auf Smartcard-Niveau gefordert ist.
Doch die Entscheidung, die Ihnen tatsächlich die Hände bindet, ist nicht das Vertrauensmodell. Es ist das Bereitstellungsmodell, Cloud-only, hybrid oder rein on-premises, und genauer die Frage, ob eine reine On-Premises-Bereitstellung überhaupt tragfähig ist.
Auf dem Papier ist sie es. In der Praxis: On-Premises-Bereitstellungen müssen eine Mehr-Faktor-Option verwenden, die sich als AD-FS-MFA-Adapter einbinden lässt. Microsofts eigene Antwort auf diese Anforderung existiert nicht mehr. MFA Server wird seit dem 1. Juli 2019 nicht mehr für Neubereitstellungen angeboten, und bestehende MFA-Server-Installationen bedienen seit dem 30. September 2024 keine MFA-Anfragen mehr. Eine reine On-Prem-WHfB-Bereitstellung bedeutet 2026 also: AD CS, dazu AD FS, dazu ein Drittanbieter-MFA-Adapter für den zweiten Faktor. Microsoft selbst verortet den Hauptanwendungsfall dieses Modells bei „Enhanced Security Administrative Environments", den Red Forests, und weist darauf hin, dass eine Migration von On-Premises nach Hybrid einen Neuaufbau erfordert. Cloud Kerberos Trust wiederum funktioniert in einer reinen On-Premises-AD-DS-Umgebung überhaupt nicht.
Das sollte man beim Namen nennen. Microsofts On-Prem-Geschichte zur passwortlosen Anmeldung braucht einen Dritten für den zweiten Faktor, zielt auf eine Tier-0-Nische und hat keinen Migrationspfad, Sie bauen von vorn auf.
Cloud Kerberos Trust ist demgegenüber der bequemste Weg und der, für den Microsoft am lautesten die Werbetrommel rührt. Es ist zugleich ein hybrides Modell mit fest eingebauter Cloud-Abhängigkeit: kein Entra ID, kein WHfB. Für Häuser, deren Strategie On-Prem-first lautet, ist das ein strukturelles Problem und keine Frage des Werkzeuggeschmacks.
Doch die Entscheidung, die Ihnen tatsächlich die Hände bindet, ist nicht das Vertrauensmodell. Es ist das Bereitstellungsmodell, Cloud-only, hybrid oder rein on-premises, und genauer die Frage, ob eine reine On-Premises-Bereitstellung überhaupt tragfähig ist.
Auf dem Papier ist sie es. In der Praxis: On-Premises-Bereitstellungen müssen eine Mehr-Faktor-Option verwenden, die sich als AD-FS-MFA-Adapter einbinden lässt. Microsofts eigene Antwort auf diese Anforderung existiert nicht mehr. MFA Server wird seit dem 1. Juli 2019 nicht mehr für Neubereitstellungen angeboten, und bestehende MFA-Server-Installationen bedienen seit dem 30. September 2024 keine MFA-Anfragen mehr. Eine reine On-Prem-WHfB-Bereitstellung bedeutet 2026 also: AD CS, dazu AD FS, dazu ein Drittanbieter-MFA-Adapter für den zweiten Faktor. Microsoft selbst verortet den Hauptanwendungsfall dieses Modells bei „Enhanced Security Administrative Environments", den Red Forests, und weist darauf hin, dass eine Migration von On-Premises nach Hybrid einen Neuaufbau erfordert. Cloud Kerberos Trust wiederum funktioniert in einer reinen On-Premises-AD-DS-Umgebung überhaupt nicht.
Das sollte man beim Namen nennen. Microsofts On-Prem-Geschichte zur passwortlosen Anmeldung braucht einen Dritten für den zweiten Faktor, zielt auf eine Tier-0-Nische und hat keinen Migrationspfad, Sie bauen von vorn auf.
Cloud Kerberos Trust ist demgegenüber der bequemste Weg und der, für den Microsoft am lautesten die Werbetrommel rührt. Es ist zugleich ein hybrides Modell mit fest eingebauter Cloud-Abhängigkeit: kein Entra ID, kein WHfB. Für Häuser, deren Strategie On-Prem-first lautet, ist das ein strukturelles Problem und keine Frage des Werkzeuggeschmacks.
Wo WHfB von Haus aus passt
Einzelbenutzergeräte in einer Entra-joined oder hybrid-joined Umgebung. Ein Wissensarbeiter mit Notebook, bei dem die 1:1-Beziehung zwischen Gerät und Mensch über die gesamte Lebensdauer des Geräts hält. Außendienst. Entwickler. Geschäftsführung. Der Benutzertyp, dessen Authentifizierungsproblem lautet: „Ich bin ich, an meiner Maschine, beweise es ohne Passwort."
Für diese Benutzer ist WHfB ein vertretbarer Standard. Rollen Sie es aus.
Für diese Benutzer ist WHfB ein vertretbarer Standard. Rollen Sie es aus.
Wo es aufhört zu funktionieren
Schwierig wird es, sobald die Annahme bricht. Ein Rundgang, ohne Anspruch auf Vollständigkeit:
- Gemeinsam genutzte ArbeitsplätzeWHfB bindet die Anmeldeinformation an ein Paar aus Gerät und Benutzer. An einer Arbeitsstation, die zwanzig Benutzer über eine Schicht hinweg bedienen, muss sich jeder Benutzer an jedem Gerät registrieren, das er anfassen könnte, und der Registrierungsvorgang selbst hängt an einem Passwort-Fallback. Microsofts eigene Dokumentation hält fest, dass die integrierte Bereitstellungserfahrung die schwachen Anmeldeinformationen des Benutzers, Benutzername und Passwort, als ersten Faktor akzeptiert. Das Fallback ist genau die Anmeldeinformation, zu deren Abschaffung der Rest von WHfB existiert. Was immer Sie an Mustern für gemeinsam genutzte Arbeitsplätze auf WHfB aufsetzen: Sie bauen es gegen WHfB, nicht mit ihm.
- RDP und SitzungshostsHier klafft die Lücke am deutlichsten, und Microsoft dokumentiert sie. Cloud Kerberos Trust lässt sich nicht als bereitgestellte Anmeldeinformation für RDP oder VDI verwenden. Der unterstützte Weg besteht darin, eigens ein Zertifikat in den Windows-Hello-Container zu registrieren, für Key Trust gilt dasselbe —, was eine PKI auf Basis von AD CS oder eines Drittanbieters voraussetzt und, bei Entra-joined Geräten, ein Zertifikat auf den Domänencontrollern als Vertrauensanker der Clients. WHfB emuliert dann aus Kompatibilitätsgründen eine Smartcard und fragt die Geste ab.
Halten wir fest, was das heißt. Die Lösung für WHfBs RDP-Lücke besteht darin, ein Benutzerzertifikat auszustellen und Windows so tun zu lassen, als wäre es eine Smartcard. Das Versprechen der Zertifikatsfreiheit von Cloud Kerberos Trust hält also genau so lange, bis jemand per RDP auf einen Server muss.
Die Alternative ist Remote Credential Guard: Single Sign-on für RDP-Sitzungen über Kerberos, ohne Zertifikate ausrollen zu müssen, dafür mit eigenen Einschränkungen. Remote Desktop mit Biometrie funktioniert nicht mit Dual Enrollment und nicht dort, wo der Benutzer alternative Anmeldeinformationen angibt. Wer den Zertifikatsweg geht, berichtet von den erwartbaren Ecken und Kanten: Der RDP-Client greift das falsche Zertifikat aus dem Speicher, und nur eine Sitzung zur Zeit kann die Smartcard-Anmeldeinformation nutzen, was spätestens beim zweiten RemoteApp-Host zum Problem wird. - Kommandozeile und IdentitätswechselHier werden zwei verschiedene Dinge in einen Topf geworfen, und der Unterschied ist wesentlich.
Pfade, die das Kerberos-TGT erben, sind unproblematisch. Nach einer WHfB-Anmeldung läuft PowerShell-Remoting über Kerberos ohne Passwort auf dem entstandenen Ticket. Etwas anderes zu behaupten, wäre unredlich.
Pfade, die eine bereitgestellte Anmeldeinformation verlangen, sind das Problem: runas, runas /netonly, psexec mit expliziten Zugangsdaten, MMC- und RSAT-Werkzeuge, die als anderer Benutzer gestartet werden, geplante Tasks, die unter einem Benutzer mit hinterlegtem Passwort laufen. Das sind die Arbeitspferde des Betriebs.
Es gibt dafür eine dokumentierte WHfB-Antwort, und die verdient Anerkennung: Dual Enrollment, ein Zertifikat im Hello-Container des privilegierten Kontos, liefert passwortloses Run-as und passwortloses RDP, mit PIN statt getipptem Passwort. Das funktioniert. Es kostet allerdings AD CS, eine Zertifikatsvorlage, Zertifikate pro Benutzer und einen Dual-Enrollment-Prozess, und es hat dokumentierte Kanten, darunter die, dass ein per Intune ausgerolltes Zertifikat in Kombination mit einer Benutzerkontensteuerung, die Anmeldeinformationen auf dem sicheren Desktop abfragt, die Run-as-Funktion schlicht aushebelt.
Die ehrliche Aussage lautet also nicht, WHfB könne diese Pfade nicht abdecken. Sie lautet: Sie abzudecken bedeutet, genau jene Zertifikatsinfrastruktur wieder aufzubauen, die Cloud Kerberos Trust Ihnen ersparen sollte, und sie anschließend neben der Key-Trust-Bereitstellung zu pflegen, die Sie ohnehin schon haben. - Service Desk und Break-GlassHelpdesk-Mitarbeiter, die eine Aktion im Namen eines Benutzers ausführen müssen. Kontowiederherstellung, wenn ein Benutzer seine PIN vergessen oder sein Telefon getauscht hat. Die Wiederherstellungsgeschichte von WHfB hängt stark davon ab, welches Vertrauensmodell Sie gewählt haben und wie Ihr Entra konfiguriert ist. Unmöglich ist das nicht, aber es ist ein eigener Arbeitsablauf neben dem, den Ihre Administratoren gewohnt sind, und in den unangenehmen Fällen landet er am Ende doch beim Passwort.
- Pre-Boot und OfflineArbeitsstationen, die sich vor dem Benutzer authentifizieren müssen, oder die stundenlang ohne Verbindung zu Entra ID auskommen (Schiffe, Außenstandorte, Sicherheitsbereiche). Cloud Kerberos Trust setzt Cloud-Erreichbarkeit voraus und funktioniert in einer reinen On-Premises-AD-DS-Umgebung ohnehin nicht. Key Trust übersteht den Ausfall, zu dem oben beschriebenen Preis.
- Komplexität hybrider IdentitätenWenn Ihre Benutzer im lokalen AD leben und Sie ihnen WHfB geben wollen, betreiben Sie Entra Connect. Sie nehmen damit eine Abhängigkeit von der Verfügbarkeit von Entra für Ausstellung und Rotation von Anmeldeinformationen in Kauf, und eine Frage der Datenresidenz, die Sie vorher nicht hatten. Nichts davon ist unbeherrschbar. Es ist nur das genaue Gegenteil der On-Prem-Isolation, die viele regulierte Umgebungen verlangen.
Was SystoLOCK in diesen Fällen leistet
SystoLOCK ist für die oben beschriebenen Fälle gebaut. Die Position gegenüber WHfB in Kürze:
- AnmeldemodellBeide schaffen das Passwort als gespeichertes Geheimnis ab. WHfB tut es mit einem TPM-gebundenen Schlüssel, SystoLOCK mit einem kurzlebigen X.509-Zertifikat, das zum Zeitpunkt der Anmeldung ausgestellt wird. Beide landen im Active Directory als Kerberos-Ticket, geprüft über denselben Mechanismus.
- GerätebindungWHfB bindet die Anmeldeinformation an ein bestimmtes Gerät. SystoLOCK bindet den Authentifizierungsfaktor, ein Telefon, einen Token, einen Ausweis, an den Benutzer und lässt diesen Faktor an jeder Arbeitsstation der Umgebung authentifizieren. Das ist es, was gemeinsam genutzte Arbeitsplätze funktionieren lässt.
- Cloud-AbhängigkeitWHfB mit Cloud Kerberos Trust setzt Entra ID voraus. SystoLOCK braucht keinerlei Cloud-Dienst. Der Authentifizierungsbroker läuft on-premises, auf Windows-Servern, in derselben Domäne, gegen die er authentifiziert. In abgeschotteten Umgebungen funktioniert es genauso wie in verbundenen.
- KommandozeileDie oben beschriebene Lücke schließt SystoLOCK genau an der Stelle, an der Windows nach einer Anmeldeinformation fragt. Ein Credential Provider erweitert den Dialog für bereitgestellte Anmeldeinformationen, denselben Dialog, der hinter runas, „Als anderer Benutzer ausführen" und der Anmeldeabfrage des RDP-Clients steckt, und schiebt ein in diesem Moment ausgestelltes, kurzlebiges Zertifikat unter. Was Windows danach tut, ist der ganz gewöhnliche Weg. Kein Dual Enrollment, keine Zertifikatsvorlage, kein Zertifikat pro Benutzer, für das ein Lebenszyklus geplant werden will.
- AbdeckungWHfB authentifiziert die interaktive Windows-Anmeldung. SystoLOCK authentifiziert Windows-Anmeldung, RDP, Identitätswechsel auf der Kommandozeile, Altanwendungen über Kerberos-Integration und VPN. Derselbe Faktor, dieselbe Richtlinien-Engine, über die gesamte Matrix der Zugriffsmuster.
- Abdeckung des BestandsWHfB verlangt Windows 10 oder neuer und ein TPM. SystoLOCK authentifiziert Windows-Versionen zurück bis Windows 7 und Server 2008. Das ist keine Prahlerei damit, veraltete Software zu unterstützen. Es ist die Anerkennung einer Tatsache: Die Maschinen, die niemand abschalten kann, die, die an ein Laborgerät geschraubt sind, die, die die Fertigungslinie steuern, die, deren Hersteller sich 2014 in Luft aufgelöst hat, sind genau die Maschinen, bei denen ein Passwort noch immer das Einzige ist, was zwischen einem Angreifer und der Domäne steht. WHfBs Antwort für diese Endpunkte lautet: außerhalb des Geltungsbereichs.
- Hybride IdentitätWHfB setzt Entra Connect voraus. SystoLOCK setzt nichts voraus außer AD. Wenn Ihre Identität on-premises lebt und das so bleiben soll, ist der Unterschied struktureller Natur.
- RegistrierungWHfB registriert pro Benutzer, pro Gerät. SystoLOCK registriert pro Benutzer, einmal, und der Benutzer authentifiziert sich von jedem abgedeckten Endpunkt aus.
Was wann die richtige Wahl ist
Die ehrliche Empfehlung, Herstellermarketing beiseite:
Für Entra-first- oder vollständig cloud-basierte Umgebungen mit Einzelbenutzergeräten ist WHfB der richtige Standard. Rollen Sie es aus. Machen Sie sich keinen Kopf.
Für hybride AD-Umgebungen, in denen die lokale Identität strategisch ist, in denen es gemeinsam genutzte Arbeitsplätze gibt, in denen MFA auf der Kommandozeile für NIS2 oder DORA zählt, in denen RDP zum Betriebsalltag gehört, oder in denen eine Entra-Abhängigkeit im Authentifizierungspfad nicht akzeptabel ist, wird WHfB Lücken hinterlassen. SystoLOCK ist gebaut, um genau diese Lücken zu schließen.
Die beiden schließen einander nicht aus. WHfB auf den Notebooks, SystoLOCK auf den gemeinsam genutzten Arbeitsplätzen, den Sitzungshosts und den privilegierten Zugriffspfaden ist eine vertretbare Architektur. Der Fehler liegt in der Annahme, WHfB allein sei die vollständige Antwort, nur weil Microsoft das sagt.
Für Entra-first- oder vollständig cloud-basierte Umgebungen mit Einzelbenutzergeräten ist WHfB der richtige Standard. Rollen Sie es aus. Machen Sie sich keinen Kopf.
Für hybride AD-Umgebungen, in denen die lokale Identität strategisch ist, in denen es gemeinsam genutzte Arbeitsplätze gibt, in denen MFA auf der Kommandozeile für NIS2 oder DORA zählt, in denen RDP zum Betriebsalltag gehört, oder in denen eine Entra-Abhängigkeit im Authentifizierungspfad nicht akzeptabel ist, wird WHfB Lücken hinterlassen. SystoLOCK ist gebaut, um genau diese Lücken zu schließen.
Die beiden schließen einander nicht aus. WHfB auf den Notebooks, SystoLOCK auf den gemeinsam genutzten Arbeitsplätzen, den Sitzungshosts und den privilegierten Zugriffspfaden ist eine vertretbare Architektur. Der Fehler liegt in der Annahme, WHfB allein sei die vollständige Antwort, nur weil Microsoft das sagt.