Journey To Passwordless: Temporary Access Pass
Artikelübersicht
- Passwordless - Aber warum?
- Initiale Konfiguration
- Temporary Access Pass
- FIDO2 Security keys
- Windows 10 Device Onboarding und Windows Hello for Business
- Administrieren mit PowerShell und ohne Passwort
- Microsoft Authenticator app
- FIDO2 Schlüssel einschränken & Fazit
Wiederholung
In den ersten zwei Blogs der Serie habe ich das Konzept und die Vorzüge von Passwordless beleuchtet und die notwendigen Konfigurationsschritte im Entra ID (Azure AD) Tenant vorgenommen. Jetzt wenden wir uns dem ersten Puzzlestück zu einer echten passwortlosen Anmeldung zu.
Dem Temporary Access Pass.
Was ist ein Temporary Access Pass
Bei einem Temporary Access Pass (TAP) handelt es sich um ein Zugangscode für den Anwender. Ähnlich einem Kennwort ist damit eine Erstanmeldung möglich.
Der große Unterschied bei einem TAP ist jedoch, dass dieser nur zeitlich begrenzt nutzbar ist. Dabei ist eine Zeitspanne zwischen einer und acht Stunden wählbar. Eine weitere Einschränkung ist, dass man die Nutzung auf eine Anmeldung beschränken kann.
Da ein FIDO2 Schlüssel aktuell nicht durch einen Administrator für einen Benutzer hinzugefügt werden kann, ist der TAP somit die einzige Möglichkeit einer Initialeinrichtung eines neuen Accounts ohne Passwort.
Temporary Access Pass erstellen
Zeit den ersten Benutzer mit einem TAP zu versorgen.
Nachdem ein neuer Entra ID (Azure AD) Benutzer angelegt wurde, kann über den Menüpunkt “Authentication methods” ein TAP erstellt werden. Bei der Erstellung des Benutzers wird zwar ein Kennwort vergeben, dieses braucht man sich aber nicht notieren.
Meist dauert es einen kleinen Moment bis man bei einem neuen Benutzer die Daten hinterlegen kann. Wenn man zu schnell ist kommt folgende Fehlermeldung:
Nach ein bis zwei Minuten sollte sich das Problem von selbst gelöst haben. Es handelt sich wahrscheinlich um ein Timingproblem bei der Benutzeranlage.
Sollte noch die die legacy User Authentication Methods Experience aktiv sein, muss man diese mit einem Klick auf “Switch to the new user authentication methods experience” zur neuen Ansicht wechseln.
Über “Add authentication method” kann nun ein Temporary Access Pass erstellt werden.
Bei der Erstellung kann man die zeitliche Gültigkeit des TAP manuell verändern. Wenn in der globalen Konfiguration keine Einschränkungen durchgeführt wurden sind 1 Stundenintervalle von ein bis 8 Stunden möglich.
Auch kann konfiguriert werden ob der TAP mehrmals oder nur einmal genutzt werden kann. Diese Destroy After Use Funktion ist optional und hat auch Ihre negativen Seiten.
So ist es z.B. notwendig, dass der Anwender spätestens 10 Minuten nach der Anmeldung eine alternative Anmeldemethode, z.B. einen FIDO2 Security Key oder die Authenticator App, hinterlegt haben muss. Leider wird der Anwender bisher nicht auf diesen Umstand hingewiesen.
Anschließend wird der TAP im Klartext angezeigt und kann dem Anwender übermittelt werden.
Praktischerweise blendet Microsoft auch gleich die URL zur Initialeinrichtung einer sicheren Anmeldemethode mit ein.
Mehrere aktive TAPs?
Es kann pro Benutzer immer nur nur einen aktiven TAP geben. Aber nach Ablauf dieses TAP kann ein neuer erstellt werden und der vorhandene wird überschrieben.
Solange der vorhandene TAP gültig ist ist dies nicht möglich, man muss diesen erst entfernen und kann dann einen Neuen hinzufügen.
PowerShell und Graph API
Das Entra ID (Azure AD) PowerShell Module unterstützt die neue Authentication Method API aktuell weder im GA Release (2.0.2.130) noch in der Preview (2.0.2.134).
Mit dem Microsoft Graph PowerShell Modul ist eine Verwaltung der neuen Authentication Methoden möglich, man muss aber die Beta Graph API nutzen.
# Install module
Install-module Microsoft.Graph.Identity.Signins -Scope CurrentUser
# Connect to Microsoft Graph API using Device Authentication and with correct API permissions
Connect-MgGraph -Scopes UserAuthenticationMethod.ReadWrite.All
# Switch to beta API
Select-MgProfile -Name beta
TAP erstellen
# Create a one time usable TAP, valid for 61 minutes
$TAP = New-MgUserAuthenticationTemporaryAccessPassMethod -UserId 849189be-c4c1-4873-aabd-570604214c0a -IsUsableOnce -LifetimeInMinutes 61
# Retrieve TAP
$TAP.TemporaryAccessPass
Anzeigen des TAP
# List TAP registered to a user
Get-MgUserAuthenticationTemporaryAccessPassMethod -UserId 849189be-c4c1-4873-aabd-570604214c0a
Entfernen des TAP
Remove-MgUserAuthenticationTemporaryAccessPassMethod -UserId 849189be-c4c1-4873-aabd-570604214c0a -TemporaryAccessPassAuthenticationMethodId 149e0573-c362-429a-9a33-bd8a1d5b632d
Graph Explorer
Über den Microsoft Graph Explorer kann man auch direkt die API Endpunkte ansprechen.
https://graph.microsoft.com/beta/users/849189be-c4c1-4873-aabd-570604214c0a/authentication/methods
Als Ergebnis werden alle registrierten Anmeldemethoden zurückgeliefert. Der TAP hat dabei folgendes Format.
{
"@odata.type": "#microsoft.graph.temporaryAccessPassAuthenticationMethod",
"id": "149e0573-c362-429a-9a33-bd8a1d5b632d",
"temporaryAccessPass": null,
"createdDateTime": "2021-05-13T15:22:52.879393Z",
"startDateTime": "2021-05-13T15:22:52.6349677Z",
"lifetimeInMinutes": 480,
"isUsableOnce": false,
"isUsable": true,
"methodUsabilityReason": "EnabledByPolicy"
}
Temporary Access Pass nutzen
Nachdem der TAP erstellt und dem Benutzer, natürlich über eine sichere Methode, übermittelt wurde kann dieser sich das erste Mal anmelden.
Hier kommt aktuell noch weitere Einschränkung zum Tragen die man berücksichtigen muss.
Somit sollte die Ersteinrichtung an einem vorhandenen, abgesicherten Computer mittels Browser durchgeführt werden. Erst danach kann der Benutzer seine Privileged Admin Workstation (PAW) in Betrieb nehmen.
Anmeldung
Die Einrichtung erfolgt über die My Security Information Website.
Bei der Anmeldung wird der Unterschied zu einer Erstanmeldung mittels Passwort schnell deutlich. Nach Eingabe des Benutzernamens wird kein Passwort abgefragt, sondern der Temporary Access Pass. Ist die Eingabe korrekt wird man direkt Portal umgeleitet.
Bei einer Anmeldung mittels Benutzername und Passwort wäre der Benutzer nun aufgefordert worden das Passwort zu ändern.
Nach der erfolgreichen Anmeldung muss der Benutzer nun ein zusätzliche Methode für die Anmeldung hinzufügen. Im folgenden Beispiel nutze ich dazu einen FIDO2 Security Key. In den weiteren Blogs werde ich näher auf diese Art der Anmeldung eingehen und auch die Alternative “Authenticator App” präsentieren.
FIDO2 Security Key einrichten
Im Portal “Add method” auswählen und anschließend als Methode “Security key” wählen.
Jetzt “USB device” auswählen und den nächsten Hinweis mit Next bestätigen.
Nun wird man vom Windows aufgefordert den Zugriff auf den FIDO2 Security Key zuzulassen, zusätzlich muss man zustimmen das bestimmte Schlüssel Informationen an login.microsoft.com gesendet werden und ein Credential auf dem Schlüssel erstellt wird. Abschließend muss man nun die Aktion am FIDO2 Security Key bestätigen. Bei anderen FIDO2 Modellen kommt es zusätzlich zu einer PIN Abfrage. Der eingesetzte FIDO2 Security Key unterstützt jedoch auch Fingerabdrücke für die Freischaltung, was die Einrichtung etwas bequemer macht.
Abschließend muss noch ein sprechender Name für den Security Key hinterlegt werden.
Ab sofort kann der Benutzer sich mit seinem Security Key am Entra ID (Azure AD) anmelden und der TAP wird nicht mehr benötigt.
Besonderheiten mit Self Service Password Reset (SSPR)
Ist der Benutzer teil der Self Service Password Reset (SSPR) Policy wird nach der Erstanmeldung der SSPR Registration Flow erzwungen.
Dieser erlaubt aktuell nur das Hinzufügen der Microsoft Authenticator App. Die Einrichtung eines FIDO2 Security Keys ist erst anschließend möglich.
Grundsätzlich sollte die Funktion SSPR für Benutzer die 100% ohne Passwort arbeiten sollen, deaktiviert werden. Ansonsten können Sie über diese Hintertür wieder ein Passwort erlagen.
Da bei Benutzern in bestimmten administrativen Entra ID (Azure AD) Rollen SSPR im Standard erzwingen, sollte dies theoretisch alle Administratoren treffen.
Nachdem ich der Wert
SelfServePasswordResetEnabled in meinem Tenant erst deaktiviert und dann wieder aktiviert habe, konnte ich es nicht länger nachvollziehen.# Aktuellen Wert überprüfen
Get-MsolCompanyInformation | Select SelfServePasswordResetEnabled
# Anpassen
Set-MsolCompanySettings -SelfServePasswordResetEnabled $false
Kann ich immer noch ein Passwort nutzen?
Das bei der Benutzererstellung zwingend erforderliche Passwort kann aktuell nicht entfernt werden. Auch kann zum jetzigen Zeitpunkt eine Anmeldung mittels Passwort nicht verhindert werden. Jedoch kann durch eine Conditional Access Policy der Einsatz einer startken Authentifizierung mittels MFA bzw. eines Security Keys erzwungen werden. Somit ist ein Angriffsszenario bei dem der Angreifer das Kennwort errät sehr unwahrscheinlich.
Eine Änderung des Passworts ist für den Benutzer ebenfalls nicht möglich, da das bestehende Passwort nicht bekannt ist. Natürlich müssen Features wie SSPR für den Benutzer ebenfalls deaktiviert werden.
Nächste Schritte
Im nächsten Blogpost werde ich mich detaillierter mit der Einrichtung von FIDO2 Security Keys und der Anmeldung mit diesen beschäftigen. Dabei werde ich zwei FIDO2 Security Keys, die keine PIN erfordern, vorstellen. Das Ziel ist ja zu 100% ohne PIN- oder Passworteingabe auszukommen.