Earlier this morning, I was working with our support team to work out an issue they were having in an environment where Remote Desktop Services had stopped working. Trying to connect to a server via RDS simply failed with a Network Level Authentication warning, strange, given it was a domain environment and everything should be […]
Earlier this morning, I was working with our support team to work out an issue they were having in an environment where Remote Desktop Services had stopped working. Trying to connect to a server via RDS simply failed with a Network Level Authentication warning, strange, given it was a domain environment and everything should be trusted and all good. The issue started life as support seeing Event ID 1058 and Event ID 36870 errors in the event log and they had been looking at https://blogs.technet.microsoft.com/askperf/2014/10/22/rdp-fails-with-event-id-1058-event-36870-with-remote-desktop-session-host-certificate-ssl-communication/ for guidance to this point with no success.
I quickly discovered that a GPO had recently been implemented that enforced NLA for RDS and also assigned a certificate template to use for Remote Desktop instead of the default self-signed version. I hopped onto the certificate authority to check out the certificate template that had been configured and compared it to the recommendations of the Microsoft article for assigning certificates to RDS sessions at https://blogs.technet.microsoft.com/enterprisemobility/2010/04/09/configuring-remote-desktop-certificates/ as this is an article I have referred to before and know it works.
Whilst looking through, I noticed what I wondered may be the issue but it required a little testing first. In the Microsoft article, they state to create a custom Application Policy for Remote Desktop Authentication with an OID of “1.3.6.1.4.1.311.54.1.2”. In the template in question, the OID was correct but the name was not, the name used was different as shown by the image above. We tested this and it indeed looks like Remote Desktop Services does not read the OID but instead, reads the Application Policy name. For this reason, the RDS service was requesting the certificate based on the template specified in the GPO but after doing so, realised it wasn’t fit for purpose. Instead of falling back to using the self-signed certificate, it simply put the RDS service into a failed state. It had left the certificate assigned to the service set but because the certificate was invalid and the GPO also specified that NLA was enforced, the network authentication failed because of the certificate being unfit for purpose and therefore bombed out attempts to use Remote Desktop. Had NLA not been enforced, I would have made it onto the server and found the issue another way.
The fix I assumed would be simply to create a new template, create a new OID that matched the name and OID string correctly and update the GPO but all was not to be. The first issue came that the OID has to be unique within the PKI. Trying to create a new custom Application Policy called Remote Desktop Authentication failed because the OID was already in use. Never mind, we’ll just update the existing template, delete the Application Policy and re-create it from scratch but that was not to be either.
Because an Application Policy can be re-used across multiple templates, they are stored in Active Directory. Once an Application Policy is created, it is added to the list to be later re-used but there is no delete option so once an OID is added, it’s there for good. As the screenshot above shows, even after deleting the Application Policy from the template, it remained in the list to select. After a short amount of looking in Active Directory Sites and Services (you could just as equally use ADSI Edit), I found that under the Public Key Services node, there is a Container named OID and sure enough in this container, there is a sub-container for each Application Policy and OID that is created. I deleted the Application Policy and the OID from AD and restarted the CA service to allow it to refresh the data from Active Directory. For reference, here’s what AD Sites and Services looks like when you enable the Services view from the toolbar and navigate down to the OID container.
Once the CA saw that the Application Policy and OID was deleted, I was able to create a new Application Policy using the correct name, create a new certificate template and assign the template to be issued by the certificate authority. Once that was done, the GPO was updated to reflect the new template name and a test client had gpupdate executed to update the RDS service and in turn, request a new certificate based on the new template name. With the RDS service, the changes are not applied until either a system restart or the RDS service is restarted. A quick RDS service restart later and we could now connect to the machine without issues.
In this instance, I could have just as easily deleted the Application Policy and OID from AD Sites and Services and re-created it using the existing template name without the update to the existing GPO however in the interests of ensuring everything was working from a known good, clean slate, it was worth the extra two minutes effort.
The moral of this story is not to give the Application Policy a custom name when following vendor instructions on creating certificate templates. Whilst in this instance, we were only working with Remote Desktop Services, this same message could be true for other services that depend on a PKI certificate to function. If a vendor has a document which outlines the steps to follow for creating a custom certificate template, it’s best just to follow it as-is.