Last Updated on March 9, 2023 by rudyooms

After reading a question on Reddit in which was asked how Intune knows which device belongs to which organization I decided to write a dedicated blog about this question.

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

I will divide this blog into multiple parts

1. Introduction
2. Removing the MS-Organization-Access certificate
3. Importing the MS-Organization-Access certificate
4. OID’s
5. Cleaned up Intune Objects

1. Introduction

I already wrote a fair amount of blogs about the MS-Organization-Access certificate. In this blog below, I am explaining 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 get a better understanding of how important this wonderful MS-Organization-Access certificate is 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. Also rebooting the device ended up 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?

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 we have seen what happens when removing and importing the MS-Organization-Access certificate on the same device let’s found out what happens when I export and import that MS-Organization-Access certificate on a device enrolled into another tenant.

I made sure 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. OIDS

We only imported the MS-Organization-Access certificate, right? So the Tenant Id 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, when looking at the 1.2.840.113556.1.5.284.5 OID value in the MS-Organization-Access Certificate we can spot a nice 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 know 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 Azure Ad Join, 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 is 1.2.840.113556.5.14

With this information from these certificates, the device knows in which Tenant it’s Azure Ad Joined or AADR and in which Tenant it was MDM enrolled

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 a deletion or retirement of 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! In his blog, he will show you way more details 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!