Journey To Passwordless: FIDO2 Schlüssel einschränken & Fazit

Artikelübersicht

1. Passwordless - Aber warum?
2. Initiale Konfiguration
3. Temporary Access Pass
4. FIDO2 Security keys
5. Windows 10 Device Onboarding und Windows Hello for Business
6. Administrieren mit PowerShell und ohne Passwort
7. Microsoft Authenticator app
8. FIDO2 Schlüssel einschränken & Fazit

Erweiterte Einschränkungen

Im letzten Blogpost der Serie wird es noch ein wenig technischer. Denn für FIDO2 Security Keys als Anmeldemethode können einige zusätzliche Einstellungen im Azure Portal konfiguriert werden.

• Allow self-service set up
• Enforce attestation
• Enforce key restrictions - Restrict specific keys (Allow/Block)

Allow self-service set up

Diese Einstellung muss Stand 07/2021 zwingend auf “Yes” bleiben. Wenn diese Einstellung auf “No” gestellt wird, ist es keinem Benutzer mehr möglich einen FIDO2 Security Key hinzuzufügen. Da es aber auch nicht möglich ist für den Benutzer einen Schlüssel zu registrieren, würde “No” den Einsatz von neuen Schlüsseln effektiv verhindern.

Enforce attestation

Wenn die Attestation erzwungen wird, muss sich der FIDO2 Schlüssel bei der initialen Registrierung sich gegenüber dem Entra ID (Azure AD) (Relying Party) ausweisen.

Der Hersteller muss, damit der FIDO2 Schlüssel dies überhaupt unterstützt, bei der Zertifizierung ein metadata statement mit den Eigenschaften des FIDO2 Security Keys vorlegen, welches anschließend durch die FIDO2 Alliance verteilt wird. Der Hersteller vergibt für jedes Schlüsselmodell eine Authenticator Attestation Globally Unique ID welche das genaue Modell später identifiziert.

Während der eigentlichen Registrierung fordert das Entra ID (Azure AD) mittels eines policy statement bestimmte Eigenschaften des Schlüssels an. Wenn kein entsprechender Security Schlüssel gefunden wird, ist eine Registrierung nicht möglich.

Unterstützt der Schlüssel alle Anforderungen, in diesem Fall attestation, sendet der FIDO2 Schlüssel zusätzliche Informationen an das Entra ID (Azure AD) zurück. Dazu gehört neben der AAGUID auch eine Signatur, die mit dem privaten Schlüssel des Attestation Zertifikats erstellt wird. Dieser private Schlüssel wird vom Hersteller während der Produktion auf den FIDO2 Security Key geschrieben und wird auch bei einem Reset nicht gelöscht.

Das Entra ID (Azure AD) kann anhand dieser Signatur prüfen, ob der FIDO2 Schlüssel wirklich dem angegebenen Modell entspricht und so verhindern, dass ein FIDO2 Schlüssel nur so tut als unterstütze er alle Anforderungen. Dazu nutzt das Entra ID (Azure AD) die im metadata statement hinterlegten öffentlichen Schlüssel oder prüft ob die Signatur von einem im metadata statement angegebenen Zertifikat (trust chain) signiert wurde.

Authenticator Attestation GUID (AAGUID)

Die Authenticator Attestation Globally Unique ID ist ein eindeutiger Identifier mit einer Länge von 128-bit. Er wird vom Hersteller des Schlüssels vergeben, wobei es ausreicht, dass der Hersteller eine AAGUID pro Modellreihe definiert. Im Fall von Yubikey gibt es hier teilweise auch Dopplungen, da sich die AAGUID nicht auf das Interface des Schlüssels (z.B. USB-C oder USB-A) bezieht, sondern auf den verbauten Security Chip.

Das Format entspricht dem RFC4122 und wird als fünf hexadezimale Abschnitte, getrennt von einem Bindestrich dargestellt.

Beispiel: 0076631b-d4a0-427f-5773-0ec71c9e0279

Diese GUID kann an verschiedenen Stellen im Entra ID (Azure AD) ausgelesen werden.

Security Info Portal

Jeder Anwender kann sich die AAGUID im Bereich Security Info selbst anzeigen lassen.

Azure AD Portal

Als Administrator kann man auch in den Authentifizierungsmethoden des Anwenders, über View details die entsprechenden Informationen abrufen.

Graph API

Und natürlich stehen diese Infos auch in der Graph API zu Verfügung.

https://graph.microsoft.com/beta/users/849189be-c4c1-4873-aabd-570604214c0a/authentication/methods

{
    "@odata.type": "#microsoft.graph.fido2AuthenticationMethod",
    "id": "3f0S9SVSIKt4Ti9ZtgFjSHf7ahkNN3js0FTPe5dPD4o1",
    "displayName": "FEITIAN AllinPass FIDO2",
    "creationDateTime": "2021-05-13T14:19:39Z",
    "createdDateTime": "2021-05-13T14:19:39Z",
    "aaGuid": "12ded745-4bed-47d4-abaa-e713f51d6393",
    "model": "Feitian BioPass FIDO USB/NFC/BLE",
    "attestationCertificates": [
        "4f94e8b002c79416507e9d9d390eca3153e1a5e8",
        "9e3808651ecfa53162772e9d2bc62bfe568350a9"
    ],
    "attestationLevel": "attested"
}

Bekannte AAGUIDs

Folgende AAGUIDs sind mir aktuell bekannt. Ich werde diese Liste, wenn ich noch weitere AAGUIDs finde, erweitern. Yubico bietet auch eine Übersicht auf seiner eigenen Webseite an.

Enforce key restrictions - Restrict specific keys

Mit dieser Option kann man verhindern, das bestimmte Security Keys genutzt werden können. Dabei hat man die Wahl ob man eine Block oder eine Allow Liste pflegen will.

Eine Block-Liste macht in den meisten Fällen Sinn, wenn bekannt ist das bestimmte FIDO2 Schlüssel nicht verwendet werden sollen, weil diese z.B. nicht den gewünschten Sicherheitsansprüchen genügen.

Mittels einer Allow-Liste könnte z.B. der Einsatz von bestimmten von der Firma freigegebenen FIDO2 Schlüsseln erzwungen werden.

Während der Einrichtung bekommt der Anwender nichts von diesen Vorgaben mit. Erst im letzten Schritt bei der Einrichtung, nach der Vergabe eines Namens, wird der Schlüssel abgelehnt.

Im Entra ID (Azure AD) Auditlog wird dies als Status clientError und der Begründung User failed to register Fido angezeigt.

Fazit

Die in dieser Blogreihe betrachteten Einsatzszenarien von Passwordless zeigen, wie umfangreich dieses Thema im Microsoft Kosmos schon unterstützt wird. Gerade in Umgebungen, in denen die Anwender zu 100% mit Cloud-Diensten arbeiten, gibt es eigentlich keinen Grund mehr diesen Weg nicht einzuschlagen.

Neben den vielen Sicherheitsvorteilen bietet die Anmeldung mit FIDO Security Keys, gerade wenn Sie mit biometrischen Merkmalen entsperrt werden können, ein großes Plus beim Nutzungskomfort. Für den Anwender ist diese Art der Authentifizierung durch moderne Smartphones mittlerweile zum Standard geworden und kann nun auch endlich am Arbeitsplatz genutzt werden. Während Windows Hello for Business dies mit der Unterstützung von Kameras und Fingerabdruckssensoren schon seit längerem bietet, bringt der Einsatz von FIDO2 Schlüsseln Vorteile in Bereichen, in denen kein fester Arbeitsplatz genutzt wird und eher an einem Kiosk PC gearbeitet wird.

Bestimmte Einschränkungen, wie z.B. das es nicht möglich ist einen FIDO2 Key für einen Endanwender bereitzustellen, oder dass diese auf Smartphones noch nicht unterstützt werden, trüben den positiven Gesamteindruck etwas. Jedoch gibt es mit der Authenticator App auch hier eine gute Alternative.

In einer stark durch Windows 10 Clients geprägten Umgebung sind die Vorteile für den Anwender schon heute enorm. Verlässt man jedoch dieses Umfeld, muss man auf Apple oder Google hoffen und auf die dort verfügbaren Methoden der Anmeldung in ChromeOS und macOS zurückgreifen. Hier wird der Komfort für den Endanwender, besonders in den oben angesprochenen Kiosk PC Szenarien, geschmälert.

Was ich in dieser Reihe gar nicht betrachtet habe, ist das Arbeiten in einer hybrid Umgebung. Auch hier ist ein passwortloses Arbeiten schon heute möglich, jedoch ist der Planungs- und Implementierungsaufwand um einiges größer. Je nach Nutzungsszenario kann es hier schnell notwendig werden auch eine PKI Umgebung aufzubauen bzw. die vorhandene anzupassen. Das sind alles keine Hinderungsgründe, jedoch birgt die “schnelle” Implementierung einer PKI auch große Risiken.

Mein Ausflug in die Welt ohne Passwort kommt hiermit also nicht zum Ende, aber die nächsten Posts werden in einer eigenen Reihe erscheinen und nicht schon in den nächsten Wochen bereitstehen.