Update 15-09-2021
This morning I received news that the documentation has been updated. The documented PowerShell script that caused the problem has been removed and references given to the the Azure AD Connect tools Get-ADSyncToolsTls12 and Set-ADSyncToolsTLS12. These tools have also been fixed. The Registry key is no longer replaced if it already exists.
The Azure AD Connect installation Wizard is fixed and a new build should be released tomorrow.
As always it's great to work with the Azure AD team and thanks to Tee Earl, Rob de Jong, et al, all is as it should be.
Just the other day, I got a call from a client, and the conversation went like this.
"We have just installed Azure AD Connect on a 2019 Server, and it's broken a secure management website we run on that server."
"How do you mean broken?"
"The website doesn't load, and we are getting weird .NET messages."
I love challenges, so I immediately offered to take a look. I have a troubleshooting philosophy where I like to gather as much information as possible before looking at the problem. Armed with prior knowledge, I reflect on what could have caused the issue before picking up my toolkit.
Information gathering
The client had started the install of Azure AD Connect and was blocked by the following message about the incorrect version of TLS:
They thought the error message was strange as TLS should be enabled by default on Server 2019. However, they were stuck and so looked at the documentation. The documentation provided details of registry keys to be set and provided a PowerShell script. As noted above, as of 15/9/2021 this documented script has been removed.
After running the script, they completed the install and checked synchronization etc. All Looked OK until an attempt was made to access the management website.
Access to the portal failed with the following error message:
The 'targetFramework' attribute in the <compilation> element of the Web.config file is used only to target version 4.0 and later of the .NET Framework (for example, '<compilation targetFramework="4.0">'). The 'targetFramework' attribute currently references a version that is later than the installed version of the .NET Framework. Specify a valid target version of the .NET Framework, or install the required version of the .NET Framework.
Troubleshooting
Having been involved in many Azure AD Connect installs with no side effects, the starting point for the troubleshooting was easy. I examined the PowerShell script and noticed that it was creating new Registry Keys and then setting values. For example:
New-Item 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319' -Force | Out-Null
New-ItemProperty -path 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319' -name 'SystemDefaultTlsVersions' -value '1' -PropertyType 'DWord' -Force | Out-Null
New-ItemProperty -path 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319' -name 'SchUseStrongCrypto' -value '1' -PropertyType 'DWord' -Force | Out-Null
The problem with this approach is that any pre-existing data held under that key is lost. I wanted to understand what values a clean install for Server 2019 has in the Registry for the keys that were replaced by the PowerShell script. To get a squeaky clean Server 2019 install, I fired up a new 2019 VM and checked the Register.
The PowerShell script replaced three keys:
'HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319'
'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319'
'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server'
'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client'
The last two keys did not exist on the server, but the first two keys did and were pre-populated with Keys and values. As shown:
As already explained, the script cleared the contents of the \.NETFramework\v4.0.30319 keys. Hence the error message "The 'targetFramework' attribute currently references a version that is later than the installed version of the .NET Framework."
I installed IIS on the new server to check that the installation process didn't make any other Registry changes to the pertinent keys. Luckily there were no additional changes. I created a Registry script to add the deleted data to the Azure AD Connect server, and the web portal sprang back into life. The client was pleased, so was I!
Further testing
There are two new Azure AD connect tools, Get-ADSyncToolsTls12 and Set-ADSyncToolsTls12. I tested both of these, and they had the same results as the documented scripts.
Postmortem
After getting the portal running, I sat down with my customer to reflect on the scenario. The first thing we discussed was whether the changes and impact were deliberate. For years I have been telling my customers, from a security perspective, they should be treating a server running Azure AD Connect as though it is a Domain Controller. It should be classified as a T0 asset in the Microsoft enterprise access model. Bearing that in mind, should my client have been running a website on the equivalent of a DC? Their argument, and justifiable, is that the portal is for an internal management task and locked down. We both agreed that if Microsoft were deliberately locking down the server, there should have been a warning.
MVP power
As Microsoft MVP, I have exemplary access to the Microsoft product groups. Before I knew it, I was in contact with Tee Earl (https://www.linkedin.com/in/teeearls/) who is a Principal Program Manager on the Azure Identity team. The impact of running the script was not the intended behaviour, and they immediately started working on a fix based on a short report that I had emailed. Within days I was informed that a fix would be in the next Azure AD Connect build, and in the interim, they would update the documentation.
Mistakes happen
Yes, mistakes happen. However, if you look at the complexity of shipping new and updated components across many disparate environments, it is impressive how seamless most changes are. I know the Identity team’s goal is to make it “just work” for even complex scenarios so that customers don’t have to think about it. And they don’t want to fall short of creating that magic.
The Azure AD teams do a fantastic job – keep up the great work. I love the challenges and rewards of working with the product.
Wrap up
Thank you for reading this blog, and stay tuned for the next one. Please let your friends and colleagues know about the blog via LinkedIn and Twitter, don't forget to include me, so I see it! twitter: @john_craddock and/or www.linkedin.com/in/johnxts
My next identity masterclasses for CET and EST are in March 2022. Why don't you join me for an action-packed week?
Monday 7th - Friday 11th March 2022 9:00 - 17:00 CET
Monday 14th - Friday 18th March 2022 8:00 - 16:00 EST
Full details at https://learn.xtseminars.co.uk
Comments