After a nice talk with Yannick Van Landeghem, who made me aware of a “possible” security gap when using a Temporary Access Pass (TAP), I decided to write a blog with a huge title about it. I will show you some important stuff you need to be aware of! I am not going to tell you anything new here, only raise some awareness… nothing more…
1. Introduction
When we discuss the temporary access pass (TAP), I will first need to explain in Microsoft’s own words what we can do with it.
“A Temporary Access Pass (TAP) is a time-limited passcode issued by an admin that satisfies STRONG AUTHENTICATION requirements and can be used to onboard other authentication methods, including Passwordless ones such as Microsoft Authenticator or even Windows Hello.”
Looking at the above sentences, it’s pretty clear that we can enroll a nice new device with Autopilot by entering a time-limited passcode
Let’s pretend that I am the IT admin (who wants to quit the company in the near future), and I was asked to enroll a new device for the CFO! This time, I will use TAP instead of pre-provisioning the device with Autopilot!
So let’s start with enabling TAP in the tenant first before enrolling the CFO for TAP. Open portal.azure.com and make sure you click on “Security/Authentication Methods” first. To enable TAP, we only need to click on enable. Duhhhh and target the users you want to provision with TAP
There are some more settings you can configure, but that’s not what this blog is about so let’s add the TAP Authentication method for the selected user
Please note: Remember to copy the TAP, as this is the only time it will be shown!
2. Looking at What happens.
When we enroll our device with Autopilot, you will normally be asked to enter your username, password, and MFA approval (which I obviously don’t have for the CFO), but this time, you will only be asked to put in the Temporary Access Pass instead!
After filling in the TAP, your device will start enrolling into Autopilot, and you will end up staring at the Enrollment Status Page for some time.
Please note: if you are interested in more information about this ESP flow, feel free to check out this blog
Troubleshooting Win32 Apps IME | Retry Failed Win32App GRS (call4cloud.nl)
After the Device is set up, the device “could” perform a reboot, but this time it will NOT reboot (I will show you why later on), and with the “Cached Credentials/Cached Authentication Buffer,” you will be prompted to configure Windows Hello for your Account.
While looking at this nice Windows Hello prompt, we could still easily open all the users his/her Applications. Let me show you how! Let’s press Shift+F10 first but after doing so, just click “no“
After closing the OOBE Create Elevated Object Server prompt, we notice we can open all kinds of things by pressing the “Start” button on your keyboard
You could even open File Explorer and start OneDrive to access the CFO’s personal OneDrive, which may contain sensitive data!
3. That’s Odd I was expecting MFA?
You would normally expect an MFA prompt when you switch to the Account ESP phase, and you would also expect Conditional Access to block access when you require Multifactor authentication
As I told you at the beginning of this blog TAP satisfies the Strong Authentication Requirement.
TAP will be recognized as MFA just like Windows Hello is recognized as MFA
MFA, WHfB, Azure Ad Joined devices, and the Sign-In reports (call4cloud.nl)
This will make sure you are not required for MFA because the MFA requirement was already satisfied by the claim in the token. With NO MFA question and having a golden ticket/SSO to the CFO his session, we could do some harm?
4. But why on earth did we get that SSO?
Let me explain a bit why we got that SSO in the first place! It’s all because of that nice fixed issue when deploying WUFB to devices, and the ManagePreviewBuilds rebootrequired URI
Please Note: I am also mentioning that rebootrequireduri and WUFB in this blog below
Windows 11, WUfB and the Autopilot pre-provisoning issue (call4cloud.nl)
When we are NOT targeting the update ring to DEVICES but to USERS instead, as shown below
We don’t get that wonderful reboot, and without that reboot, we have a nice, wonderful SSO to the CFO in his session. Do you know why I called it a wonderful reboot? If you have read the blog I mentioned before, you will know that this reboot will make sure the device passes its Bitlocker status to the DHA service.
5. Where’s Wally Logging?
Normally, when we assign user permissions to get access to someone else’s mailbox or something similar, it will be logged! Another example would be when changing someone’s password, it will be logged!
When using TAP we need to start looking at the Azure Audit Logs and the Azure Ad Sign-in logs.
When the admin creates the TAP, a new entry will be made in the Audit log. As shown below it mentioned that: “the admin has registered a temporary pass method for user”
When the user starts logging in with the TAP, another log will be created. Let’s open the Azure Ad Sign-In logs. You will notice that the sign-in mentions Multifactor Authentication. To get some details, we need to use the “Authentication Details”
When we look at the “Authentication Details,” we will finally see the TAP mentioned as the authentication method.
Of course, it’s obvious when being an IT admin, you can do a lot… but luckily we always have the Audit and Sign-in logs, right? Please Note: These logs are only maintained for 30 days!
So please make sure you forward these logs or/and put some monitoring on these logs, because you really want to be notified when another IT-Admin registered a TAP for a user
6. Securing it a little bit more
Having that SSO from the user perspective is great, but it could also cause some security issues. As I told you earlier, what if an IT admin was asked to prepare a new device for the CFO and could access all that data without any logs indicating he did?
We need to make sure we have some more security in place to make sure this can’t happen
It sounds pretty obvious, but for some companies, it’s still very hard. To ensure the device can only access Office 365, we need to configure some nice Compliance Policies and Conditional Access Rules.
Let’s start with the Compliance Policy to require Bitlocker
As shown above, we configured a compliance rule to ensure Bitlocker is required. This Compliance rule is configured without any grace period. Because we all know what happens when the device is in a grace period…. If the device fails to report its Bitlocker state to the DHA service, the device isn’t going to be compliant
Configuring Compliance Policies is only 33% because we also need to ensure we enforce the requirement. As shown below, you could create a new Conditional Access Policy to “Require the device to be marked as compliant”
Okay, so we are almost done, but I guess we still need that last 34% covered. Do you remember the blog I mentioned earlier about the SSO we got because the device didn’t reboot? Normally the device needs to perform a reboot and pass that kind of information to the DHA service, as I have also mentioned in this blog
But because we changed the WUFB assignment to users, the device didn’t reboot, and by NOT doing so, the device isn’t compliant
Please note: When the device reboots because this rebootrequired URI or some other configured policy, you are also good to go because, at that time the Cached Authentication Buffer is trashed and you will be prompted to log in
Please note: If you want to know more about this excellent Authentication buffer, please read this part
Autopilot White Glove Pre-Provisioned Deployment Flow (call4cloud.nl)
7. The World TAP is not Enough
When we have implemented conditional access and ensured that all our devices are fully compliant, we still need to be aware of one more setting.
Some time ago I created a blog about using the web sign and how you could configure it to use your MFA Authenticator to log in to your device
https://call4cloud.nl/2021/04/battle-for-the-planet-of-the-credential-providers
As I told you at the beginning of that blog, the option to log in with the MFA authenticator using the web sign-in was removed, and from now on, you can only use it to log in with a Temporary Access Pass (TAP)
Of course, we are also requiring MFA when logging in to our compliant devices, we do NOT exclude our compliant devices!!!! not for all of the money in the world! Or? 🙂 It sounds like a lot…
At the beginning of this blog, I showed you the fact that TAP also satisfies the MFA requirement. So If an IT admin needs to login into a Compliant device without knowing the Windows Hello code or the user his password, he could just use the TAP. Just as with the Autopilot enrollment, the TAP sign-in will be mentioned in the Audit Logs. Besides the Azure Audit logs, we could also use the Windows Event log to determine if TAP was used.
The Windows event log doesn’t show much, except the Shell-Core event log. As shown below, when using TAP to login into your device an event 62407 will be created mentioning an Identity.WindowsLogon.Scenario with the value: AADWEBAUTH.
I guess that event is one of those you really want to monitor using Azure Log Analytics, as described in this blog!
Azure Log Analytics monitor Applocker Azure joined Devices (call4cloud.nl)
I guess we need to add some additional security when we have deployed the option to use the web-sign-in provider to log in to your device. Please make sure you also configure the Multi-Factor unlock options that I also showed you in the blog about the battle of the credential providers!
Conclusion:
Again, I didn’t tell you anything new, but I just wanted to raise some awareness about this TAP flow because not knowing all the pieces of information could have created a gap in your security.
When your IT admin suddenly becomes an insider threat, we need to be notified when he decides to do some bad stuff.
I guess our CISOs and ISO auditors could have an opinion about it?
Thank you so much for this writeup. I found TAP as an available setting in my MFA policy to enable and all I fixated on was the Entra ID language of “Boostrapping new hire device enrollment.” Excellent guide that helped me with my own testing.