Why doesn't NLA work with cross-domain smart card authentication?
Well... actually it does. But you need a trust.
And by the way this will affect more than just smart card authentication to an RDP session, it will also affect copying files over UNC paths and basically anything else that requires authentication.
First though, let me back up a bit and talk about Network Level Authentication (NLA). This isn't technobabble, you really need to understand this to understand the problem.
OK. When you RDP to a server you chew up resources as the server remotely presents you with the graphical identification and authentication (GINA) screen. No matter who you are. This opens up a path to create a quick-and-dirty Denial of Service attack against a server by repeatedly sending thousands of these requests. If NLA is enabled, the source has to first "pre-authenticate" locally before a connection over RDP will even be allowed. So if you don't have the correct permissions, you can't launch such an attack. This topic is somewhat misunderstood in government circles because there are several Security Technical Implementation Guides (STIGS) referring to NLA as a protection against Man in the Middle (MitM) attacks. While there may be some merit to this, it was not what NLA was designed to accomplish. In addition, if you're going to require your users to authenticate with smart cards, this is irrelevant.
When you use smart card PKI certs for authentication, the exchange happens at the point where the card exists (better stated, the place where you enter your PIN to unlock the certificates on the card). The place where the private key exists. If you've ever launched remote desktop to a server and logged on with a smart card you've seen the GINA screen of the target server reading your smart card. This is because you've allowed your source computer to share the smart card (and its reader) with the target system so that the remote system can read the card as though it were physically present on that computer. In fact, it's so much an emulation that if you don't have the drivers for the reader or card on the remote system, it won't work. Proof that the card is literally "copied" (for lack of a better word) to the remote system. This persists as well past the GINA screen. Any time you need to authenticate, you'll see the password box followed by all the certificates present on the card as available to select. As you can see, this is very much different than how passwords work. (passwords can be forwarded on, certs with private keys can't).
But passwords work?!!? Chris, this must be a bug, right? Call the product team and have them fix it!!
Okay let's stop for a second (again) and cover a couple more important concepts. Right at this point we're talking about authentication, not authorization. What rights you have on that server (such as to log on via RDP) aren't in question yet, so put that aside for a second. All we're doing right now is validating that you are who you say you are. With a username/password that attestation is done by a trust that YOU are the only person who knows those two things. (And that is forwardable by hashing the password from anyone, to anyone.) With certificates, the attestation that you are who you say you are is based on the fact that you have the certificate in hand (and more specifically, in this case that you knew the PIN to unlock the smart card so you'd have a cert, meaning two factor). The certificate you have is issued by a trusted source (trusted by the target server). Just like when I get pulled over for speeding, the officer looks at my drivers license. He trusts the DMV as an issuer and if they validated that I'm Chris Davis, that's good enough for him. He only trusts me when I say I'm Chris Davis because he trusts them.
Because NLA is basically "authenticate before you authenticate" and since you're using a non-forwardable certificate for the authentication, the source (your workstation for instance) is the place where the certificate is. That's where you select the cert from the NLA prompt. If your workstation is part of the same domain (or has a trust to the same domain) as the target server, your workstation already knows that the target server trusts whoever it is that issued you that certificate. In this case however, the workstation has absolutely no knowledge of what the target server's trust store looks like and (for good reason) has no way to determine if the user's certificate is trusted or not.
There is no difference really in NLA and trying to open a UNC path (\\servername.domain.name\sharename) using a smart card for authentication. If the workstation isn't on the same domain or at least can talk to that domain via a trust, it simply does not work. This isn't a bug. This is how certificate authentication works. The workstation only knows that *IT* trusts that certificate.
There are other reasons not to use NLA as well in non-trusted scenarios like this (source/target computers are not part of a domain or a trust). Even if you're using passwords, there are issues. For instance, there is no way to easily change your password once it has expired. When you open the RDP connection and are presented with the NLA prompt, if your password is expired you simply cannot change it via the NLA prompt.
So why not build a trust or just have all your machines on the same domain?
Because it's a bad idea. Your workstation has access to the internet right? (And please God tell me your servers don't.) That means nasties like keyloggers. Viruses. Trojans. Cannibalism. Mass hysteria. Dogs and cats living together. Basically the worst parts of the bible. The domain where your workstations (and users) are shouldn't be the same domain where your enterprise workloads live. Shouldn't be the same network segment either. Period. Everybody accuses my security posture of being tinfoil-on-the-head... that is, until they become Ebay, JP Morgan Chase, Target, Adobe, Sony, The Home Depot, etc. Folks who haven't been hacked (or don't know they've been hacked) are like teenagers and cars. "Bad stuff won't happen to me, that's somebody else!"
So why use smart cards at all if you have to turn off security features like NLA?
Well, first off. You don't have to turn it off. But I'll get to that in a moment. Second, because the security enhancements you get with two factor auth like a smart card FAR outweigh the protection you get from NLA.
So what do we do? I want NLA and I want to use smart cards!
Have a jump box. Set up a couple of terminal servers and turn off NLA on them. Then set group policy to turn it on everywhere else. When you log on to the terminal server you'll have your smart card credentials available so NLA will work just fine to the other machines in that forest. In fact, do yourself a favor and open your saved RDP file for the terminal server in notepad and add the following line:
enablecredsspsupport:i:0
This turns off NLA attempt on the client side too. It will save you a few seconds on each logon and take you directly to the GINA for that server.
The fact that these servers are now susceptible to the potential denial of service attack, you need to consider your firewall options. What subnets are allowed to open 3389 connections to those servers? How many connections are allowed from any specific IP address on that subnet?
To summarize, here are your options:
- Don't use NLA (not a good idea unless it's just a few select servers used as jump boxes).
- Don't use smart card authentication (obviously, you need to be doing this - passwords are so last year, get over it)
- Have all your machines in the same forest (ugh, please don't do this)
- Have a trust between your workstation/user domain and your production enterprise domain (Don't do this either, only trust things you can actually trust. If it's connected to the internet, you can't trust it.)