While I spend most (all) of my time working with the UAG DirectAccess solution, UAG DirectAccess is functionality essentially represents a superset of Windows DirectAccess functionality. Therefore, I thought it might be interesting to share with you all some questions I received from a fellow who is interested in deploying Windows DirectAccess. Maybe the questions and answers contained here will help you with your own planning for deploying DirectAccess in your SMB environment.
Question/issue 1: I’m in the process of putting together a DirectAccess solution for a small client of mine that needs the features of DirectAccess but can’t lay down the cash for multiple physical servers or UAG. They don’t need the additional complexities of access to IPv4 only resources as this is basically going to be a new network starting from scratch.
I know this may not be ideal from a performance perspective because of the many shared roles and limited scalability, but this is not going to be a network with many users; rather it will be a network of a dozen or so kiosks that will always be remotely connected. I’m starting to experiment some but haven’t found many resources for the absolute simplest implementation of DirectAccess.
I will certainly be going through the test lab documentation and other papers from Microsoft regarding the set up, but I thought I’d ask just in case anyone knows of some resources I haven't found yet (or just has some good tidbits of info themselves).
My concept is this:
What I’d ultimately really love is a "test lab" document similar to the one already out there from Microsoft but designed to interface with the real internet instead of a fake internet. The document makes several references to "problems" trying to adapt that test environment into a real world scenario, but it doesn’t give a whole lot of information about what "problems" they are referring to.
ANSWER: First off, these are great questions and thanks for sending them my way. Examples of planning for real-world deployments help everyone on their trek to DirectAccess goodness.
Since your customer can’t afford UAG at this time (maybe he will in the future as the company grows), the place to start is with the Windows DirectAccess solution. You are right that you will not have support for IPv4-only resources on the intranet, and your high availability options are somewhat limited. But you recognize these conditions and we can work within these parameters.
We generally recommend that you don’t put the Network Location Server on the domain controller, especially in pure IPv6 scenarios for some reasons regarding interface timings. While I don’t have the details in front of me, I have received information from a DirectAccess PM who strongly recommends that the Network Location Server not be placed on a DC – so if you could create a VM for the NLS, that would be a good way to go.
You can put the DirectAccess server in a virtual machine. However, there are performance implications and therefore we generally recommend that you put the DirectAccess servers on physical machines. With that said, you mention that this is going to be a relatively lightly used configuration, and therefore you might be able to get acceptable performance. You’ll need to monitoring your deployment and see if you are running into processor bottlenecks.
It is good that you’re planning on dedicated NICs for the virtual and physical interfaces. DirectAccess will perform better this way.
It’s also good you recognize that the firewall in front of the DirectAccess server will perform only firewall functionality and not NAT, because DirectAccess is not supported from behind a NAT device (although it can be done with the help of a few routing tricks, but that configuration is not supported by the product group).
Windows 7 Enterprise or Ultimate is required – so you’re good with the OS on your clients. Keep in mind that these must be domain members.
Regarding the problems that we suggest with the Test Lab Guides here are a few things that I can think of:
With those things in mind, you can create a “live” pilot deployment. I’d recommend that you obtain a commercial certificate for the IP-HTTPS listener, and not use the CRL checking disablement steps I deployed in the UAG DirectAccess Test Lab Guides.
Question 2: What are the advantages/disadvantages of using a native IPv6 infrastructure (with a tunnel broker like Hurricane Electric) vs just using ISATAP? Are there any compelling reasons to go ahead and go native (especially if the network is going to be new with no legacy devices)?
ISATAP is useful if your network infrastructure isn’t IPv6 aware, since you can tunnel your IPv6 traffic over IPv4 and use your current IPv4 routing infrastructure. However, if your routing, DNS and DHCP infrastructure is all IPv6 capable, there’s no need to deploy ISATAP and I’d recommend that you go native IPv6. You will need to configure your routers (and maybe the hosts) on your network so that they know the route back to the DirectAccess clients.
In most cases that will require that you make the DirectAccess server the IPv6 route of last resort since this is the only way to get the messages back to the 6to4 DirectAccess clients – or better, you can disable 6to4 on your DirectAccess clients and they will use Teredo instead – then your routing tables will be a bit “cleaner” and you want need to make the DirectAccess server the IPv6 route of last resort.
Question 3: What are the security implications with opening up inbound IPv6 traffic into your network? Since DirectAccess requires Protocol 41 traffic to be let through the firewall directly to the external NIC on the DirectAccess server, doesn't this open up some potential security issues without an IPv6 firewall in place? Maybe I am missing something, but since Protocol 41 is encapsulating ALL IPv6 traffic in IPv4 packets isn't letting Protocol 41 traffic through essentially the same thing as having a computer directly connected to the IPv6 internet with no firewall at all?
IP Protocol 41 is used to indicate that there is direct encapsulation of IPv6 packets within an IPv4 header to support 6to4. So, we’re not really allowing all IPv6 traffic through the firewall, just 6to4 traffic. Also, keep in mind that both of infrastructure tunnel and the intranet tunnel require authentication – for the infrastructure tunnel, both computer certificate and NTLMv2 authentication is required, and for the intranet tunnel, both computer certificate and Kerberos v5 authentication is required.
While all IPv6 traffic is allowed through the IPv4 tunnel – traffic to the DirectAccess server is allowed only after the client authenticates and establishes a valid IPv6 IPsec connection . We also have some Denial of Service Protection technology built into to take care of malicious users who try to take advantage of this situation, though. However, if you don’t think this is enough – you can take my earlier recommendation and disable 6to4 on the DirectAccess clients and let them use only Teredo or IP-HTTPS. Keep in mind that this is the same situation – the Teredo and IP-HTTPS clients are also encapsulating all IPv6 traffic. But the same protections still apply regarding IPsec and DoSP.
I hope you find these answers helpful and would be happy to carry on the conversation in the comments section.
Tom Shinder email@example.com Principal Knowledge Engineer, Microsoft DAIP iX/Forefront iX UAG Direct Access/Anywhere Access Group (AAG) The “Edge Man” blog (DA all the time): 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
Hi Tom, thanks for sharing that info. Regarding NLS on the Domain Controller....what about dedicating a fourth NIC on that host (the DC) to the NLS, assign it's own IP and create a DNS record for it, then bind the NLS site to that IP/NIC? Would that address the concerns raised by the DirectAccess PM?
That's something I have done on CA servers but never tried it on a DC. Here's more details on the method - blog.concurrency.com/.../uag-directaccess-network-location-server-nls
Are you thinking of making the NLS a virtual machine on the host operating system (which is the DC)? If so, that would work fine. Also, I don't see a strong need to dedicate a NIC to the NLS VM - you can create an External Virtual Network (Hyper-V terminology) that is bound to the same NIC used for the DC's internal interface.
Thanks for your response, Tom. That is very helpful.
Regarding the NLS issue, what about putting it on the DirectAccess server itself (in my small deployment)? In this specific scenario (remote kiosks) I won't really have any clients locally connected, so I wonder if I even need a NLS at all? If necessary, I could always have a local test client that is not a member of the DA group and that would prevent it trying to establish a remote connection, right?
Also, can you direct me to any resources specific to setting up a native IPv6 DirectAccess solution? I think I'd like to go that route but I'm still fuzzy on the details as I haven't worked with IPv6 much before.
Finally, I hear what you are saying with the firewall only allowing 6to4 traffic and not all IPv6 traffic. I don't see there being any real issues now, but I guess I'm just wondering as more people start using IPv6 (and thus there is more 6to4 traffic out there) that relying on the DirectAccess server's software firewall/security policies might be problematic if there were unpatched vulnerabilities that could be exploited. I'd feel much safer in the long term if I could somehow run the IPv6 traffic through an IPv6 firewall to drop anything that wasn't specifically needed for a DirectAccess connection. Does that make sense?
RE: putting the NLS on the DirectAccess server, that might work. I don't think we've tested it, but I haven't heard anything about it not working or even not being supported - so that might worth a try.
blog.msedge.org.uk/.../path-to-directaccess-part-2-thinking.html has some useful information on using native IPv6. Thanks to Jason Jones for that!
The Windows IPsec is pretty rock solid - I don't think you have any significant secure concerns there. Remember, if the user *and* the machine can't authenticate, the connection is dropped. If I had to bet $100, I'd worry more about the firewall's potential security issues than any possible security issues with the Windows implementation of IPsec. Remember, if the IPsec tunnel can't be established, no IPv6 traffic is passed, since the IPv6 traffic is contained within the IPsec tunnel.
However, ICMP traffic is exempt from IPsec protection, and some people might have concerns about that - so if the IPsec tunnel establishment fails, ICMPv6 can enter the network after just establising a successful IPv6 transition technology connection. If you want to remedy this, check out social.technet.microsoft.com/.../directaccess-forcing-encryption-for-icmpv6-traffic.aspx
Hi Tom. I agree that making another VM to serve as the NLS is an option (and you're right, that would have no need for it's own nic), but I was just suggesting that you dedicate a NIC on the host to be used to bind the IIS site to. Alternatively, you could probably just define a secondary IP on the Host's NIC and bind that to avoid needing a physical NIC.
The point is that it would separate the IP address and DNS record of the DC from that of the NLS. In my blog post I cover the steps taken.
Regarding the NAT issue, while I am not going to be using it in my current project I'm very curious about the unsupported workaround of which you spoke. There may be some scenarios I deal with where public IPs on the DA server is just simply not an option, so if there is some magic that can allow something like a one-to-one or static NAT to work with DA I'd be very interested (even if it is unsupported).
Oh! OK, it makes sense. What the real goal is to assign another IP address that is used only by the NLS web site and not used by the DC for any other functions. Good idea and should get around the IPv6 issues.
I'm very tempted to put together a blog post on this and just put a big UNSUPPORTED on it - so that people can at least play around with the solution. I'll put together a Visio diagram of this and send it to you. Mind you, we haven't tested this, but theoretically it should work.
Hi Tom, can you clarify a couple points related to Certificate Authorities and CRLs? I plan on getting a commercial certificate for the IP-HTTPS listener as you recommended, but how does that affect all of the other certificate related configurations in the test lab guide? The CA created on the domain server is completely separate from this commercial certificate, right?
And you mentioned that you wouldn't want to host the CRL on the DirectAccess server in a production environment. Is this only because of performance reasons or because of something else? And is this CRL not related to the IP-HTTPS listener? So, just to make sure I'm getting it, there is one CA and a corresponding CRL for the active directory domain, and then another CA/CRL (in this case commercial) for the DirectAccess connections. Is that right?
I'll do a blog post tomorrow on these subjects as I think many people are interested in the same issues.