One of the most mysterious errors you’ll see when working with DirectAccess are related to failures in IP-HTTPS connectivity. I did a blog post on this problem last year and you can find it at http://blogs.technet.com/b/tomshinder/archive/2010/03/30/troubleshooting-the-no-usable-certificate-s-ip-https-client-error.aspx
Phillip Sand clued me into another possible cause of IP-HTTPS connectivity problems. First, whenever you suspect a problem with IP-HTTPS connectivity, you should run the command:
netsh interface httpstunnel show interface
If you see the following:
Role : client URL : https://da.domain.com:443/IPHTTPS Last Error Code : 0x103 Interface Status : no usable certificate(s) found
Where da.domain.com is the FQDN used to connect to the IP-HTTPS listener on the external interface of the UAG DirectAccess server, then you know you have a problem.
In addition to the cause I mentioned in the earlier blog post is a situation related to the CA certificate not being installed in the NTAUTH store of the UAG DirectAccess server. You can find out if the CA certificate is installed by running the command:
certutil –v –store –enterprise ntauth
on the UAG DirectAccess server. If everything is OK, then you’ll see something like what appears in the figure below (this is what you’ll see if you’re using the UAG DirectAccess Test Lab Guide for your UAG DA lab):
If you don’t see any certificate listed, then that can cause the 0x103 error on the client.
You can fix the problem by running the command:
certutil –addstore –enterprise –ntauth IssuingCACert.cer
Where IssusingCACert.cert is the root CA certificate.
Hat tip to Philipp Sand for this great info!
Tom Shinder email@example.com Principal Knowledge Engineer, Microsoft DAIP iX/Identity Management Anywhere Access Group (AAG) The “Edge Man” blog : http://blogs.technet.com/tomshinder/default.aspx Follow me on Twitter: http://twitter.com/tshinder Facebook: http://www.facebook.com/tshinder
Visit the TechNet forums to discuss all your UAG DirectAccess issues http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/threads
Stay up-to-date with “just in time” UAG DirectAccess information on the TechNet wiki http://social.technet.microsoft.com/wiki/tags/DirectAccess/default.aspx
On my clients and every other server the NTAUTH store has certificates. The DA server doesn't. Could it possibly be the lack of a gateway on the DA server? Suggestions?
The DirectAccess server definitely needs a default gateway - since it's receiving and sending messages from and to IPv4 hosts on the Internet.
Sorry for the poorly written question. The docs say that the DA server should not have a gateway configured on the corpnet interface.
I was unable to view the NTAUTH certificate store so I rebuild the DA server from scratch and I'm still running into the same issues.
- Single domain, single forest
- Disjointed namespace
- We have 40+ sites, 40+ GCs, and 40+ subnets worldwide
- I'm trying to enable DA in one of those sites to access one of the sites (LAX.corpnet.local not SFO.corpnet.local or any of corpnet.local)
I've added routes to all the sites that contain AD roles (just a guess, not in any of the documentation I saw).
When I run the DA setup wizard it tells me that Active Directory is unavailable. We haven't restricted the netlogon service or DNS as to which sites use which DCs. My initial thoughts are that it is selecting a DC that it does not have a route to.
I'm going to do some network captures and try to see what's going on but I thought I would post here in case you had some info to share.
If you are getting an error that the AD is not available, that is significant.
Could it be a name resolution issue?
A routing issue?
A firewall or some other filtering device between the UAG DirectAccess server and the domain controller?
Let us know what you find out from your network captures.
I've now run into a second server in a different site that cannot verify the ntauth store.
DNS is perfect.
Persistent routes have been added for the subnets that contain the CA and the PDCe.
No firewall or filter between.
PKI is rock solid.
I can enroll and autoenroll certificates no problem at all.
It seems like I need a route to *something* else as this doesn't happen on machines that have routes to all of our sites. That or having the external NIC is causing problems. Only the two DA servers have experienced this problem so far.
Checking a DC seems to work fine:
certutil -viewstore "ldap:///CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=domain,DC=com"
CertUtil: -viewstore command completed successfully.
Checking locally fails:
CertUtil: -store command FAILED: 0x80070002 (WIN32: 2)
CertUtil: The system cannot find the file specified.
gpupdate /force runs without a problem, domain admins without cached credentials can login, etc.
Nothing in the event logs, rebooted numerous times.
After some digging I found that the below registry key didn't even exist. I exported it from another machine and now the above certutil command is working "fine", not that I'm confident in the config as it wasn't transferred automatically.
The only problem that I could find after going through a lot of documents, how to guides, kb articles, etc. was that the binding order of the NICs had the Internet NIC higher when I ran the DA wizard. I haven't seen this mentioned anywhere about DirectAccess (which I have) but it is in a few articles for DirectAccess UAG so perhaps that's been causing my problems.
Side note: My PDCe is in Europe (200ms ping times) so not being able to specify which Domain Controller that DA contacts during the wizard is a bit of a pain (it takes almost an hour to complete).
You seem to be available first thing in the morning (PDT) so I wanted to get this typed up in the hopes you have some comments or suggestions. Sorry there are errors or omissions, it's late here :)
Figured it out. We were only using auto enrolment for our clients, not servers.
Certificate auto enrolment must be enabled for the NTAUTH local certificate store to exist. That or you can manually create it using:
certutil -enterprise -addstore NTAuth CA_CertFilename.cer
So, if you're not using autoenrollment for certificate distribution for the server, the server won't get its certificate added to its local NTAUTH store. I can honestly say that I never heard of this before and I really appreciate you sharing this with us!
Microsoft KB article:
The contents of the NTAuth store are cached in the following registry location:
This registry key should be automatically updated to reflect the certificates that are published to the NTAuth store in the Active Directory configuration container. This behavior occurs when Group Policy settings are updated and when the client-side extension that is responsible for autoenrollment executes. In certain scenarios, such as Active Directory replication latency or when the Do not enroll certificates automatically policy setting is enabled, the registry is not updated. In such scenarios, you can run the following command manually to insert the certificate into the registry location: