The TenantID from Toronto

After reading a question on Reddit about how Intune knows which device belongs to which organization, I decided to write a dedicated blog post about this question and how we could retrieve the TenantID From the Entra Device Certificate.

How does Intune know which device belongs to which organization? : Intune (reddit.com)

Hopefully, with this blog, we can get a good understanding of how important the MS-Organization-Access certificate and the Intune MDM device certificate are

1. Introduction

I have already written several blogs about the MS-Organization-Access certificate. In the blog below, I explain how trust is being built between your device and Azure. Please read it before reading the other parts of this blog!

To give you a small summary: It’s all about your TPM, Transport/Device Keys.

2. Removing the MS-Organization-Access certificate!

To better understand the importance of this beautiful MS-Organization-Access certificate, I decided to remove it from a working enrolled device. If you haven’t tried it yourself, just do it! Of course, not on your production device, but that’s obvious, right?

Please note: Before I choose to delete it, I exported it to a .cer file (without the private key… as it’s not exportable of course)

Shall we take a look at the dsregcmd /status output first? The picture below is a screenshot before I deleted the certificate.

As shown above, DSREGCMD is showing us, the fact that our device is “AzureAdJoined” and it is showing us the Device Details. In these details, we are noticing the “Thumbprint” that matches our MS-Organization-Access certificate and the DeviceAuthStatus is a SUCCESS

After deleting this certificate, I rerun the DSREGCMD /status command. This screenshot was taken just 1 second after I deleted the certificate.

As shown above, when the MS-Organization-Access certificate is removed, your device becomes Azure Ad Unjoined instantly!

As the Device Certificate is responsible for a working Azure Ad Join, it broke immediately. Rebooting the device also resulted in the same issue I showed you earlier: a nice login screen with no possibility to log in with your Azure Ad User!

But what happens when we import the old Device Certificate back into the store on that same device? As shown below, as it is missing the private key binding we don’t have the “Key Icon”

Let’s open the CMD again and take a look at what DSREG has to tell us now the cert is back again!

As shown above, the device was immediately Azure Ad joined again. But did you notice the DeviceAuthStatus: Failed. “Device is either disabled or deleted.”

Luckily you could restore the connection with the dsregcmd /forcerecovery option? But why should we when we can use certutil to fix the binding as shown in this blog below?

https://call4cloud.nl/2022/07/privatekey-missing-0x80072f99-sync-intune/#part7

With the use of the certutil -repairstore command, we can fix the binding again because we still have the private key somewhere. You can find it out yourself by running this PowerShell command

$a = Get-ChildItem Cert:\LocalMachine\My\ | where{$_.issuer -like "*MS-Organization-Access*"}
[System.Security.Cryptography.X509Certificates.RSACertificateExtensions]::GetRSAPrivateKey($a).key.uniquename

As shown above, the PowerShell command is giving us the exact location where we need to look

C:\ProgramData\Microsoft\Crypto\PCPKSP\

Let’s take a look at dsregcmd, and the Device Certificate after we repaired the certificate store with the command above.

As shown above… the problem with the private key missing is fixed and everything is working again.

3. Importing the MS-Organization-Access certificate

Now that we have seen what happens when removing and importing the MS-Organization-Access certificate on the same device, let’s find out what happens when I export and import that MS-Organization-Access certificate on a device enrolled in another tenant.

I ensured I copied that cert to another device already enrolled into another tenant and removed the already present MS-Organization-Access certificate. You can guess what happens when you import the MS-Organization-Access certificate from a device enrolled in tenant a to a device enrolled in tenant b

Opening the CMD and looking at the output of dsregcmd /status will show you the same DeviceAuth error we noticed earlier. DeviceAuthStatus d009200b

But did you also notice the change in the TenantName? When removing the corresponding MS-Organization-Access certificate and importing one from another tenant, the device suddenly becomes Azure Ad Joined to another tenant! You can even log-in with a user from that specific tenant!

How the hell is that possible?

4.TenantID / OIDS

We only imported the MS-Organization-Access certificate, right? So the TenantID Information NEEDS to be in the certificate! Let’s find out, shall we?

When looking at the Device certificate, you will need to start looking at the certificate details and to be specific we need to start looking at the Object Identifier (OID). An OID is nothing more than “a sequence of numbers in a format described by [RFC1778]. In many LDAP directory implementations, an OID is the standard internal representation of an attribute”

The representation of an attribute.…. sounds just like the thing we need, right?

As shown above, the 1.2.840.113556.1.5.284.5 OID value in the MS-Organization-Access Certificate shows a scrambled DER-encoded value!

First remove the 04(BITSTRING), 81 (the length of length in bytes), and 10 (the length of the data in bytes) The part that is left behind we can glue back together to get back our TenantID.

As shown above, the scrambled value is the actual Tenant ID. When looking at the MS-Organization-Access certificate, we also could see if the device was Azure Ad Joined or Azure Ad registered. This one is a little bit easier to unscramble!

As shown above, the 1.2.840.113556.1.5.284.7 value is giving us the information we need to know if the device was Azure Ad Joined (1) or Azure Ad registered (0)

When running a Trace during the Entra ID, we will notice that the process also uses this OID to determine the join status and the tenant ID.

Of course, the same goes for the Microsoft Intune MDM Device CA Certificate! The OID we need to check to determine the TenantID/AccountID is 1.2.840.113556.5.14

With this information from these certificates, the device knows which Tenant it Entra ID Joined or AADR and in which Tenant it was MDM enrolled. When spending time in Microsoft’s code, it became pretty clear that Microsoft itself is looking for a different OID to determine the Account ID/Tenant ID

As shown above, Microsoft looks at the 1.2.840.113556.5.6 OID to determine the customer’s Tenant ID (AccountID).

5. Cleanup Intune Devices

I guess most of us are using clean-up rules, right?

When you are using clean-up rules to keep your Intune environment nice and clean, and a device that hasn’t checked in for, let’s say, 30 days, it will be hidden from the Intune Portal, not Deleted!! (even when the Intune Portal tells us otherwise!)

Without deleting or retiring the device, the Intune certificate will remain valid and will still be on the device. The Microsoft Intune MDM Device CA Certificate is the trust between your device and Intune, and as long as it doesn’t expire the device will make sure the Intune object will be brought “online” again. Only after 180 days when the Intune MDM device certificates have expired, the device will be deleted by Intune

Conclusion

First of all, I want to thank Dr. Nestori Syynimaa (@DrAzureAD) / Twitter ! because his blogs are the real golden nuggets in this world!

Stealing and faking Azure AD device identities (o365blog.com)

I reached out to him yesterday evening, but while writing down my question, I already stumbled upon his blog! He will show you more details in his blog than I did! so go read it!

Secondly, knowing how stuff works is really really necessary! With this information, your troubleshooting skills will skyrocket, and you will do better at your job!