Inhalt

Journey To Passwordless: Temporary Access Pass

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. 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 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.

Info
Aktuell befindet sich TAP noch in der Public Preview. In meinen Tests hat sich aber gezeigt, dass diese Funktion sehr gut funktioniert.

Temporary Access Pass erstellen

Zeit den ersten Benutzer mit einem TAP zu versorgen.

Nachdem ein neuer 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:

/journey-passwordless-temporary-access-pass/images/TimingProblem.png

Nach ein bis zwei Minuten sollte sich das Problem von selbst gelöst haben. Es handelt sich wahrscheinlich um ein Timingproblem bei der Benutzeranlage.

/journey-passwordless-temporary-access-pass/images/AddAuthenticationMethod.png

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.

/journey-passwordless-temporary-access-pass/images/SwitchToNewAuthExperience.png

Über “Add authentication method” kann nun ein Temporary Access Pass erstellt werden.

/journey-passwordless-temporary-access-pass/images/AddTAPOneTimeUse.png

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.

Warnung
Der TAP kann später nicht mehr eingesehen werden. Wer es verpasst hat Ihn sich zu notieren muss den Vorhanden löschen und einen Neuen erstellen.

/journey-passwordless-temporary-access-pass/images/TemporaryAccessPass.png

Praktischerweise blendet Microsoft auch gleich die URL zur Initialeinrichtung einer sicheren Anmeldemethode mit ein.

aka.ms/mysecurityinfo

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.

/journey-passwordless-temporary-access-pass/images/MaximumOfOneActiveTAP.png

PowerShell und Graph API

Das 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

/journey-passwordless-temporary-access-pass/images/PowerShellNew-MgUserAuthenticationTemporaryAccessPassMethod.png

Anzeigen des TAP

# List TAP registered to a user
Get-MgUserAuthenticationTemporaryAccessPassMethod -UserId 849189be-c4c1-4873-aabd-570604214c0a

/journey-passwordless-temporary-access-pass/images/PowerShellGet-MgUserAuthenticationTemporaryAccessPassMethod.png

Entfernen des TAP

Remove-MgUserAuthenticationTemporaryAccessPassMethod -UserId 849189be-c4c1-4873-aabd-570604214c0a -TemporaryAccessPassAuthenticationMethodId 149e0573-c362-429a-9a33-bd8a1d5b632d

/journey-passwordless-temporary-access-pass/images/PowerShellRemove-MgUserAuthenticationTemporaryAccessPassMethod.png

Graph Explorer

Über den Microsoft Graph Explorer kann man auch direkt die API Endpunkte ansprechen.

/journey-passwordless-temporary-access-pass/images/GraphExplorer.png

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.

Info
Mittels TAP kann man keinen neuen Windows Computer onboarden. Egal ob Autopilot oder Out-of-Box-Experience (OOBE), hier ist z.B. ein FIDO2 Security Key für die Authentifizierung notwendig.

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.

/journey-passwordless-temporary-access-pass/images/TAPSignInExperience.png

Bei einer Anmeldung mittels Benutzername und Passwort wäre der Benutzer nun aufgefordert worden das Passwort zu ändern.

/journey-passwordless-temporary-access-pass/images/ChangePassword.png

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.

/journey-passwordless-temporary-access-pass/images/TAPSignIn-3-MySignInsPortalCorrect.png

Jetzt “USB device” auswählen und den nächsten Hinweis mit Next bestätigen.

/journey-passwordless-temporary-access-pass/images/SecurityKeyChoice.png

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.

/journey-passwordless-temporary-access-pass/images/TAPSignIn-7-9.png

Abschließend muss noch ein sprechender Name für den Security Key hinterlegt werden.

/journey-passwordless-temporary-access-pass/images/TAPSignIn-10-NameYourKey.png

Ab sofort kann der Benutzer sich mit seinem Security Key am 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.

/journey-passwordless-temporary-access-pass/images/MoreInformationRequired.png

Dieser erlaubt aktuell nur das Hinzufügen der Microsoft Authenticator App. Die Einrichtung eines FIDO2 Security Keys ist erst anschließend möglich.

/journey-passwordless-temporary-access-pass/images/SSPRFlowOnlyAuthenticatorApp.png

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 Azure AD Rollen SSPR im Standard erzwingen, sollte dies theoretisch alle Administratoren treffen.

Info
In meinen Tests trat das Verhalten ein einziges Mal auf.
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.

Wann geht's weiter?
Der nächste Blogeintrag erscheint vorraussichtlich am 24.05.2021.