Sometimes the issue is the dumbest thing

TL;DR I recently ran into an issue in the hybrid AD lab that was difficult to diagnose but easy to fix. It is RE logging into AAD as the Global Admin from ‘on prem’, TLS 1.2 & error code AADSTS1002016. Posting it here in case it helps anyone else.

Welcome to Part VI of our Back to the Basics Series!

Part I: NTDS.dit vs SAM

Part II: Ownership Matters

Part III: Recovering from a Crash

Part IV: Setting up a Simple Honeypot Account

Part V: Automating DC Deployment

Part VI: Sometimes it’s the dumbest thing

Part VII: Merry Christmas, macros, & Base64

Part VIII: Why old 0 Days make great teaching tools

Part IX: PowerShell & PS1s without PowerShell.exe

Part X: Ownership & so called “effective permissions”

Part XI: Windows Event Forwarding & SACLs

Part XII: Poorly planned honeypots & other Bad Ideas

Part XIII: Setting up a simple honey token

Part XIV: Smartcards and Pass-the-Hash

Part XV: Forwarding logs to Sentinel & basic alerts

Part XVI: Automating VM deployments in Hyper-V

Part XVII: Migrating the lab from ESXi to Hyper-V

Part XVIII: Centrally managing Hyper-V & Live Migrations

Background

I have run into a couple gremlins in the homelab since moving it from just AD to Hybrid AD. To Microsoft’s and AAD’s credit, all these issues so far have been caused by misconfigurations in my ‘on prem’ environment specific to AD.

This howto is about diagnosing and solving one of those, namely error code AADSTS1002016. It turned out to be a simple fix, but I did not see it all over Google so I figured I’d post my notes in case it helps anyone else.

The issue

Microsoft AAD recently began mandating TLS 1.2 or 1.3 in order to login to AAD as a Global Admin. I had been using my laptop to access AAD via PowerShell and screw around, so I did not initially notice anything amiss. My laptop is not on test.local.

However I eventually went to tweak a configuration in Azure AD Connect and saw the below:

I attempted to access AAD via PowerShell from a VM in test.local and got the same error.

My standalone laptop is still accessing AAD just fine though. What gives?

Barking up the wrong tree

I initially assumed the issue was the version of TLS that .NET was using. Googling the error code “AADSTS1002016” did not disabuse me of this notion. You can see what TLS version PowerShell is using via

[Net.ServicePointManager]::SecurityProtocol

The odd thing is that PowerShell on my desktop and laptop are showing the same TLS versions as the VMs in the lab domain. The desktop and laptop could login fine.

Regardless, just to make sure I pushed registry keys to the lab VMs. If at nothing else it was good training. I Googled up the relevant keys and pushed the below via a startup *.ps1 in Group Policy:

Set-GPPrefRegistryValue -Name "Mishky's TLS 1.2" -Context Computer -Key "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" -ValueName "Enabled" -Value "1" -Type REG_DWORD -Action Update

#Create these
Set-GPPrefRegistryValue -Name "Mishky's TLS 1.2" -Context Computer -Key "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" -ValueName "DisableByDefault" -Value "0" -Type REG_DWORD -Action Create

Set-GPPrefRegistryValue -Name "Mishky's TLS 1.2" -Context Computer -Key "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" -ValueName "Enabled" -Value "1" -Type REG_DWORD -Action Create

Set-GPPrefRegistryValue -Name "Mishky's TLS 1.2" -Context Computer -Key "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" -ValueName "DisableByDefault" -Value "0" -Type REG_DWORD -Action Create

Set-GPPrefRegistryValue -Name "Mishky's TLS 1.2" -Context Computer -Key "HKLM\SYSTEM\CurrentControlSet\services\HTTP\Parameters" -ValueName "EnableHttp3" -Value "1" -Type REG_DWORD -Action Create

If you are only setting a registry key on one system you can also simply copy/paste and save to a *.reg file. To set the last key listed above for example use:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\HTTP\Parameters]"EnableHttp3"=dword:00000001

However none of this helped.

The root cause

After awhile it dawned on me that the issue was actually an old suspect.

That’s right; Internet Exploder. For reasons unknown it had taken it upon itself to default to SSL 3.0 only. The login box that pops up when you execute ‘Connect-AzureAD’ is from IE, causing the issue. Ironic that a trainwreck of a browser from the days when Microsoft had a well deserved reputation [and not a good one] was the root cause of an issue regarding AAD.

Nonetheless once I realized what the root cause was it was easy to fix. I felt pretty dumb for not grasping it sooner, but it was easy to fix. I swear sometimes it’s the dumbest thing.

The fix

Simply push a GPO under

Computer Configuration\Administrative Templates\Windows Components\Internet Explorer\Internet Explorer Control Panel\Advanced Page\

Enable ‘Turn Off Encryption Support’, as counterintuitive as that sounds, and set the options accordingly in the drop down box. I hit the easy button and just picked ‘Only use TLS 1.2’.

Once the lab’s VMs updated Group Policy all was well.

Installing Azure AD Cloud Sync

Once that was resolved I finally got around to enabling Azure AD Cloud Sync. AAD supports running it alongside Azure AD Connect, so I figured why not. Simply install the agent on an ‘on prem’ system and then configure the sync options from AAD.

Just like Azure AD Connect, Cloud Sync has an option to only sync selected OUs.

I will have to poke around later and see if an attacker can dump creds from the system running the Cloud Sync agent, and if so what privilege is required. We covered setting up a hybrid AD lab here and dumping creds from the Azure AD Connect server here.

Summary

IMHO stuff like this is the reason to have a home lab in the first place. Make your mistakes, dive headfirst down the wrong rabbit hole, and learn your lessons in an environment without any users impatiently asking when it’ll work again. Obviously it is also great for learning common attacks and mitigations, all while winging it. Change requests, meetings, etc are not required.

The eventual goal is to move away from needing ‘on prem’ in the lab at all. Eventually we will spring for a license or two for M365 and Intune so we can screw around with syncing Exchange, SSO to everything, managing client workstation VMs without Group Policy, etc.

Ironically the issues we have encountered so far, like this one, have been caused by the ‘on prem’ side of the house, not by AAD.

References

Set TLS manually in PowerShell: https://stackoverflow.com/questions/73132536/tls-version-issue-is-being-raised-while-connecting-to-azuread-using-the-azure-fu

Force IE to use TLS 1.2 via GPO: https://www.bauer-power.net/2014/06/how-to-enabled-tls-11-and-tls-12-in.html

Check/set TLS version in use: https://stackoverflow.com/questions/73132536/tls-version-issue-is-being-raised-while-connecting-to-azuread-using-the-azure-fu

Add DNS forwarder: https://www.server-world.info/en/note?os=Windows_Server_2019&p=dns&f=10

Azure AD Cloud Sync setup: https://learn.microsoft.com/en-us/azure/active-directory/cloud-sync/tutorial-pilot-aadc-aadccp

Set keys using reg files: https://www.lifewire.com/how-to-create-edit-and-use-reg-files-2622817