There are many ways to overcome the many challenges of user lifecycle management, especially the onboarding of a new employee. While creating the new account and its birthrights with pricey solution like Quest One Identity Manager is a breeze, almost all solutions lack the “out of the box”-ability to secure a new account with more than a complex password.

How do you onboard a new employee if he is e.g. a remote worker and is not able to visit the office to be in a mostly secure environment to reach the “register security information”-page to setup your multi factor authentication. Because if you don’t secure that page with conditional access it is possible that every new account gets taken over without you or the user knowing it.

Let’s play this out:

1. You create the account with an complex initial password.
2. The new colleague gets his equipment by parcel and is ready to go thanks to Windows Autopilot or macOS DEP
3. You send the credentials probably to his supervisor some days in advance. (you shouldn’t!)
   • Maybe the supervisor is on holiday and another colleague takes over the duty and has access to it
   • Maybe the supervisor forwards the credentials to the private email address of the new colleague
   • Maybe the new colleague calls his supervisor (or his stand in) and they try to spell the complex password over the phone (good luck)

It’s already at that stage not guaranteed that nobody logged in with the account and did setup multi factor authentication if the “register security information”-page is not secured. And when your conditional access policies are setup like “no multi factor if trusted location or compliant (or even only entra hybrid / joined) device”, you would also not notice that there is a rogue registration.

The solution should be to always require multi factor authentication when visiting the “register security information”-page. But how do you serve new colleagues (or service partners) with a second factor?

The answer is: You create a TAP, short for Temporary Access Pass.

A Temporary Access Pass (TAP) is a time-limited passcode that can be configured for single use or multiple. Users can sign in with a TAP to onboard other passwordless authentication methods, such as Microsoft Authenticator, FIDO2 and Windows Hello for Business.

https://learn.microsoft.com/en-us/entra/identity/authentication/howto-authentication-temporary-access-pass

To create a TAP you need at least the following Graph API Permission or the role authentication administrator. If you need to manage also privileged accounts, you will need the privileged authentication administrator. Be very careful with that role and only use them with pim.

You can connect with the Graph API PowerShell SDK:

Connect-MgGraph -Scopes "User.Read.All, UserAuthenticationMethod.ReadWrite.All" -ContextScope Process

To create a TAP is very easy and almost a one-liner. First we want to check what options we got when creating it.

So in our case we create a TAP that is only usable a single time and is valid since its creation date for 2 hours. The define that value in our body variable and just run a simple Graph API Post Request to create it against the user object we select via userprincipalname attribute.

$body = @{
    lifetimeInMinutes = 120
    isUsableOnce = $true
}
 
 
Invoke-MgGraphRequest -Method POST 'https://graph.microsoft.com/v1.0/users/Timo.Kaiwe@cloudkreise.de/authentication/temporaryAccessPassMethods' ´
-Headers @{"ConsistencyLevel" = "eventual"} -Body $body
 
Name                           Value
----                           -----
temporaryAccessPass            jaZa6GA5
startDateTime                  20.05.2024 15:16:31
lifetimeInMinutes              120
isUsableOnce                   True
@odata.context                 https://graph.microsoft.com/v1.0/$metadata#users('Timo.Kaiwe@cloudkreise.de')/authentication/temporaryAccessPassMethods/$entity
id                             98d7cfd9-xxxx-xxxx-xxxx-76c1b73f6495
createdDateTime                20.05.2024 15:16:31
methodUsabilityReason          EnabledByPolicy
isUsable                       True

As you can see, the temporaryAccessPass would be “jaZa6GA5” in that case and valid until 20.05.2024 17:16:31. That simple to spell one time code is the key to the “register security information”-page for new employees or service partners without the risk of getting hijacked. Even if the credentials we created in step #1 are leaked it is not possible to register a rogue authentication method for the attacker.

That should be the bare minimum regarding the security of creating new accounts. Depending of the skill of the attacker or the IT-staff (e.g. service desk) it is of course still possible to use social engineering to get around these safety measures.