- Remote Desktop An Authentication Error
- Remote Desktop Authentication Error 0x80004005
- Authentication Error Has Occurred Remote Desktop Installer
- Authentication Error Has Occurred Remote Desktop Operating System
An authentication error has occurred (Code: 0x607)
Remote Computer: RDSHost.domain.local
A 0x607 error is caused by using an invalid security certificate for authentication. Certificate validation is picky, for good reason. While the error points to a failed certificate, it doesn't share any information about which certificate failed or how it failed. I recently had a good bit of trouble weeding out the cause in new 2016 RDS build. I hope this saves someone a little trouble.
Fix: An Authentication Error Has Occurred (Code: 0x80004005) – Remote Desktop Create a new saved Remote Desktop File. Click Show Options in the bottom left corner of the remote desktop window. Save the Default.rdp file to your Desktop. Now, open the Default.rdp file in Notepad. I think the cause of the problem related to my having switched session hosts to different session collections and somehow the certs don't update properly. Removing the session host from the collection and then remove the cert from the computer personal & remote desktop stores, restart and the certs are recreated and problem resolved. An authentication error has occurred. The function requested is not supported. Remote computer: This could be due to CredSSP encryption oracle remediation. For more information, see https:/go.microsoft.com/fwlink/?linkid=866660.
The Environment
It's important to note that the domain had been around since 2000 (windows version, not build year) and it has hosted an RDP server since the beginning. When I first came on the scene there was a bare-metal 2008 server that was really having a tough time. I had replaced the previous server with a 2012 R2 deployment using a two server setup, both virtual machines. One server was setup as the gateway and the rest of the roles were on the other server. Pretty basic.
Fast forward to 2018. My 2012 R2 RDS deployment that was starting to struggle. My repair attempts had not been successful. Most of the issues only affected the management aspects, which I was able to work around, so I ignored the problems as long as I could. When it developed some performance problems that were affecting users negatively, I decided something had to be done. The fix for this new problem was a reboot. That is simple enough for a single workstations, but it becomes a big problem when it's all of your users that get booted.
It didn't help that it was unpredictable. A simple nightly reboot wasn't enough. The problem could occur 1 hour or 1 day after the last reboot. After fighting with it for some time, I gave up on fixing it and moved toward building a clean deployment using the newest server edition. The old 'time is money' philosophy.
Remote Desktop An Authentication Error
The New 2016 Environment
Along with the new version, I had a few other improvements to incorporate as well. Microsoft office for mac %e7%a0%b4%e8%a7%a3%e7%89%88. My intention was to add two more servers to the mix. The two extra servers would be session hosts. A few years of experience on our previous broker/host setup convinced me that separating the broker from the host makes more sense. Furthermore, 2 smaller hosts seemed less problematic from a user interruption perspective. With multiple hosts, I can service one host or even the broker, in limited capacity, without shutting out users during low traffic times.
The install process was pretty straight forward in 2016. Everything went according to plan with the install and deployment. Testing went great.
Then the Problems Started
Unfortunately, as soon as they started logging in from outside of the building, we started seeing the 0x607 error. At first, only one server had the issue, so I was able to by-pass the problem by disabling one of the hosts. Then, it started on the other, but not every time. With a little tracking I found that most of the time one 1-2 users were blocked each day. In most cases, temporarily disabling the server that any given user was having trouble with allowed them to connect to the other server. The intermittent occurrence drove me crazy.
Remote Desktop Authentication Error 0x80004005
This was a certificate error, so I went through the certificates and could not find any problems. There were only two certs involved. Both using the FQDN of our server, but they were issued by 2 different CA's. The first was the self-signed cert generated by the deployment, located in the 'Remote Desktop' folder of the certificate store. The second was the automatically generated cert from the domain CA, located in the 'Personal' certificate store.
Just a Bit on RDS Deployments Since 2012
Microsoft made some pretty significant changes to the RDS environment with the 2012 release of Windows server. Previously, we had to configure every server role independently. The new approach is significantly faster and simplified for most deployments. Rather than individually configuring each server, you setup your deployment on a single machine through a wizard that pushes out the setup to the individual servers. The common settings are all relatively easy to find from server manager. More complicated or customized deployments will need to use PowerShell commands. My setup was very much a common setup.
About the Certs
Out of the box, the system is designed to use a third party SSL certificate to secure the user's connection to the gateway server. Once through that layer, a domain CA cert is used to secure the connection to the broker. The broker then facilitates the connection to the session host using the host's self-signed certificate. This is, of course, a over-simplification of the process, but diving into the multiple layers of security involved is outside of the scope of this problem.
The Foul Up
It took a lot of digging to find my problem and even more to find the cause. Remember, this is a clean install and, at first glance, there were no problems. My first impulse was to check the clients. This was a domain CA cert that was giving my grief, so I had thought it might be a client side issue. It was not.
I eventually found that the session hosts were using the cert from the domain CA instead of the built-in self-signed cert. You might be thinking, 'Well that should work', and it would if my broker is configure to use the domain cert. As it was, my broker (and therefore the clients) was expecting the self-signed cert and my hosts were proffering the other.
Proving my theory
The cert used by RDS is visible in both WMI and the Registry. I used PowerShell to pull the WMI class. Get-CimInstance -class Win32_TSGeneralSettings -Namespace rootcimv2terminalservices, does the trick nicely. There are only two properties important to this problem, SSLCertificateSHA1Hash and SSLCertificateSHA1HashType. The first gives us the thumbprint of the certificate.
If you really need to know which cert this is specifying, you can use something like $TP = (Get-CimInstance -class Win32_TSGeneralSettings -Namespace rootcimv2terminalservices).SSLCertificateSHA1Hash; Get-ChildItem cert:LocalMachine** | ?{ $_.Thumbprint -match $TP} to figure it out, but I found my answer from SSLCertificateSHA1HashType. The default value is 1, but I had a 2 in that property. That told me two important details. The first, is that I am not using the self-signed cert, the second is that the cert I am using is dictated by Group Policy.
Let the Hunt Begin
I immediately opened gpedit to find this rouge setting in my RDP Servers GPO. It wasn't there. I actually dug around for a while before I thought about using group policy results 😳 . Sure enough, buried down in one of our default server policies was a setting in 'Computer ConfigurationPoliciesAdministrative TemplatesWindows ComponentsRemote Desktop ServicesRemote Desktop Session HostSecurity' called 'Server Authentication Certificate Template' that was instructing all of our servers to use the Domain CA certs that were automatically being issued for authentication.
The Fix
I'm sure this setting was configured well before we started using an 2012 RDS. It might have even dated back to the first RDP server install or perhaps it was part of an administrative RDP setup. Regardless, it was certainly the cause of my problem. As soon as I disabled that policy for our RDP server policy object and updated the hosts with gpupdate, those WMI values reverted back to defaults and everything worked perfectly.
The install process was pretty straight forward in 2016. Everything went according to plan with the install and deployment. Testing went great.
Then the Problems Started
Unfortunately, as soon as they started logging in from outside of the building, we started seeing the 0x607 error. At first, only one server had the issue, so I was able to by-pass the problem by disabling one of the hosts. Then, it started on the other, but not every time. With a little tracking I found that most of the time one 1-2 users were blocked each day. In most cases, temporarily disabling the server that any given user was having trouble with allowed them to connect to the other server. The intermittent occurrence drove me crazy.
Remote Desktop Authentication Error 0x80004005
This was a certificate error, so I went through the certificates and could not find any problems. There were only two certs involved. Both using the FQDN of our server, but they were issued by 2 different CA's. The first was the self-signed cert generated by the deployment, located in the 'Remote Desktop' folder of the certificate store. The second was the automatically generated cert from the domain CA, located in the 'Personal' certificate store.
Just a Bit on RDS Deployments Since 2012
Microsoft made some pretty significant changes to the RDS environment with the 2012 release of Windows server. Previously, we had to configure every server role independently. The new approach is significantly faster and simplified for most deployments. Rather than individually configuring each server, you setup your deployment on a single machine through a wizard that pushes out the setup to the individual servers. The common settings are all relatively easy to find from server manager. More complicated or customized deployments will need to use PowerShell commands. My setup was very much a common setup.
About the Certs
Out of the box, the system is designed to use a third party SSL certificate to secure the user's connection to the gateway server. Once through that layer, a domain CA cert is used to secure the connection to the broker. The broker then facilitates the connection to the session host using the host's self-signed certificate. This is, of course, a over-simplification of the process, but diving into the multiple layers of security involved is outside of the scope of this problem.
The Foul Up
It took a lot of digging to find my problem and even more to find the cause. Remember, this is a clean install and, at first glance, there were no problems. My first impulse was to check the clients. This was a domain CA cert that was giving my grief, so I had thought it might be a client side issue. It was not.
I eventually found that the session hosts were using the cert from the domain CA instead of the built-in self-signed cert. You might be thinking, 'Well that should work', and it would if my broker is configure to use the domain cert. As it was, my broker (and therefore the clients) was expecting the self-signed cert and my hosts were proffering the other.
Proving my theory
The cert used by RDS is visible in both WMI and the Registry. I used PowerShell to pull the WMI class. Get-CimInstance -class Win32_TSGeneralSettings -Namespace rootcimv2terminalservices, does the trick nicely. There are only two properties important to this problem, SSLCertificateSHA1Hash and SSLCertificateSHA1HashType. The first gives us the thumbprint of the certificate.
If you really need to know which cert this is specifying, you can use something like $TP = (Get-CimInstance -class Win32_TSGeneralSettings -Namespace rootcimv2terminalservices).SSLCertificateSHA1Hash; Get-ChildItem cert:LocalMachine** | ?{ $_.Thumbprint -match $TP} to figure it out, but I found my answer from SSLCertificateSHA1HashType. The default value is 1, but I had a 2 in that property. That told me two important details. The first, is that I am not using the self-signed cert, the second is that the cert I am using is dictated by Group Policy.
Let the Hunt Begin
I immediately opened gpedit to find this rouge setting in my RDP Servers GPO. It wasn't there. I actually dug around for a while before I thought about using group policy results 😳 . Sure enough, buried down in one of our default server policies was a setting in 'Computer ConfigurationPoliciesAdministrative TemplatesWindows ComponentsRemote Desktop ServicesRemote Desktop Session HostSecurity' called 'Server Authentication Certificate Template' that was instructing all of our servers to use the Domain CA certs that were automatically being issued for authentication.
The Fix
I'm sure this setting was configured well before we started using an 2012 RDS. It might have even dated back to the first RDP server install or perhaps it was part of an administrative RDP setup. Regardless, it was certainly the cause of my problem. As soon as I disabled that policy for our RDP server policy object and updated the hosts with gpupdate, those WMI values reverted back to defaults and everything worked perfectly.
The Loose Ends
I never did determine why this worked intermittently outside of the office or why the clients didn't mind the cert mismatch when they were locally connected. I'm assuming the latter question had something to do with using the local authentication to handle the encryption layer, but I would have thought this problem would have affected them either way. The intermittent successes still don't make any sense. With plenty of other issues on my agenda and this issue fixed, I moved on to ponder those questions on another day.
Authentication Error Has Occurred Remote Desktop Installer
In Conclusion
Authentication Error Has Occurred Remote Desktop Operating System
I hope this saves someone the frustration I went through. It's never any fun when you catch up with problems created in the past. Good Night and God Bless!
