UAG SP1 DirectAccess: Config Wizard, Infrastructure Servers

Author by Shannon Fritz

This is one of the wizards you may revisit over time because it is where you will specify which hosts the computer accounts can access prior to a user logging onto the workstation (for example, Domain Controllers and virus update servers) and which hosts should not be accessible over DirectAccess (like the NLS and resources you truly want to be available on the Intranet only). Enter the FQDN of the Network Location Server that you built earlier (don't include the "HTTPS://" prefix in the text box).  Once you click Validate and see the green checkmark you are ready to move on.  I'll point out again the recommendation that the NLS be made highly available. It is particularly important to understand this next part of the wizard when your Internal domain name matches your External domain name.  On the DNS suffixes page you can specify DNS names and patterns that will be placed the Name Resolution Policy Table (NRPT) of your DirectAccess clients.  The NRPT is basically a list of rules that defines special handling of DNS requests that match items on the list.  You will use this to tell the DirectAccess clients if it should ask the corporate DNS servers to resolve a host name or if instead it should ask a different DNS server, like the one defined on it's local network adapter. There are two items that should always be in this list, and they are filled in automatically.  The first is your windows domain (*.yourdomain.com) and it'll be set to use [DNS64].  This means any request for a host on your domain will use the DNS64 translation feature of UAG to resolve the IP address of that host.  It works something like this:
  1. A DirectAccess clients want to find host.yourdomain.com
  2. The *.yourdomain.com entry in the NRPT tells the client says to use DNS64
  3. The DA client sends a DNS request to your UAG server for the address of host
  4. The UAG server relays that request to your corporate DNS server
  5. The DNS server looks up host in it's database ... If it knows an IPv6 address (ISATAP, etc) it replies with that AAAA record ... If it only knows an IPv4 address it replies with that A record
  6. If need be, the UAG server translates the (A) IPv4 address to (AAAA) IPv6
  7. The UAG server sends the IPv6 address back to the DA client
  8. The DA client sends it's traffic to the IPv6 address ... This is where ISATAP, 6TO4 or NAT64 would come into play which is a different topic
That works great, but what if you have a hostname that should not resolve to an internal resource?  For example, the Network Location Service?  Remember, if the DirectAccess client can find the NLS it'll think it is inside the corpnet and will not bring up the DirectAccess interfaces.  If they can find NLS over DirectAccess it'll shut the tunnels down, no longer be able to find them and bring them back up again and loop over and over.  It'll be a big mess. So how do you prevent that?  By using an exclusion.  An exclusion simply says not to use your UAG server to ask internal DNS servers for the answer.  This causes the client to instead ask the DNS server that is configured on it's physical NIC for the answer.  So for example, your client is connected to a hotel network and it is given an IP and DNS configuration from DHCP there.  When a host matches the exclusion rule it will ask for and answer from the DNS server that was assigned from DHCP instead of from the corpnet. At this point you should take a moment to think about how DNS operates in your organization.  If your internal domian name and external domain name are different, then the two rules that are present should likley be all you need and you can move on, but if the domains are the same, then you should consider what host names should resolve to an internal address and which ones should instead resolve externally.  Let's say for example that you want users who are inside your network to find the host "WWW" to bring up a web page from your Intranet Sharepoint site, and those who are outside your network would instead bring up your company's public web site.  This would be accomplished with an exclusion. You could also use exclusions to simply prevent DirectAccess clients from finding and using other internal resources that you do not what them to have access to outside the corpnet, or perhaps that resource has external connectivity and they should use that instead of traversing the DirectAccess tunnel.  For example, you would want to exclude Outlook Web Access or Lync / OCS since those have public interfaces that users outside the office should (or must) use instead of traversing the DirectAccess tunnel. To exclude something from DNS64, enter the hostname (or entire domain suffix) and specify not to use internal DNS.  This will cause the NRPT to direct the client to query it's own DNS server (likely assigned form DHCP) to resolve the IP address.  Click OK and repeat if you have several hosts to exclude. Here's a couple common examples to exclude:
  • mail.domain.com
  • owa.domain.com
  • webmail.domain.com
  • autodiscover.domain.com
  • _sipinternaltls._tcp.domain.com
  • _sipinternal._tcp.domain.com
  • _sip._tls.domain.com
  • _sip._tcp.domain.com
  • sip.domain.com
  • sipinternal.domain.com
  • sipexternal.domain.com
The final page of this wizard lists all of the resources that a DirectAccess enabled computer should know about even before a user logs in and they are made available on the "Infrastructure Tunnel".  This wizard does a nice job of auto-discovering servers but the list should include servers such as Domain Controllers (so machines can update their group policy and authenticate users), Anti-Virus servers (so definitions can be updated), Client Management servers (like WSUS and System Center Configuration Manager so software updates can be applied), etc. The servers added to this list will be injected into the Client GPO and establish some IPSec policies against their current IPs, so if you change an address or replace a server, you'll need to revisit this page and update the list.  Your DirectAccess clients will also then need to process group policy as they would do naturally. You can hit Finish and move on to the final wizard.  You're almost done!
Author

Shannon Fritz

Infrastructure Architect & Server Team Lead