Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to DirectAccess, do’s and don’ts
Similar to DirectAccess, do’s and don’ts (20)
More from kieranjacobsen
More from kieranjacobsen (13)
Recently uploaded
Recently uploaded (20)
DirectAccess, do’s and don’ts
- 1. DIRECT ACCESS, DO’S AND DON’TS KIERAN JACOBSEN HP ENTERPRISE SERVICES
- 2. PLAN FOR THE NIGHT • Pre-deployment design considerations • Deploying your first server • Diagnosing Issues
- 3. WINDOWS 7 OR 8/8.1 Windows 7: • Requires certificate based computer authentication • Doesn’t support the use of NULL ciphers when IPHTTPS is used • Will require connectivity assistant to be installed • Has limited support for multi site deployments
- 4. HIGH AVAILABILITY OPTIONS • Load Balancing • NLB • External Load Balancer • Multi Site • Clients can select entry points automatically or can specify them manually • Global load balanced IP support • Limited Windows 7 support • Cannot deploy DirectAccess load balancing or multi-site on 2012 R2 when Web Proxy Server installed
- 5. 3RD PARTLY LOAD BALANCERS • F5 & Riverbed support various different deployment types • Ensure you enable NULL SSL Ciphers • Can provide SSL offload support (if supporting Windows 7)
- 6. DIRECTACCESS AND PKI • CRL and Strong CRL validation • IPSEC will fail to establish a connection if using certificate based computer authentication with computer certificates that use SHA512 hashing algorithm
- 7. LET’S DEPLOY
- 8. DON’T USE THE GETTING STARTED WIZARD
- 9. DIRECTACCESS WITH OR WITHOUT VPN
- 10. JUST 4 SIMPLE STEPS
- 11. STEP1: FULL ACCESS OR MANAGE OUT?
- 12. STEP 1: GROUPS
- 13. STEP 1: NETWORK CONNECTIVITY
- 14. STEP 2: NETWORK PLACEMENT
- 15. STEP 2: NETWORK ADAPTERS
- 17. STEP 3: NETWORK LOCATION SERVICE
- 18. STEP 3: NETWORK LOCATION SERVICE
- 19. STEP 3: DNS AND NRPT
- 20. NRPT RESOLUTION: EXCHANGE.CITADEL.UMBRELLACORP.INFO Whilst connected to DirectAccess, User’s Outlook client needs to connect to exchange.citadel.umbrellacorp.info 1. FQDN will be compared to the NRPT – only matches first entry in table, which direct it to DNS proxy on DirectAccess Server 2. User’s computer will send a DNS request to the DirectAccess server 3. DirectAccess server uses locally configured network interfaces to resolve request, if response from corporate DNS servers is an IPv4 address, DirectAccess server will substitute a IPv6 address. 4. Response is sent to the DirectAccess client
- 21. NRPT RESOLUTION: INSIDE.CITADEL.UMBRELLACORP.INFO (NLS ADDRESS) Whilst connected to DirectAccess, DirectAccess performs a connectivity test to see if it is connected to the corporate network 1. FQDN will be compared to the NRPT – matches second entry in table, which is the NRPT exemption. 2. User’s computer will send a DNS request directly to the DNS server configured on the client’s NIC 3. Public DNS unable to resolve the address, DirectAccess determines it is still externally connected.
- 22. NRPT RESOLUTION: MICROSOFT.COM Whilst connected to DirectAccess, User opens Internet Explorer and attempts to open up the Microsoft web page 1. FQDN will be compared to the NRPT – no matching entries are found 2. If Split Tunnelling (Default) : User’s computer will send a DNS request directly to the DNS server configured on the client’s NIC, Public DNS will then resolve the address and respond to the client. OR If Force Tunnelling: User’s computer will send DNS request to DirectAccess server, and the DirectAccess server will use locally configured network interfaces to resolve request, if response from corporate DNS servers is an IPv4 address, DirectAccess server will substitute a IPv6 address. The address is then sent to the client.
- 23. NRPT RESOLUTION: INTRANET (SINGLE LABEL) Whilst connected to DirectAccess, User opens Internet Explorer, types intranet in the box, hits enter: 1. Single-label is in use, append DNS suffix to request to form an FQDN 2. FQDN will be compared to the NRPT – only matches first entry in table, which direct it to DNS proxy on DirectAccess Server 3. User’s computer will send a DNS request to the DirectAccess server 4. DirectAccess server uses locally configured network interfaces to resolve request, if response from corporate DNS servers is an IPv4 address, DirectAccess server will substitute a IPv6 address. 5. Response is sent to the DirectAccess client – Either 1) resolved address or 2) Name not found 6. If name has been resolved, process completed all is done, if name not found, return to step 2 and try the next entry in the DNS suffix search order. If all suffix search entries have been exhausted, continue to 7. 7. Attempt to use LLMNR, NetBIOS or WINS * Special Warning *
- 24. NRPT RESOLUTION: INTRANET (SINGLE LABEL) – LOCAL NAME RESOLUTION
- 25. STEP 3: DNS AND NRPT (FORCE TUNNEL)
- 26. STEP 3: DNS SUFFIXES
- 27. STEP 3: MANAGEMENT SERVERS
- 28. STEP 4: APPLICATION SERVERS
- 30. DEPLOYMENT DONE
- 31. DIRECTACCESS DIAGNOSTICS • Check Operation Status in Remote Access Management Console • DirectAccess diagnostic log available from client • Access steps changed in 8.1 from 8 • Information Logged: • NCA Connection Status (Probes List) • IP-HTTPs Configuration (Get-NetIPHttpsConfiguration) and IP-HTTPs State (Get-NetIPHttpsState) • NRPT Policy (Get-DnsClientNrptPolicy) • IPsec Main Mode SA's (Get-NetIPsecMainModeSA) • IPsec Quick Mode SA's (Get-NetIPsecQuickModeSA) • And more…
- 32. DIRECTACCESS DIAGNOSTICS – EXTRA COMMANDS • “Custom Commands” group policy • Computer Configuration -> Admin Templates -> Network -> DirectAccess Client Experience Settings -> Custom Commands • Can be any PowerShell Command/Cmdlet/Function/Script • Recommended: • $wc=new-object net.webclient; $wc.downloadstring(“<your NLS address”) • $wc=new-object net.webclient; $wc.downloadstring(“<your NCA address”) • Nltest /dnsgetdc:<domain name> • netsh advfirewall show currentprofile
- 33. DIRECTACCESS AND GROUP POLICY • Server and workstation configured using group policy • Created by management console • Server policy filtered by server AD account • Client policy filtered by specified groups in step 1 wizard • Multi site creates server policies for each site • Policies created at root of domain
- 34. ANTIVIRUS AND SECURITY SOFTWARE • DirectAccess requires Windows Firewall IPSEC components • Be careful of web filtering functions • Ensure network IPS/IDS exclusions are correct
- 35. QUESTIONS AND LINKS • My Blog: http://aperturescience.su • My Twitter: @kjacobsen • Richard Hicks’ Blog: http://directaccess.richardhicks.com/ • Tom Schinder’s Blog: http://blogs.technet.com/b/tomshinder
Editor's Notes
- Hi everyone, my name is Kieran Jacobsen, for the past few years I have been working as an engineer for HP Enterprise services, on the bank of Queensland account. I am here tonight to talk about DirectAccess and my experience of deploying it in an enterprise environment. I recently finished a Windows 8 mobility project which had the aim of giving the CEO, those who reporting to him, and their executive assistants with a Windows 8 tablet, that had things like Office and lync 2013 and provided them with them remote connectivity to the corporate network with DirectAccess. At the start of the project, no one in the team had much experience with DirectAccess, and we have had a steep learning curve. Most of the things tonight will be based upon what I discovered during that project, as well as quite a lot of things I found out in my test lab. There are a few things which also come from an even larger deployment of DirectAccess. HP itself, is in the process of deploying DirectAccess. Just to look at some stats here, HP has approximately 331, 800 employees, whilst not all of these will have remote access, it is still a significant deployment.
- Before I begin with the tech stuff, just going to apologies that there are no live demos, you will however be seeing screen captures of the last deployment in my test lab. I had quite a bit to go through, and just didn’t want to risk loosing time to failed demos. So let’s start by looking at some pre deployment design considerations.
- To start with, what client operating systems are we supporting? Whilst I really love Windows 7, Microsoft really did improve on things in Windows 8 and 8.1 that make supporting Windows 7 clients pretty undesirable.Firstly, supporting Windows 7 will require you to enable certificate based computer authentication, are you prepared to issue certificates to your clients?The second issue is Windows 7 does support the use of the null cipher suites when connecting with the IPHTTPS interface. So its probably a good time to explain what the IPHTTPS interface is, and how it comes into play in DirectAccess. Basically, direct access is just a client to server, IPV6 IPSEC VPN solution, with a whole lot of extras to allow us to use it in less IPv6 compatible environments. Clients with direct access can establish the IPSEC tunnel over things like the 6 to 4 transition technologies, treedo, or even over a HTTPS session. It is this HTTPS session that we refer to as the IPHTTPS interface. When Microsoft originally deployed 7, IPHTTPS was really seen as a last resource, where if no other technologies could connect, a client could put the encrypted IPSEC tunnel over a HTTPS session, of course, wearing the hit of double encryption in the process. This performance hit was seen a the cost of resorting to this conectivity method. Microsoft has seen the light, and that people want to make this their primary connection method and in windows 8 introduced the null cipher suites, and when these are used we do not encrypt anything over the HTTPS session, which obviously improves the performance. Another minor reason is that we will need to deploy the direct access connectivity assistant to Windows 7, where as everything is built in in 8.The final reason is Windows 7 only has limited multi site support. For multisite to really work, you will need 8.
- In terms of high availability, Microsoft has given us a vast number of options. We can deploy multiple servers at a single site using load balancing, have servers at multiple sites, or mix the two. My lab has two separate sites, and load balancing at only one single site. Microsoft has made the process of setting all of this up incredibly easy! It is super easy, we just deploy one server, setting up all of the policies and organisational configuration, and then we expand from there.Load balancing can be either using NLB or an external load balancer.Each site when multi site is deployed is called an entry point. We have a few options about how we can control what entry points user connect to, we can select it for them, or even allow them to select their desired site.One big issue that I should point out. Load balancing and multi site are not supported on DirectAccess Servers which have the new web proxy, web publishing functionality that was introduced in Windows Server 2012 R2. IF you do install this new feature, you will notice the enable load balancing and enable multisite buttons will disappear from the remote access management console.
- The vendors of the major 3rd party load balancers, like F5 and Riverbed, actually do support DirectAccess really well, including IPV6 and also sorts of different deployment scenarios. These vendors are Microsoft partners, and have relationships with the DirectAccess team and “officially” they support DirectAccess. In reality, getting support out of these vendors can be a challenge as they are desperately trying to sell their own VPN products.We are using F5 LTM and GTM at BOQ, I am not sure what is used for the HP deployment. Deploying F5 LTM in front of DirectAccess was pretty simple, you just need to remember to ensure that the F5 is configured to support the null cipher suites.Richard Hicks, one of the DirectAccess MVPs, has instructions on using the F5 to do SSL offloading if you have to support Windows 7. In his configuration, the F5 will do all the decryption of the IPSEC traffic in the encrypted HTTPS session, and then use the NULL ciphers to establish a session back to the directaccess server. This will reduce the load on your direct access server quite considerably.
- Things are pretty simple in terms of DirectAccess and public key infrastructure. Direct Access does use a few certificates, but over all things are pretty simple.Two things to note. Firstly, DirectAccess isn’t going to be extremely picky when it comes to CRL validation. If for some reason it cannot access the CRL location, or the CRL file has expired, it will continue allowing the user to connect, however you can change this by enabling strong CRL validation in group policy, If this is enabled, clients which cannot connect to the listed CRL points on the certificates in use, will be unable to connect to direct access.Another thing that burnt me in my test lab pretty hard. Was the selection of a hashing algorithm on my certificate authorities. What I found was whenever I enabled certificate based computer authentication, the IPSEC tunnels would never connect. After quite a lot of work I narrowed it down to being certificate related. All of my certificates at the time were issued by a CA that used the SHA512 algorithm to sign certificate requests. On a random guess, I tried a different CA and everything worked. When you deploy a Windows CA, you are given the option of what hashing algorithm the authority should use when issuing certificates, by default its SHA1 I believe, however there is also the new SHA 256, 384 and 512 variants. Being a paranoid kind of administrator, I opted for 512 in my test lab, and haven’t seen any other issues since, until that is, I decided to enable certificate based computer authentication. Richard Hicks finally cracked the reason why this is the issue, and it relates back the Windows Vista days and beyond. If you are going to use certificate based computer authentication, ensure that your CA is using one of the other hashing algorithms, SHA1, 256 and 384 work perfectly. If your authority is issuing SHA512 certificates, you might need to look at using a different authority for computer authentication or not using certificate based auth.
- Let’s start deploying DirectAccess. This diagram here is part of my testlab. What we are going to look at is deploying the first direct access server at the production site.Things to note, before we continue, we are assuming that the right certificates have been installed, that remote access role has been enabled, and directaccess and vpn option installed, but the web proxy component has not been installed.Last assumption is that HTTPS has been made available through the UTM firewall to the direct access server.
- The first time you start the remote access management console you will be asked if you want to do one of two things, either run the getting started wizard, or run the remote access setup wizard.Unless you are performing a very, very simple deployment, do not select the getting started wizard, it makes some assumptions, and they are typically not going to be what you want. You can of course go through this option and go back and change what you want at a later date.I always select the Remote Access Setup wizard, you can still opt for the defaults as you go through the deployment process, however you will get greater flexibility and your deployment is more likely to succeed. If you are going to be going to a load balanced or multisite deployment, this is also the option you want to take.
- Next we will be asked about what remote access technologies do we want? Obviously there is DirectAccess, and the other is simply referred to as VPN. VPN here refers to the older style VPN protocols like PPTP, L2TP and Microsoft’s SSTP. I suspect you probably want one of the first two options.
- You will now be presented with the 4 step deployment screen. You have just four simple wizards between you a functioning DirectAccess deployment. Once we get through these very simple wizards, we should be able to use directaccess. Let’s click configure on step 1.
- The Step 1 wizard has a particular feel that you are configuring the client, but in reality you are configuring the both the server and the clients in every wizard. The first thing we are asked in this wizard, is what deployment scenario are we wanting to deploy. You have two options, full access, or manage out. In the full access scenario, your users will have access to corporate internal resources, and you will also be able to remotely manage their devices. In the manage out scenario, users will not be able to access an corporate resources, however you will be able to manage their devices.Typically you will want a full access scenario.
- Now we need to specify which groups of computers can use direct access. Whilst this is simple enough as selecting some groups with computers we want to access the corporate network, this is also where the first major weakness in directaccess appears. We can only control which devices can use direct access not which users can. This means if user A who is allowed to use direct access gives their configured device to user B, we don’t really have any way from stopping user b from connecting in. We also have the limitation that we have to add each device that a user has to this groups listed here. In a period where the computing environment is defined by users and not devices, this seems like a limiting choice.You also have the option on this screen to specify if only mobile devices can use direct access. Bascially, your saying to only allow laptops, notebooks, tablets and not desktops or virtual machines to connect to direct access. I leave this off as I like having virtual machines connecting in especially when I am testing.Finally there is an important option here, Force Tunnelling. By default, direct access works as a split tunnel vpn. So those of you who don’t know the difference, in a split tunnel VPN, the client will only send traffic down the vpn connection to the corporate network, if it really is destined to go there. For example, the CEO’s bit torrent will go only go over the WIFI connection and not through the VPN and thus the corporate network; however, his access to the HR system, will go over the VPN connection and to the corporate network. In a force tunnelling scenario, all of the CEO’s traffic will go over the CPN and thus to the corporate network. There are many arguments about what is better, which is more secure, and which is faster, and I am going to stay out of it for tonight.I haven’t spent a huge amount of time investigating the ins and outs of enabling this option. So I cannot comment that much on the impacts of enabling force tunnelling.Richard Hicks tells me that IPHTTPS is preferred. Technet tells me that 6to4 and Teredo are disabled and I quote, Force Tunneling-enabled clients will still be able to access any resources on their local subnet, such as network printers, but any network traffic beyond the local subnet must be IPv6 traffic. The only locations that a DirectAccess client can reach by default with IPv4 traffic are those on its local subnet. All other traffic sent by the applications and services running on the DirectAccess client is IPv6 traffic sent over the DirectAccess connection. Thus, IPv4-only applications on the DirectAccess client cannot be used to reach Internet resources. End quote.
- The last screen in this wizard is the configuration of the network connectivity assistant or NCA. This settings should not be confused with network location awareness which we will configure shortly. The NCA basically helps the directacess client determine if it has successfully connected to the corporate network. It is this test that changes your connection status from “connecting” to “connected”.On this screen you can specify a number or resources, either http or ping targets. Once the main IPSEC tunnel is up, and before any futher traffic is allowed through, the directaccess client will attempt to test these resources. If there is any issues, dns resolution, connectivity, some sort of configuration issue, or these resources are down, then your directaccess clients will not allow any traffic through, and from a user point of view, the connection will say “connecting”.One NCA resource will be automatically created, a HTTP check to directaccess-nls dot your domain name. You can just live with this one, but think about selecting others when using any of the HA options. Next, always specify an email address. If you don’t specify one, your clients cannot generate diagnostic debug logs to provide assistance in troubleshooting issues. Now you can change the name of the direct access connection, or use the default workplace connection.Finally, there is the option to allow our clients to use their local name resolution, I haven’t seen any noticeable changes when this option is enabled, the default is disabled.
- Now on to the step two configuration wizard and the first thing we need to decide is how are we connecting the directaccess server to the network?Are we placing the server at the edge of the network or behind a firewall? Single or dual nic configuration?I will admit that all of my deployments have been single nic behind a nat device.Finally, what is the external hostname or ip address. This is the external address clients will connect to with DirectAccess.
- Next, you need to pick a network adapter, and you will need to select a certificate.The certificate needs to be trusted by the client and must have the name you specified in the previous screen. You have two options, you can use a self signed certificate, clients will be configured via group policy to trust it. Otherwise you can specify a certificate, either issued by a third party authority like versign or your internal certificate hierarchy.
- So, how are we going to authenticate users and computers.Firstly, are we authenticating users based upon their account credentials, or do we want to implement two factor based upon smart cards or one time passwords?Secondly, are we using certificates to authenticate client computers? and what authority is issuing those certificates? If you are going to deploy multisite or support windows 7, you will need to enable this. One thing to note about certificate based computer authentication is you will need a certificate for each direct access server.Finally, do we want to use NAP?Now whilst we have finished step 2, one thing I do want to point out, direct access does not need a TPM on the client, it never has. This is a common misconception, and I really don’t know where it came from.
- On to the step 3 configuration wizard.Now this is one of the most important decisions you will make, what will you select as the network location server address, or NLS address. Sometimes the NLS is also called the Network location awareness address or NLA address. This address is what will be used by the clients to determine if they are connected directly to the corporate network or on some other network. If your NLS location is inaccessible to clients when they are directly connecting to your network, then, they will think they are externally connected, causing no end to the chaos. This URL will not be accessible over direct access, so be careful what you select, and certainly do not select something like the corporate intranet page. You have two options, firstly, specify a URL, like we have here, or we can select to host the URL on the directaccess server. The recommended option is to specify some URL, I suggest that you create something just for this, I think something that is unique and most definitely highly available. Load on this is very low, so you could have it hosted on a bunch of servers that already have IIS installed for other things. There are not many requirements for the NLS, simply that it is HTTPS protected and not resolvable though the public DNS infrastructure.I also think you should put a page at the end of the address, like here where I have put whereami.htm. Why unique and why specify a page? Well, in the past I used a simple FQDN, about 99 percent of the time, everything was ok. Occasionally however, you might find an externally connected client is actually resolving your NLS FQDN even whilst not connected to the corporate network! How is that? Well a lot of free wifi providers use captive portals so their users are redirected to a usage agreement page, or a payment page, and they do this by responding to all dns queries with the ip address of the page you want to go to. There are also other providers like openDNS and Telstra, who redirect unresolvable DNS address to a search results page. To ensure there was no chance of confusion, I use a unique url, and for additional protection a unique page on the end. Whilst it might sound like paranoia, when working with users like the CEO, its better safe than sorry.Finally, if you are going to be deploying either of the HA options, you will need to specify a URL.
- If you don’t want to specify a custom URL, then you can select to host the URL on the server. What will be created for you is directaccess-nls dot your internal domain name.You will also need to specify a certificate. This certificate will need to have a common name specified of directaccess-nls dot your internal domain name. You could use a certificate issued by your internal certificate authority, or use a self signed certificate.
- Next we need to configure DNS for our directaccess deployment. DNS in directaccess is an interesting beast and doesn’t act how most administrators would expect it to.When directly connected to the corporate network, resolution will occur as normal, with names resolved based upon the DNS servers in the address settings on the network interface or perhaps using something like NetBIOS, or WINS or LLMNR to resolve an addres. When connected with DirectAccess name resolution will depend upon the settings specified in the Name Resolution Policy table or NRPT. The easy way to think of the NRPT, and this was suggested by the MVP Tom Shinder, is the NRPT is like a form of “DNS Routing”. In the screenshot here, taken from my deployment which was the default split tunnel configuration we will see two entries created for us by the wizard.The first is for my internal domain name. Citadel.umbrellacorp.info is my test labs internal domain name. This entry has an ip address in the right hand column, and what this entry will do is to cause all queries with our internal domain name to go to the DNS proxy component on the directaccess server. You will want an entry like this for each of your internal domain names. The next entry is inside.citadel.umbrellacorp.info, this is my NLS address. Notice there is no IP address, this is called an NRPT exemption entry. This ensures that even though it would normally be a url that would qualify through the first entry, that is, an internal address, the query will actually not be sent through to the directaccess server for resolution it will only occur using the locally configured DNS server. This prevents resolution and thus connectivity to the NLS address, thus it prevents the directaccessclient from thinking that it’s on the corpnet when it is not. If a name doesn’t match any entries on the NRPT, then the name resolution request is sent to the DNS server configured on the client’s network interface, typically a public DNS server. Having said that, if force tunnelling is selected, then all resolution requests will be directed to the DNS proxy.The three options below control how the resolution of single label domain names, like, simply intranet will occur. Let’s look at an example of how directaccess resolves an address when an FQDN is specified, and when a single label domain is specified. These examples should be the easiest way for you to understand the impact of the NRPT settings on your clients.
- For all of these examples, the client is connected to directaccess.So in this first example, we have a users outlook client is connecting to the exchange server via its FQDN of exchange.citadel.umbrellacorp.info. Resolution will start by comparing the FQDN with the entries in the NRPT, the first entry will of course be a match, and no others. That entry directs the client to send the resolution request to the DNS proxy on the direct access server, which in tern will go off to the corporate DNS servers to resolve the address. If the response comes back to the proxy in the form of an IPv4 address, then the Directaccess server will kick in performing the DNS 6 to 4 and NAT 6 to 4. DNS requests will always have either a response containing an IPv6 address, or a messaging stating the name could not be resolvedThis one was pretty simple right?
- Second example, this time the directaccess client it trying to see if it has been connected to the corporate network directly, and wants to resolve the FQDN of the NLA address. Once again, the FQDN is compared to the NRPT, we actually have two matches in the table, one which is our general citadel.umbrellacorp.info and a more specific inside.citadel.umbrellacorp.info match. The second is the one which will be used as it is more a more specific match than the first. The NRPT directs us to perform the match using the locally configured DNS servers on the clients connected network interface, which is a public dns server. The public dns is hopefully unable to resolve the address, and response as such to the client. DirectAccess confirms it is still externally connected.Still simple right?
- Slightly more complex is resolving something like Microsoft.com. In this case the user is trying to go to the Microsoft website, once again the FQDN is compared to the NRPT, but there is no matches! There is two options.If we are using split tunnelling, then the DNS request will be sent to the DNS servers specified on the network interface, presumably public DNS servers. If using force tunnelling, then the request will actually be sent to the DNS proxy and the resolution will occur much like the exchange server address did previously.Not that complicated, but becoming more so. One more, the most complicated of them all.
- So what happens if the user just goes to a browser and enters intranet or exchange? These are single label names! Well this process is well understood by administrators normally. If the client was connected to the internal corporate network, then Windows appends the DNS suffix search order list on the end and tries resolution until it succeeds or ultimately fails. If DNS resolution fails then we can fall back on trust NetBIOS, wins or LLNMR.Simple right? Well it is far from it when a client is connected to DirectAccess!The process is a modified version of what would normally happen during DNS name resolution. We will get the single-label name, append the first entry from the DNS suffix search order list, processing the NRPT like we would with any FQDN. If we don’t get a response we try the next entry in the search order list, check the NRPT and so on. It is when we run our of suffix entries to check against that things become weird.In DirectAccess restrictions on the use of local name resolution technologies like LLMNR, NetBIOS and WINS exist, and these are specified in the configuration of the NRPT.
- Remember those settings on the bottom of the NRPT policy page? Well, they are just coming into action. If we have been unable to use DNS to resolve a single label address, then there is three options on what we can do next.The most restrictive is to only fall back to using local name resolution if DNS resolution has returned us with a NAME NOT FOUND response. We can specify this action by selecting the first option in the list of three at the bottom of the NRPT configuration screen.Or we can select the default, the recommended option. In this option the use of local name resolution, that is NetBIOS, LLMNR or Win server, will only occur if we receive either no response from the DNS server, or the DNS server response that the name is unresolvable, and we are connected to a network defined as either a HOME or WORK network, that is to say, we are not on a “public” network.Finally if we have selected the third option, Fall back to local name resolution for any kind of DNS resolution error,then no matter what kind of DNS error we receive, be it unresolvable or no response at all, and no matter what kind of network we are connected to, then we will attempt to resolve the address using NetBIOS, LLMNR and WINS. Selecting this option could be considered a security risk as we will be performing broadcast name resolution on public networks. I should point out that again that all of this is simply for single-label names and not fully qualified domain names. And that this will only occur if we selected the option to allow local name resolution all the way back in the step 1 configuration wizard!Confused? Well, you will get the hang of it. Let’s get back to the configuration wizard and finish off deploying this server!
- Just a quick thing to show here, if we had selected force tunnelling, then the NRPT would look like this. We still have our two entries from before, but we also have one called any suffix, this ensure that all DNS traffic goes over DirectAccess, we also have in this case two exemption policies, one for each of the public dns names for my entry points.
- The next step is to configure the DNS Suffix search list. Now this is entirely optional, if you already have this configured in your environment, then you can uncheck the option. Just remember that the hostnames are how clients determine what to send over the connect and what not to send. You need to make sure you have these search orders specified somewhere.
- The last thing to specify in step 3, is to specify the management servers. These are the servers that will be able to connect to remotely connected clients.
- The step 4 wizard is to optionally configure end to end authentication, this allows clients to authenticate to internal application servers.For most deployments, you will probably be leaving this at to the default, which is do not extend authentication.All you need to do is hit finish.
- So once you have answered all of these questions, you can hit finish. You will be presented with the screen shown here, everything will be listed here, allowing you to check everything is specified correctly.There isn’t much to know here, but there is one thing I really want to point out. This is the only place where you can change the name of the group policy objects that will be createdIf everything looks good, hit apply.
- The remote access management console will now go off and configure everything up, once it is done, you hopefully will have either a success message, or perhaps a single warning like the one above, this you can easily ignore.Basically you are done, setup a windows client, add it to the right groups and update group policy. Make sure the client has a certificate if it is required, and go off and connect remotely!
- What do you do when things go wrong? Well there is some good news and bad news. The bad news is that the windows event log on both servers and clients doesn’t have a whole lot of information. The good news is there are some things to make up for it.Firstly, there is a some what useful operational status screen in the remote access management console. It can point out a lot of obvious things that you might have wrong in your environment.After that, you need to look at a client. From a client you can generate a diagnostic report which contains a tressure trove of troubleshooting information. Unfortunately it takes quite some time to learn to understand everything it contains. The contents of the report have changed little from windows 7, 8 and 8.1, the way to generate the report has, but even that is pretty similar. One annoying limitation is it does require user interaction to generate this report.The things I look for are:Are my IPSEC Tunnels, both main and quick mode up?Is my IPHTTPS interface connected? Can I get to my NCA addresses?
- The really good news, is you can expand upon what is in this report to give you even more information.So using group policy, we can actually add our own list of tests that we want performed. The neat thing, is that the client diagnostic report is actually generated by powershell, so we can use powershell commands.Simply open your group policy and navigate to computer config, admin templates, network, direct access client experience settings and look for custom commands. You can add your powershell commands as individual lines, and their output will be nicely formatted in the report for you!The main commands I added were two web tests for the NLS and NCA addresses and an NLTEST command to see if I could resolve a domain controller name. Another handy one is netshadvfirewall show currentprofile, because this will tell you if it is domain, public or private.
- Speaking of group policy, DirectAccess is almost entirelyconfigured by group policy, hence the reason why clients and servers need to be domain joined. We will have a policy for clients and for servers, and we could have multiple server policies if we deploy multi site. All of the policies will be created at the root, there really isn’t any simple way of specifying where they are created.This is another small limitation with DirectAccess, because there are times where you might make a change, go to test and see no real difference. This is often due to the fact group policy might not have replicated to all of your domain controllers, or that your clients or servers haven’t refreshed their policies. Sometimes your changes will take effect in the background, other times you will need a reboot, its better to be aware of this. I have had to reboot both clients and servers at times to ensure all of my policy items have correctly applied.
- DirectAccess can have some very interesting interactions with antivirus software. You need at least the IPSEC connection security components of the Windows Firewall, the outbound and inbound filtering can be disabled, but you need the IPSEC functionality.Most of you have probably deployed some sort of endpoint protection suite which includes a firewall and it probably disables all of the windows firewall. If this happens, you are not going to be able to connect. Some AV products, like those form Symantec and Mcafee will allow you to keep the IPSEC enabled, and even support DirectAccess through their firewall functionality, but it is my experience that removing these 3rd party firewalls is the simplest solution, as they just seem too clumsy to configure. We spent quite a lot of time trying to get the BOQ third party endpoint firewall to work with DirectAccess but we just couldn’t make it work.Another thing is some of these endpoint suites transparently filter http and https traffic and that could cause issues as well. Keep an eye on the logs to ensure they are not blocking your connections.Next, these endpoint products could also have some sort of heuristic filtering engine that looks for suspicious traffic, keep an eye on those logs as well.Finally, if you are seeing issues, and your sure the clients are ok, make sure that your network IPS/IDS units are not blocking the traffic.
- So that is it, here are some very useful links including my blog, my twitter, Richard Hicks’ and Tom Schinder’s blog.Does anyone have any questions?