IMPORTANT ANNOUNCEMENT FOR OUR READERS!
AskPFEPlat is in the process of a transformation to the new Core Infrastructure and Security TechCommunity, and will be moving by the end of March 2019 to our new home at https://aka.ms/CISTechComm (hosted at https://techcommunity.microsoft.com). Please bear with us while we are still under construction!
We will continue bringing you the same great content, from the same great contributors, on our new platform. Until then, you can access our new content on either https://aka.ms/askpfeplat as you do today, or at our new site https://aka.ms/CISTechComm. Please feel free to update your bookmarks accordingly!
Why are we doing this? Simple really; we are looking to expand our team internally in order to provide you even more great content, as well as take on a more proactive role in the future with our readers (more to come on that later)! Since our team encompasses many more roles than Premier Field Engineers these days, we felt it was also time we reflected that initial expansion.
If you have never visited the TechCommunity site, it can be found at https://techcommunity.microsoft.com. On the TechCommunity site, you will find numerous technical communities across many topics, which include discussion areas, along with blog content.
NOTE: In addition to the AskPFEPlat-to-Core Infrastructure and Security transformation, Premier Field Engineers from all technology areas will be working together to expand the TechCommunity site even further, joining together in the technology agnostic Premier Field Engineering TechCommunity (along with Core Infrastructure and Security), which can be found at https://aka.ms/PFETechComm!
As always, thank you for continuing to read the Core Infrastructure and Security (AskPFEPlat) blog, and we look forward to providing you more great content well into the future!
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.
“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