Heute möchte ich euch (endlich, mal wieder) einen etwas technischeren Post zu Authentifizierungsmechanismen bei Windows liefern:

Agenda

1. Was ist Windows Hello for Business?
2. Aber noch mal: warum ist das jetzt MFA?
3. Aus 2 mach 3 oder mehr!
4. Fein, und wie konfiguriert man dies nun?
5. ABER
6. FAZIT und Empfehlung

Ich werde immer mal wieder gefragt:

„Ihr/du erzählt immer ganz viel von ‚#gopasswordless‘, ‚MFA ist das Mindeste, was man zur Absicherung seiner Unternehmung tun sollte‘, etc – das funktioniert ja auch sehr gut bei allen an Azure AD angeschlossenen Apps, aber was ist eigentlich mit Windows selber???“

Nun, bei Windows selber gibt es dazu im Wesentlichen drei Möglichkeiten, wovon ich auf eine im Besonderen eingehen werde:

1. Old School: Smartcards -> Hoher Kosten- und Verwaltungsaufwand, das ist heute nicht mehr „state of the art“ (SOTA)
2. Einfach: FIDO2
3. Einfach und am günstigsten: Windows Hello (for Business)

Und grade der letztgenannte ist erklärungswürdig, vor allem „hä? Warum ist das MFA?“

Was ist Windows Hello for Business?

Kurz gesagt ist Windows Hello for Business (WHfB) die Antwort darauf, wie Authentifikationen insbesondere im Netzwerk sicher(er) ablaufen, als wenn klassisch Benutzername und Passwort übertragen werden.

Der Mechanismus sieht (vereinfacht) wie folgt aus:

1. Initial wird mit der Authentication Authority, z.B. das lokale AD (bitte auf die Requirements achten!) oder gerne auch Azure AD, der User einmalig authentifiziert. Das kann heute auch gerne „#gopwasswordless“ stattfinden, muss aber nicht. [Empfehlung ist: doch, muss!]
2. Dann wird über „klassische“ PKI Mechanismen ein Schlüssel/Zertifikat ausgetauscht und – sofern vorhanden – im TPM abgelegt.
3. Nun muss noch der Zugriff auf den TPM abgesichert werden. Dafür gibt es mehrere Möglichkeiten, die u.a. auch von der verbauten/verfügbaren Hardware abhängen:
   1. Per PIN, also je nach Konfiguration ein einfacher Zahlenpin oder auch eine alpha-numerische Kombination.
      WICHTIG: selbst ein einfacher PIN (bitte gerne mehr als 4 Ziffern) ist insgesamt sicherer als Benutzername+Passwort!!!
   2. Per Fingerabdruck – natürlich nur, wenn per Hardware verfügbar. Und ja, wenn keine Livedetection und lediglich Papillarleisten überprüfbar sind, dann ist das keine supportete Variante für WHfB! Lediglich Hardware auf kapazitiver Basis sind möglich.
   3. Per Gesichtserkennung – sowohl aus Security, als auch aus Usability der zu bevorzugende Weg!
4. Ab jetzt kann über die in 3. bestimmten Möglichkeiten das Zertifikat im TPM aktiviert und für die Authentication gegen den Dienst genutzt werden.

Moooooment! Warum soll das denn besser sein? Ich will doch gar nicht, dass meine biometrischen Merkmale an meinen Arbeitgeber – oder noch schlimmer – in die Microsoft Cloud transferiert werden!

Ja, richtig, bitte noch mal den vorangegangenen Absatz lesen!

Also noch mal: die biometrischen Merkmale werden lediglich LOKAL genutzt, um den TPM „aufzuschließen“!

Das heißt wiederum, dass die biometrischen Daten NICHT/NIEMALS das lokale Windowsgerät verlassen (dürfen)!

Puh, also werden die biometrischen Daten im TPM gespeichert – aber ist der dafür nicht eigentlich zu klein?

Nein und ja!
Nein, die Daten werden NICHT im TPM gespeichert und ja, der wäre dafür auch schlicht zu klein!

Die biometrischen Daten werden über die in Windows verfügbaren „Data Protection API“ verschlüsselt und geschützt.
D.h. vor allem, dass es keine Möglichkeit gibt die Daten aus Windows zu „extrahieren“ – weder für den User, noch für einen Administrator, noch für einen „unbekannten Dritten“!

Aber noch mal: warum ist das jetzt MFA?

Das ist einfach erklärt: es bedarf entweder „what you know“ (PIN) oder „what you are“ (Finger, Gesicht) plus in jedem Fall „what you have“ (das verwendete Gerät) und lässt sich damit nicht einfach auf einem beliebigen anderen Gerät replizieren („ich schaue bei der Anmeldung über die Schulter und kenne das Passwort und kann in Ruhe von meinem Gerät den Zugriff versuchen“).

„Das ist mir zu wenig! Ich will MEHR SICHERHEIT!“

Aus 2 mach 3 oder mehr!

Ok, verstanden! Und ja, wer mehr will, der kriegt auch mehr – mit einem kleinen „Aber“, siehe dazu weiter unten.

Seit Windows 10 1709 gibt es eine Möglichkeit aus den zwei (Standard-) Faktoren mehr zu machen.

Die Anmeldung an Windows kann dahingehend erweitert werden, dass neben z.B. dem Gesicht auch zusätzlich der Pin abgefragt wird und erst dann die Authentication (bzw. „das Öffnen des TPM“ vgl. oben) erfolgt.

Neben den bereits von WHfB bekannten Faktoren kann noch ein weiter Mechanismus genutzt werden, die sog. „Trusted Signals“.

Trusted Signals sind Signale, die Windows „mitbekommt“, die aber nicht zwingend den gleich hohen Sicherheitskriterien entsprechen, wie z.B. die Gesichtserkennung.

Das macht auch eigentlich gar nichts, denn es sind ja „zusätzliche“ Mechanismen.

Dazu zählen

1. Konfiguration des aktuellen Netzwerkes (z.B. SSID, IPv4/6 konfig, …)
2. Nähe eines „der Windows-Instanz per Bluetooth bekanntes Devices“
   Wobei „Nähe“ ganz spannend ist, denn durch die erfasste Signalstärke kann Windows tatsächlich sehr genau die Nähe bestimmen und entscheiden, ob „Nah“ nah genug ist. Ganz ähnlich wie die Erfassung der „Nähe“ der Covid-19 App zur Kontaktnachverfolgung!

Das Schöne ist, dass diese Mechanismen kombiniert werden können und zu u.a. folgenden Szenarien führen kann:

1. Der/die Mitarbeitende befindet sich in Reichweite eines bekannten Netzwerkes (z.B. WiFi des Arbeitsplatz oder angeschlossen an ein Netzwerkkabel). Dann muss lediglich freundlich in die Kamera gelächelt werden und die Authentication ist für diese*n Mitarbeitende*n unter der Haube um die Überprüfung des Netzwerkes erweitert worden. Für die Usability hervorragend!
2. Wie 1. – nur diesmal am Flughafen: nun muss zusätzlich noch neben dem freundlichen Lächeln der PIN eingegeben werden. Ein Schritt mehr, aber trotzdem sehr einfach.
3. Wie 2. – nur diesmal ist auch das Smartphone mit Windows „verheiratet“ und in der Nähe des Devices: hier entfällt – genau wie in 1. – der zweite, manuelle Schritt und durch die Nähe des Smartphones ist die Usability wieder erhöht worden, ohne die Sicherheit (signifikant) zu senken.

Fein, und wie konfiguriert man dies nun?

Das ist nicht ganz trivial, aber sehr gut dokumentiert – ich möchte hier daher nur ein, zwei Dinge benennen, die ggf. kleine Stolperfallen sind:

Die Konfiguration selber wird über eine Group Policy durchgeführt, welche wiederum GUIDs und ggf. eine XML Anweisung enthält:

Die GUIDs für die credential provider sind hier zu finden: Multi-factor Unlock – Windows security | Microsoft Docs und sind in der Policy durch ‘,‘ zu trennen, also {GUID1},{GUID2}.

D.h., dass ich im ersten und zweiten Feld damit definieren kann, welche Faktoren jeweils zugelassen sind.

WICHTIG: meine Empfehlung ist, dass hier nicht groß „eingeschränkt“ werden sollte, siehe mein „ABER“!

Spannend wird es dann bei den „signal rules“.

Basierend auf XML können diese nämlich durch „ODER“ (bzw. konkret durch <or>) und „UND“ (also <and>) kombiniert werden, so dass das o.g. Szenario mit Phone ODER Netzwerk genutzt werden kann.

Beispielhaft könnte das so aussehen:

<rule schemaVersion="1.0">
  <or>
    <signal type="ipConfig">
      <ipv4Prefix>10.10.1.0/24</ipv4Prefix> 
      <ipv4Gateway>10.10.1.1</ipv4Gateway>
      <ipv4DhcpServer>10.10.1.10</ipv4DhcpServer>
      <ipv4DnsServer>10.10.1.10</ipv4DnsServer>
      <dnsSuffix>corp.contoso.com</dnsSuffix>
    </signal>
    <signal type="bluetooth" scenario="Authentication" classOfDevice="512" rssiMin="-10" rssiMaxDelta="-10"/>
    <signal type="wifi"> 
      <ssid>contoso</ssid> 
      <bssid>12-ab-34-ff-e5-46</bssid> 
      <security>WPA2-Enterprise</security> 
      <trustedRootCA>a2 91 34 aa 22 3a a2 3a 4a 78 a2 aa 75 a2 34 2a 3a 11 4a aa</trustedRootCA> 
      <sig_quality>80</sig_quality> 
    </signal>
  </or>
</rule>

D.h. hier habe ich die Trusted Signals „ipConfig“, „wifi“ und „bluetooth“ miteinander oder-kombiniert!
FYI: <and> ist auch möglich, würde ich aber i.d.R. von abraten, siehe mein „ABER“.
Hinweis: für die Sichtbarkeit habe ich das XML eingerückt, für die GPO bitte alles in eine Zeile ohne Leerzeichen zwischen den Elementen bringen!

ABER

Ist doch viel sicherer, warum dann ein „Aber“?

Sicherer ja, aber manchmal auch fehleranfälliger.
Daher meine Empfehlung unbedingt immer mehr als einen Faktor zur Verfügung zu stellen (sowohl für den ersten als auch für den zweiten), denn aus eigener Erfahrung kann ich euch sagen:

• nicht immer ist die Lichtsituation so, dass die Gesichtserkennung sofort und 200% zuverlässig funktioniert.
• Nicht immer funktioniert das Netzwerk so, wie es konfiguriert wurde.
• Nicht immer ist das Smartphone in der Nähe, hat Akku und Bluetooth ist aktiviert

Das wiederum bedingt, dass die User darauf geschult werden MÜSSEN „was mache ich wenn und was ist ‚wenn‘ überhaupt“!

Wenn das „vergessen“ wird, dann wird es zwangsweise zu einem erhöhten Supportaufkommen kommen!

FAZIT und Empfehlung

Ich selbst nutze dieses Feature seitdem es implementiert worden ist.
Normalerweise bekomme ich das auch gar nicht mit, denn mein Netzwerk funktioniert meistens, mein Telefon ist meistens in der Nähe und überhaupt, auch das Licht passt meistens für die Gesichtserkennung.

Damit möchte ich sagen:

ja, dies ist ein gangbarer Weg, um die Sicherheit weiter zu erhöhen!

Vor allem für folgende beiden Szenarien würde ich daher diesen Weg sogar erzwingen:

1. PAW/SAWs – muss ich glaub ich nicht wirklich erklären warum
2. Feste Arbeitsplatzrechner, insb. wenn diese per Kabel angeschlossen sind
   – denn, damit kann das „Wegtragen“ zusätzlich abgesichert werden, auch wenn der/die „Wegtragende“ das erst am neuen Einsatzort feststellen dürfte.

Allerdings müssen für die User*innen die entsprechenden Schulungen sichergestellt sein. Sollte das zu aufwendig sein, oder die Nutzerschaft „zu weit weg“ sein, dann würde ich gemäß meines ABERs, dieses Feature nicht nutzen.

Übrigens: Dieser Mechanismus lässt sich super durch „Dynamic Lock“ ergänzen, bei dem sich Windows automatisch „Win+L“ed (also locked), wenn das Smartphone sich zu weit von der Maschine entfernt!

Ich finde das super!