Azure AD Troubleshooting etc.

First off check this awesome blog post before reading mine. To give credit where due that is an exhaustive list of things to try.

Additionally there’s this blog post from Microsoft. Lastly, there’s also my earlier post on some notes about Azure AD.

The blog post you are currently reading is more for me to note down things I encounter because I happen to fix issues and then forget what I did and the next time it happens I spend time reinventing the wheel. If not already obvious 1) I have a poor memory and 2) the sole purpose of this blog is for me to go back and read what I did in the past. 🙃 I also have a short attention span and poor eyes so sometimes I don’t manage to read my own posts as I find them long and rambling… oh well, can’t keep everyone (including myself) happy. 😎

Benchmark Output

Here’s the output of dsregcmd /status just as a benchmark when things are working:

I always ignore the Ngc Pre-req check section as that’s for Windows Hello for Business and I haven’t used that yet.

The first section of Device State is what I usually look at. That tells me if a device is Azure AD joined or not (and if it’s both Azure AD joined and Domain joined then it’s implicitly Azure AD Hybrid joined).

The Tenant details has my Azure AD tenant ID and name. The Device details has the Device ID (which should match with Azure AD – more on this below). The SSO State section tells if I have a Primary Refresh Token (PRT) – required for Seamless SSO (i.e. when using (Hybrid) Azure AD). So far so good.

Broken Output

Here’s an example output when this is broken:

Again, ignore Ngc. (So difficult to ignore it though – when there’s an error and I see the WillNotProvision as that’s at the end of the output my first instinct is “aha! that’s broken”).

Older version (and somewhat broken) Output

The “benchmark” output format I pasted above can change depending on your Windows version. The above output is from Windows 10 2004 but things were slightly different with older version. For instance, the output a colleague sent me for one of his machines (Windows 10 1607 I think) looked like this:

Notice the Device State, Device Details, and Tenant Details were all together. No mention of SSO here – that’s not a limitation of the older output, it’s a symptom of the error in this case.

The above is an example of something I wanted to record here. In this case my colleague was getting the following error:

If I looked in Azure AD I could see his machine but it had a Pending status. And in the output above while it looked good at first glance (had more URLs and Tenant info than the broken version) it too said the device wasn’t Azure AD joined… and the SSO section was missing as I noticed above.

Looking more into this I realized that the Device ID in the dsregcmd /status output was different to the Device ID of the same device in Azure AD. Not sure why. So I asked him to do a dsregcmd /leave, reboot the machine and login as usual… and that fixed the issue. I wasn’t sure this would work and whether I will have to remove the device entry from Azure AD, but dsregcmd /leave removed and re-added I think. Nice!

Device ID

So what is the Device ID? This is the GUID of the machine in Azure AD. It is tied to the state of the machine too – so a machine that is Azure AD registered has one Device ID, when the same machine becomes Azure AD hybrid joined for instance the Device ID changes (this is why you’ll see the same machine twice in Azure AD sometimes – the older one will be automatically removed).

The Device ID is stored in the registry at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CloudDomainJoin\JoinInfo.

A thing to remember is that when cloning machines that are already (Hybrid) Azure AD joined, tools like sysprep won’t delete the Device ID. This in itself may not be a problem because when the cloned machine rejoins Azure AD it can generate a new Device ID – but this is something to bear in mind. Try and not clone (Hybrid) Azure AD joined machines as sysprep isn’t aware of this.

Hybrid join failing

And this is a good segue into the issue I ran across today. A colleague had cloned a bunch of Hybrid Azure AD joined machines. Users on these machines were having trouble because conditional access was kicking in and stopping them from using Teams etc. as it required a Hybrid Azure AD joined machine. These machines however were not appearing in Azure AD at all, and dsregcmd /status had the broken output I showed at the beginning of this post (the second of my outputs at the top).

To troubleshoot I took a look at Microsoft-Windows-User Device Registration/Admin in the Event Viewer and found the following Event ID 304 error:

So it was failing due to a Keyset does not exist error. This seems to be related to the private keys used by Windows and while there’s a lot of Google hits I finally found the blog post I referenced at the top of this post and there it said this error could be to do with TPM (see that post for fixes) or because of cloning. Since the latter was my issue, the fix was the delete C:\ProgramData\Microsoft\Crypto\Keys and try registration again. I deleted the folder.

Next I wanted to try a manual join. You can’t really do that as the dsregcmd /join command requires to be run under the SYSTEM account when an Azure AD synced account logs in (you could workaround using something like psexec -i -s cmd.exe to launch a command prompt under the SYSTEM account and then do dsregcmd /join). An easier way to handle this though is to use the Scheduled Task created by Windows that automatically attempts a Hybrid Join (under the SYSTEM account) when an Azure AD synced user logs in. To do this open Task Scheduler and go to Microsoft\Windows\Workplace Join, select the Automatic-Device-Join task and run it. Additionally kick a delta sync for Azure AD too (Start-ADSyncSyncCycle -PolicyType delta) and now if you login as an Azure AD joined user it will be Hybrid joined.

When a machine registers with Azure AD it has certificates added to its certificate store and also to the userCertificate attribute in AD. When you then do an Azure AD sync it looks to this attribute before syncing those objects to Azure AD and only syncs the ones that have a userCertificate. Hence what I did above of doing a join and then the delta sync.