Can’t ping the domain controller via FQDN while on the internal network? Trouble accessing any of the internal domains that are available via Direct Access while on your internal network?
This is a quick blog post to document an error I encountered that took me a while to figure out, as is typical with errors that are caused by configuration mistakes, yes self-inflicted. In the Microsoft Unified Access Gateway administration documentation for configuring Direct Access (DA), it says 2 things that are extremely important but does not emphasize just how important they are, or the errors that will be encountered if they are not followed.
Your Network Location Server (NLS), which must be able to serve HTTPS requests, is used by your DA clients to determine whether they are on the internal network, this site must not and cannot be accessible through DA or any other means from outside your network, so make sure the HTTPS resource is NOT something you need to access from external networks. If your clients can access the NLS then they will not attempt a DA connection. If they cannot access the server, then they will attempt a DA connection. There are a few key points to this server that also cannot be overlooked.
1.) The NLS needs to be as highly available as you can make it within your infrastructure. If this server is offline for whatever reason, your DA clients on the internal network will lose the ability to access most, if not all, internal resources due to DNS resolution issues because they will attempt to access all internal named (via DNS) resources through DA and your domain controllers. I ran into this issue because DNS is tied to the domain controllers and I lost access to the DCs via FQDN. NSLookups did still work, because you’re connecting by IP at that point, but actual resolution failed because DA attempts to send all internal network requests, determined by domain name suffixes, through the DA pipe. So even rebooting the NLS will cause access problems for all DA clients, albeit temporarily in the case of a reboot.
2.) The certificate on the NLS MUST be trusted by the DA clients. If the certificate / chain is not trusted by the DA clients, you will experience the same problems that are experienced as when the NLS is offline. You can test the trust by opening a browser, before adding a client to the DA group, and attempting to browse the site on the NLS. If you receive any kind of warning from the browser, then the client that you are using will fail to access the NLS server and that will cause connectivity issues while inside the network. This is not a full-proof way to test it, but for a quick and dirty confirmation or troubleshooting, it’s a good start. Some browsers, ie. Firefox, allow users to add browser based exceptions for specific certificates, so test with IE, Chrome, or another browser to make certain the resource is truly trusted.
If you change NLS servers, while a client is having access issues, it is also likely that they won’t be able to update their Group Policy Objects (GPO) (which is where the DA configuration information is stored), and thusly, not receive the NLS change. You may be able to solve this by connecting the client to an external network. If DA is functioning correctly from outside your network, your clients can then update GPO through DA. Confused yet? :) Example, in my case, I had network access from external, but not internal, so I was able to get policy updates while connected to a MIFI device. To force clients to update GPO, from a command prompt type:
You can also download the certificate and transfer it onto the DA client box manually via USB drive / key or a share that is still accessible. Place the certificate in the DA client computer’s Trusted Certificate Authorities store, NOT the current user store. You need to be a local administrator on the machine to make the change.
On the DA client itself you can use a command line program to check whether the machine is attempting DA or not.
netsh name show effective
If this command tells you that DA is unavailable while on the internal network, and you are on the internal network, then you are good. While on an external network, it will display information related to your domain controller, the NLS server, and other network services if all is working correctly. If you don’t have the appropriate messages while on the appropriate networks, you’re having problems that may likely be related to the NLS server as mentioned above.
The NLS server, again, should be fully trusted by the clients and NOT accessible via any means, from the outside network. During DA configuration, an NLS server blocking rule is created.
Hope this helps someone out.
By the way, this is a VERY helpful article for setting up Direct Access: