Journey To Passwordless: Temporary Access Pass
Blog series
- Passwordless: But why?
- Enable passwordless
- Temporary Access Pass
- FIDO2 Security keys
- Windows 10 device onboarding and Windows Hello for Business
- PowerShell administration without a password
- Microsoft Authenticator app
- Restrict FIDO2 key usage & conclusion
Recap
In the first two blogs of the series, I highlighted the concept and benefits of Passwordless and took the necessary configuration steps in the Entra ID (Azure AD) Tenant. Now we turn to the first piece of the puzzle towards a true passwordless sign-in.
The Temporary Access Pass.
What is a Temporary Access Pass
A Temporary Access Pass (TAP) is an access code for the user. Similar to a password, it can be used to sign in for the first time.
The big difference with a TAP, however, is that it can only be used for a limited time. A period between one and eight hours can be selected. Another restriction is that the use can be limited to a single sign-in.
Since a FIDO2 key currently cannot be added by an administrator for a user, the TAP is thus the only option for initial setup of a new account without a password.
Create a Temporary Access Pass
Time to provide the first user with a TAP.
After a new Entra ID (Azure AD) user has been created, a TAP can be created via the menu item “Authentication methods”. A password is assigned when the user is created, but you do not need to write it down.
Usually it takes a short moment until you can add the data for a new user. If you are too fast the following error message appears:
After one or two minutes, the problem should have resolved itself. It is probably a timing problem with the user creation.
If the legacy User Authentication Methods Experience is still active, you have to switch it to the new experience by clicking on “Switch to the new user authentication methods experience”.
A Temporary Access Pass can now be created via “Add authentication method”.
When creating the TAP, you can manually change its validity period. If no restrictions have been made in the global configuration, 1 hour intervals from one to 8 hours are possible.
It is also possible to configure whether the TAP can be used several times or only once. This Destroy After Use function is optional and also has its negative sides.
For example, the user must have stored an alternative sign-in method, e.g. a FIDO2 security key or the Authenticator app, no later than 10 minutes after sign-in. Unfortunately, the user is not made aware of this fact.
The TAP is then displayed in plain text and can be sent to the user.
Conveniently, Microsoft also displays the URL for the initial setup of a secure login method.
Multiple active TAPs?
There can only ever be one active TAP per user. But after this TAP expires, a new one can be created and the existing one will be overwritten.
As long as the existing TAP is valid this is not possible, you have to remove it first and then you can add a new one.
PowerShell and Graph API
The Entra ID (Azure AD) PowerShell Module does not currently support the new Authentication Method API in either the GA release (2.0.2.130) or the preview (2.0.2.134).
With the Microsoft Graph PowerShell module it is possible to manage the new authentication methods, but you have to use the Beta Graph API.
# 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
Create a TAP
# 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
Show a TAP
# List TAP registered to a user
Get-MgUserAuthenticationTemporaryAccessPassMethod -UserId 849189be-c4c1-4873-aabd-570604214c0a
Remove a TAP
Remove-MgUserAuthenticationTemporaryAccessPassMethod -UserId 849189be-c4c1-4873-aabd-570604214c0a -TemporaryAccessPassAuthenticationMethodId 149e0573-c362-429a-9a33-bd8a1d5b632d
Graph Explorer
Via the Microsoft Graph Explorer you can also directly access the API endpoints.
https://graph.microsoft.com/beta/users/849189be-c4c1-4873-aabd-570604214c0a/authentication/methods
As a result, all registered logon methods are returned. The TAP has the following 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"
}
Use a Temporary Access Pass
After the TAP has been created and sent to the user, of course via a secure method, the user can sign-in for the first time.
This is where another restriction comes into play that must be taken into account.
Thus, the initial setup should be performed on an existing, secured computer using a browser. Only then can the user put his Privileged Admin Workstation (PAW) into operation.
Sign-In
The setup is done via the My Security Information website.
When signing in, the difference to an initial sign-in using a password quickly becomes clear. After entering the user name, no password is requested, but the Temporary Access Pass. If the entry is correct, you will be redirected directly to the portal.
With a sign-in by means of user name and password, the user would now have been prompted to change the password.
After the successful sign-in, the user must now add an additional method for sign-in. In the following example I use a FIDO2 Security Key. In the following blogs I will go into more detail about this sign-in method and also present the “Authenticator App” as a alternative.
Setup a FIDO2 security key
In the portal, select “Add method” and then select “Security key” as the method.
Now select “USB device” and confirm the next message with Next.
Now you will be asked by Windows to allow access to the FIDO2 Security Key, additionally you have to agree that certain key information will be sent to login.microsoft.com and a credential will be created on the key. Finally, you have to confirm the action by touching the respective area on the FIDO2 Security Key. With other FIDO2 models there is an additional PIN request. However, the FIDO2 Security Key used also supports fingerprints for unlocking, which makes the setup a bit more convenient.
Finally, a descriptive name must be entered for the security key.
From now on, the user can sign-in to Entra ID (Azure AD) with their security key and the TAP is no longer needed.
Special considerations with Self Service Password Reset (SSPR)
If the user is part of the Self Service Password Reset (SSPR) policy, the SSPR registration flow is forced after the initial sign in.
This currently only allows the Microsoft Authenticator app to be added. The setup of a FIDO2 Security Key is only possible afterwards.
Basically, the SSPR function should be deactivated for users who are to work 100% without a password. Otherwise, you can use this loophole to obtain a password again.
Since users in certain administrative Entra ID (Azure AD) roles enforce SSPR by default, this should theoretically affect all administrators.
After first disabling and then re-enabling the
SelfServePasswordResetEnabled value in my tenant, I could no longer reproduce it.# Aktuellen Wert überprüfen
Get-MsolCompanyInformation | Select SelfServePasswordResetEnabled
# Anpassen
Set-MsolCompanySettings -SelfServePasswordResetEnabled $false
Can I still use a password?
The password, which is mandatory when creating a user, cannot be removed at the moment. It is also not possible to prevent sign-in using a password at this time. However, a conditional access policy can be used to force the use of a start-up authentication via MFA or a security key. Thus, an attack scenario in which the attacker guesses the password is very unlikely.
Changing the password is also not possible for the user, since the existing password is not known. Of course, features such as SSPR must also be disabled for the user.
Next steps
In the next blog post, I will go into more detail about setting up FIDO2 Security Keys and signing-in with them. I will introduce two FIDO2 Security Keys that do not require a PIN. The goal is to get along 100% without PIN or password entry.