Last Updated on October 30, 2022 by rudyooms
After having a nice talk with “Yannick Van Landeghem” who made me aware of a “possible” security gap when using 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 raising some awareness… nothing more…
I will divide this blog into multiple parts
- Introduction
- Looking at what happens
- That’s odd I was expecting MFA?
- Why that SSO?
- Where’s
Wally..Logging ? - Securing it
- The
WorldTAP is not Enough
1. Introduction
I guess when we are talking about TAP, I will first need to explain in Microsoft their own words what we can do with it.
“A Temporary Access Pass 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 am going to 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 uh 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: Don’t forget to copy the TAP, because this is the only time it will be shown!
2. Looking at What happens.
When we are enrolling our device with Autopilot, you will be asked to enter your username and normally your password and the 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 his personal OneDrive with possible sensitive data in it!
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 are requiring Multifactor authentication
As I was telling 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 USERS as shown below
We don’t get that wonderful reboot and without that reboot we have a nice wonderful SSO to the CFO 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 it will pass the device its Bitlocker status to the DHA service.
5. Where’s Wally Logging?
Normally when we are assigning user permissions to get access to someone else his mailbox or something like this, it will be logged! Another example would be, when changing someone his 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 created the TAP a new entry will be created in the Audit log. As shown below it mentioned that: “the admin has registered a temporary pass method for user”
When the user will start 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 is mentioning MultiFactor Authentication. To get some details we need to use the “Authentication Details”
When taking a look at the “Authentication Details” we will finally see the TAP being 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 was telling you earlier, what if an IT admin was asked to prepare a new device for the CFO and the IT admin could access all of 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 is still very hard. To make sure the device could 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 make sure 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 make sure we are enforcing 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 the pass that kind of information to the DHA service as I am also mentioning 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 we are making sure all our devices are fully compliant, we still need to beware 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
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? 🙂 Sound 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 events you really want to monitor with the use of 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 anything new but I just wanted to raise some awareness about this TAP flow because when not knowing all the pieces of information you could just have created a gap in your security.
When your IT admin suddenly becomes an insider threat we need to make sure we are notified when he decides to do some bad stuff.
I guess our CISOs and ISO auditors could have an opinion about it?
