When you see demonstrations of DirectAccess, the bulk of the presentation always seems to be related to how cool and convenient it is for the users to connect to corporate network resources. Indeed, it is cool! The user doesn’t even need to log on to connect to the corpnet – all he has to do is start the computer. What can be better than that?
And when the user does log on, he has access to the network in the same fashion as a host directly connected to the corpnet either through an Ethernet jack or local WLAN. The DirectAccess client is a domain member and has all the rights and privileges as any other domain member on the network.
But that always brings up the issue of allowing remote computers to be domain members and providing them with the same level of access as internal domain members. After all, there is the argument that remote computers represent a different threat model than bolted in corpnet computers. I think this was more of a concern in the past, because now it seems like most users have a corporate issued laptop that they use at work, at home and on the road. The thick dividing line between the “bolted-in” corpnet client computer and the remote access computer isn’t that thick anymore.
This is where the management advantages of DirectAccess comes in. When a client connects via DirectAccess, that client is registered on the corporate network. That allows management agents on the DirectAccess clients to communicate with management servers so that they remain in compliance with corporate desktop standards. This works great when the agents initiate the connections, but what about when the management components on the network need to establish connections to the client?
This questions comes up because if the management systems are not IPv6 capable, the clients need to use NAT64 and DNS64 to connect to the DirectAccess client. If the client has to use a NAT connection to connect to the management server, that means the management server is on the non-NATed side of the connection. In this scenario, you would think that you’d need to create some kind of publishing rule (reverse NAT setting) to allow the non-NATed side of the connection to reach the client?
Is this true? Judge for yourself by checking out this post from Ben Bernstein over on the UAG team blog over at:
HTH,
Tom
Thomas W Shinder, M.D., MCSE
Sr. Consultant / Technical Writer
Prowess Consulting www.prowessconsulting.com
PROWESS CONSULTING | Microsoft Forefront Security Specialist
Email: [email protected]
MVP — Forefront Edge Security (ISA/TMG/IAG)