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

Hi Shannon,

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!

Tom

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?

Thanks Tom.

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).

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?

Thanks!