Troubleshooting stories from the field are the best. That’s why I like writing them down. Although, sometimes they might appear as straight cases of schadenfreude, I feel there are lessons to be learned for anyone, if you’re willing to look closely and listen carefully.
This week I experienced an issue at a customer, when they raised their Active Directory domain functional level beyond Windows Server 2012 R2.
The customer has an Active Directory Domain Services environment that dates back to 2004. It has been upgraded in the past. Its domain controllers have recently been upgraded to Windows Server 2016 and Windows Server 2019.
The company uses fail-over cluster to offer scale-out file servers. These implementations are based on Windows Server 2016.
Admins have placed many users in the Protected Users security group to prevent cached logons and restrict token lifetimes.
They raised the domain functional level (DFL) to Windows Server 2016.
All the fail-over clusters became inaccessible when connecting to the cluster name and current remote desktop connections were terminated when connected to the cluster name:
However, connections to the individual hostnames of the cluster nodes were successful.
When implementing the Windows Server 2016 DFL, the domain controller protections for the Protected Users security group kicked in, as these are unlocked with the Windows Server 2012 R2 DFL. The domain controller protections include the inability to authenticate using NTLM, the inability to encrypt Kerberos pre-authentication with DES or RC4 and the inability to cache Windows digest passwords.
When connecting to the fail-over cluster name NTLM is used, instead of Kerberos. Fail-over clusters use NTLM, unless they run Windows Server 2019, and up.
The admins at this company removed people that need access to the fail-over clusters out of the Protected Users security group, while they're upgrading their fail-over clusters to Windows Server 2019..
Ten things you need to be aware of before using the Protected Users Group
New features in AD DS in Windows Server 2012 R2, Part 2: Protected Users
From the Field: The case of the unreachable forest on a domain-joined Azure AD Connect installation
From the Field: The case of the randomly rebooting Domain Controllers
From the field: The Case of the Unstable AD FS Farm