Hey everyone, I'm facing a tricky situation with two separate Active Directory environments, domain1.local and domain2.local, that don't have any trust established between them. domain2.local can only be accessed through a network that includes domain1.local and strictly via an RDS Gateway. The DCs for domain2.local aren't visible or accessible from domain1.local.
domain2.local wants to implement Smartcard Logon for their RDS Gateway and Session Hosts as they're transitioning away from NTLM. While Smartcard Logon works fine for direct logins from domain2.local workstations, I'm having issues when users from domain1.local try to log in through the RDS Gateway.
Initially, users can authenticate with the RDS Gateway using their smartcards, but on trying to connect to the RDS Session Host, they encounter an error: `The specified user name does not exist. Please verify the user name and try again. Error code: 0xa07.`
I've found that if I disable the option to use the same credentials for both phases of the authentication process, it still fails unless I switch to username/password while NTLM is enabled.
To troubleshoot this, I've concluded that the following must be true:
1. The smartcard's root and intermediate certificates need to be trusted on the domain1.local workstation.
2. The intermediate CA certificate for domain2.local's KDC must be in the NTAuth store of domain1.local.
When I set things up this way, the Smartcard logon works as expected. I'm wondering if anyone has managed to achieve this without requiring the intermediate CA certificate in the NTAuth store of domain1.local?
Also, I've noticed some quirks, like KdcProxy on the RDS Gateway and whether I need to configure it in the .rdp file. I have some questions about testing KdcProxy and smartcard certificate validation as well. Any insights or experiences would be great!
4 Answers
You're running into classic PKINIT issues here. The connection from domain1.local to domain2.local requires mutual trust between the certificates on your smartcard and the DCs. When connecting, the client in domain1 needs to trust the DC's certificate, which is why installing it as a trusted CA in the NTAuth store is necessary. Note that the intermediate CA installation is also critical for the chain of trust.
If you’re talking about NLA/CredSSP for your RDS Session Host, you might have to consider possibly disabling NLA. It can cause issues if accessing from outside the domain, but that's not always the right solution. Just tread carefully here!
For real, don’t disable NLA! It's crucial for security.
It looks like you've done your homework here! As you pointed out, the KDC Proxy isn't strictly necessary if clients can connect directly to the KDC in domain2. Also, you're spot on with your requirements about trusting the certificates. Remember, for smartcard logins, the clients should have both the root and intermediate certificates trusted. If you're using unambiguous usernames like FQDN or UPNs, that can help too. Just make sure your DNS is functioning correctly across both domains!
From my experience, you definitely need both the trusted root certificate and the intermediate CA certificate in the NTAuth store. If domain1.local clients can't reach domain2.local's KDC directly, that's crucial. Ensure that the entire certificate chain is trusted on the domain1.local clients, or else KDC authentication will fail. Also, it's essential that the revocation endpoints are accessible too.
Definitely don’t turn off NLA—it secures your connections. It can interfere, but try to find a way to get both smartcard logon and NLA working together!