While going through the Release Notes for the Windows Server Technical Preview and the Release Notes for Windows 10, I noticed something quite interesting:
If you join a computer with Trusted Platform Management (TPM) enabled to a domain in which there are no domain controllers running at least Windows Server 2012, computer authentication and those services running under Local, Network, or Virtual permissions will fail.
To correct this, on the computer you want to join to the domain, create a new registry key with DWORD value DevicePKInitEnabled under HKLM\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters. Set this key to 0 and then restart the computer.
So what’s going on here?
The situation
One of the new features in the next versions of Windows and Windows Server is support for device authentication using certificates. This feature requires connectivity to a Domain Controller in the device account domain which supports certificate authentication for computer accounts.
The DevicePKInitEnabled value in the registry allows you to set support for Kerberos to attempt authentication using the certificate for the device to the domain. By default, the device will attempt to authenticate using its certificate.
Since pre-Windows Server 2012 Domain Controllers do not support computer account authentication using certicates, authentication fails, NTSTATUS value 0xC00002F9 (STATUS_PKINIT_NAME_MISMATCH) will be logged, and you may receive an error reading The client certificate does not contain a valid UPN, or does not match the client name in the logon request. Please contact your administrator. when you start a Windows 10 Technical Preview or Windows Server Technical Preview-based virtual machine.
The solution
Using the registry
The solution, is to create a new registry key with DWORD value DevicePKInitEnabled under HKLM\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters. Set this key to 0 and then restart the computer.
Using a script
Meddling with the Windows registry can be time consuming, so alternatively you can run the following command from an elevated command prompt:
Reg add HKLM\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v DevicePKinitEnabled /t REG_DWORD /d 0
Using Group Policy
Alternatively, you can correct this behavior using Group Policy. Windows 10 Technical Preview or Windows Server Technical Preview both support a new Group Policy setting named Support device authentication using certificate under Computer Configuration, Administrative Templates, System, Kerberos to correct this behavior:
When this Group Policy setting is Not Configured, the device in scope for the Group Policy will attempt to authenticate using its certificate.
When you enable this Group Policy setting, Device authentication behavior using certificate: is set to Automatic, the aforementioned DWORD value DevicePKInitEnabled will be created (if not already present) in the Windows registry on devices running Windows 10 Technical Preview (and up) and Windows Server Technical Preview (and up) with a value of 1. When you change the value for Device authentication behavior using certificate: to Force, the DWORD value DevicePKInitEnabled will be created in the Windows registry (if not already present) on devices running Windows 10 Technical Preview (and up) and Windows Server Technical Preview (and up) with a value of 2.
When you disable this Group Policy setting, the DWORD value DevicePKInitEnabled will be created in the Windows registry (if not already present) on devices running Windows 10 Technical Preview (and up) and Windows Server Technical Preview (and up) with a value of 0, effectively achieving the same as you would achieve when you create the value yourself as mentioned as the workaround.
The other way around
Of course, you could also fix this issue by upgrading at least one Domain Controller to Windows Server 2012 in the Active Directory domain where the device account resides.
Here’s an elaborate Howto.
Concluding
Device Authentication using certificates is a welcome addition to Windows, but unfortunately not every environment is ready for it, today.
Related blogposts
Transitioning your Windows Server 2003 Domain Controllers to Windows Server 2012
Further reading
Release Notes: Important Issues in Windows Server Technical Preview
Release notes: Important issues in Windows 10 Technical Preview
2.3.1 NTSTATUS values
Microsoft Devices Security, Virtual Smart Cards Part 1: Introduction and TPM
A Trusted Ticket System for Kerberos
Next Release of Windows Server Hyper-V
That's quite important note I guess.
Just to confirm – to implement a workaround is it enough to have one 2012/2012R2 DC no matter what AD site is that DC located in? Or should it be the same site the new Windows server is introduced in?
It's enough to implement one Windows Server 2012, Windows Server 2012 R2 or Windows Server Technical Preview-based Domain Controller.
It does not matter in which Active Directory site the Domain Controller is located, when you're using automatic site links and bridging settings (default). Windows 10 Technical Preview-based devices will find SRV records for the newer Domain Controller(s) and use (only) them for authentication. In this scenario, the authentication traffic will flow over the sites Connections, though, with all consequences.
Placing Domain Controllers close to clients is a best practice. This might not come as a surprise, but I would like to mention that earlier I shared the scenario where Windows 8 clients would pile onto Windows Server 2012-based Domain Controllers (and up) when Kerberos Armoring (FAST) would be implemented.
Microsoft, currently, does not recommend using Windows 10 Technical Preview or Windows Server Technical Preview in production environments. It sounds like you have a pretty hefty testing environment on your hands there. 😉
Hi Sander,
thanks a lot for your post. After checking my Basic configuration (2 Hyper-V Host with TP and DC with TP as well) a Long time, i have found your post and it helped.
So it might not Help to install an DC with TP.
Thanks
Steven
There's one more reason;
If you had no 2012R2 (or above) Domain Controllers at the time of Azure AD Connect Setup and later you install Windows Server 2012 R2 or up on a Domain Controller, you have to run the "Refresh Schema" task from the Azure AD Connect wizard.
We were getting the exact same error, but this time the reason was different.