Hello everyone! Tim Beasley – Platforms PFE coming at you live from the funky fresh jam known as LAS VEGAS! That’s right people! I’m having a blast by the pool at the MGM Grand and loving life!! …writing a blog post for Microsoft. At Vegas. In the sun poolside…writing…a…technical blog post…what’s wrong with me?!
Okay not really. Once again I’m here in Missouri, where it’s cold in the Spring. I’m just wishing I was in Vegas at the moment. Aren’t we all???
Before I go too far off the deep end, let me zip back into focus here and discuss the topic at hand. The other day I was approached with:
“Hey Timmeh, I followed your awesome blog post about ensuring my RDP connections were configured to use a certificate from my internal PKI (found here). I believe everything’s working but I’m just not sure. When I connect to a remote machine on my network/domain, the connection always shows that I’m connected via Kerberos…NOT the certificate. No matter what I try I can’t seem to prove the certificate’s actually being used.”
Anyone ever come across this one before? If so, I have the answer! If not, I still have the answer! Muah ha ha ha! (Quick shout out to Sergey Kuzin – authentication expert in Product Group, who assisted me with tracking all this down.)
Let me enlighten you people on what it is I’m referring to that’s causing said confusion:
- Step 1. On a client joined to your domain, simply launch the Remote Desktop Connection Client (mstsc.exe) and establish any connection to a machine on the domain.
- Step 2. Click the little LOCK icon.
- Step 3. Read what the notification says.
Kerberos?!?
“But Tim, I followed your instructions in your last blog post and I know for a fact that the proper certificate is installed, and the terminal services are set to use the right thumbprint, etc.!!! You know what I think!? I think this is garbage, and Microsoft is full of it…blah blah blah!”
Take a breath (wooo saaahhhh) and relax. I promise it’s not what you think.
Remember that RDP encryption was used by default (Ahhh, but is it?). You’ll find lots of online documentation saying as much. One example is here: https://technet.microsoft.com/en-us/library/ff458357.aspx. Back in the day sure (2003 and older)…but to my surprise, I recently found out that RDP encryption is NO LONGER THE DEFAULT. It can be used, but it must be enabled at the client side. Say what?! (Yeah now I’ll have to add an update my previous blog post…) Not to mention now a few of the TechNet docs are a bit outdated…(hey it happens, stuff doesn’t last forever).
“So…. what’s the default encryption method now?”
TLS encryption! Hurray! In a nutshell, if a certificate from a PKI doesn’t exist on the machine to use for RDP sessions, then the machine will generate a self-signed certificate, and RDP will use that instead to guarantee TLS is always used.
And we can prove it. Just look at my network capture from an RDP session I did in my labs (after I set everything up to use a proper certificate…not the self-signed one).
See the TLS exchanges occurring when the session is established? Feel free to try it yourself in your own environment.
Now, let’s go re-visit that little LOCK icon from before. I guarantee you it’s working as intended, and the result is as expected. I know it’s confusing on the surface. However, once you understand that it’s related to the AUTHENTICATION method used to establish the session, then it makes more sense. That’s right, authentication. It’s how the session was authenticated to the session host! Not
whether the traffic is encrypted, and how it’s encrypted.
What happens if you follow my advice from my other blog and establish RDP sessions using FQDN and proper certificates? You get this:
Note the difference. Now you will see that the identity was verified by both a certificate AND Kerberos.
To sum up, it’s always best to first ensure proper certificates are used, and then…connect using FQDN instead of short names or IP addresses. Thanks for reading! And now it’s back to wishing I was actually in Vegas…
Tim Beasley – Platforms PFE