An interesting issue that was discovered after deploying security certificates for Remote Desktop Authentication into the TPM of desktop computers and some (physical) servers, after go live with the security certificate clients could no longer connect with the error below being displayed in the Remote Desktop Services log on the server.
The server security layer detected an error (0x80090304) in the protocol stream and the client (Client IP: <IP ADDRESS>) has been disconnected.
After chasing many red herrings around cryptography, schannel implementation, and the likes the root cause seems to be an issue with the storage within the TPM itself – as a workaround the certificate can be stored in the ‘traditional manner’ instead. An ideal fix would probably involve a firmware upgrade on the TPM.
In configuring the Microsoft Intune Certificate Connector and attempting to issue certificates to your client via Intune you might run into the error message below.
IssuePfx – COMException: System.Runtime.InteropServices.COMException (0x80094800): The requested certificate template is not supported by this CA. (Exception from HRESULT: 0x80094800)at CERTENROLLLib.IX509CertificateRequestPkcs10V2.InitializeFromTemplateName (X509CertificateEnrollmentContext Context, String strTemplateName)
at Microsoft.Management.Services.NdesConnector.MicrosoftCA.GetCertificate (PfxRequestDataStorage pfxRequestData, String& certificate, String& password)
Failed to issue Pfx certificate for Device ID 24c2445e-6cd2-4629-a942-081bdaca9b12 :
In short when configuring the certificate name to be used you’ve probably entered the ‘Template display name’ instead of the ‘Template name’ – note the difference in the screenshot where the template name doesn’t include any spaces.
Given the complexity of this feature I’ve found the guide at this link really handy in setting it up in the past:
Following on from more work with OpenVAS and after resolving issues around PHP/MySQL the next largest priority was flagged as issues with the Remote Desktop Server (this applies if the server is being used as a Session Host or is just running Windows Server/Client). Here are two pointers in the right direction to get these port 3389 issues resolved!
SSL/TLS: Report Weak Cipher Suites and SSL/TLS: Diffie-Hellman Key Exchange Insufficient DH Group Strength Vulnerability
To resolve this issue I would suggest you look at the free IISCrypto tool (https://www.nartac.com/Products/IISCrypto) which (after a reboot) disables weak cipher suites and ensures that the correct key exchange mechanisms are used on your servers and clients. Note this software doesn’t just apply to IIS (Internet Information Services) but also Remote Desktop and any other Microsoft technology that makes use of schannel.
Although it takes a little while longer you can also examine the registry (see https://www.nartac.com/Support/IISCrypto/FAQ) and deploy a Group Policy to apply the same settings to your machines.
If you can I would suggest you opt for the PCI 3.1 template (which also culls TLS1.0 support) however as I found out you may have to resort to the ‘Best Practices’ which keeps TLS1.0 enabled and in turn allows things like 802.1x EAPOL and older versions of Microsoft SQL Server to work. Really is worth doing extensive testing with all of your applications (network services included!) before you go and roll this tool out to your full environment!
SSL/TLS: Certificate Signed Using A Weak Signature Algorithm
In this case we are looking at the self signed Remote Desktop Protocol certificate which just so happens to be SHA1. To resolve this issue have a look at this blog post – https://www.darkoperator.com/blog/2015/3/26/rdp-tls-certificate-deployment-using-gpo which covers in great detail how to use an Active Directory Certificate Services Server to issue SHA256 certificates to your machines to use with Remote Desktop.
A interesting quirk of an issue with this one; when generating a CSR to secure the iDRAC (version 8) interface on a Dell T430 server it appears that you can’t use an apostrophe in any of the fields else you are presented with a empty/blank csr.txt file (see right).
The work around is simple if a little annoying (especially when CSRs generated with other tools allow apostrophes) in that you remove the apostrophe from all of fields in the request. I’d imagine this is the same for other special characters as well.