Active Directory-based authentication, access control and role-based privilege management for Windows, Linux & UNIX
Standard Edition + privileged user auditing
Enterprise Edition + encryption of data-in-motion and server isolation
Any Edition + single sign-on for SAP, Apache and J2EE/Java applications
Single sign-on for cloud apps + mobile device supportMac Edition
Active Directory-based authentication and Group Policy management for Macs + mobile device supportPremium Edition
SaaS and Mac Editions + mobile device supportCentrify for Samsung KNOX
Active Directory-based SSO, MCM and MDM for KNOX-enabled devices
Monday, March 1, 2010
It was three years ago that Bill Gates made his last appearance at the RSA Conference and introduced the Microsoft vision of "Secure Anywhere Access in a Connected World." It was 2 years later that part of that vision became reality with the introduction of technology in Windows 7 and Windows 2008 R2 called DirectAccess. In this blog post I will give an overview of DirectAccess and discuss how Centrify DirectSecure embraces and extends it to non-Microsoft platforms; i.e. even better together.
[Many thanks to our CTO Paul Moore for helping me on this blog post.]
DirectAccess is new technology in Windows 7 that gives a mobile user an 'always-on' connection to corporate resources. The user has the same network experience when docked at his desk and when using a WI-FI connection in a hotel; it all just works. For example, say I am in a hotel room and I start Outlook, it will automatically connect me to the Exchange Server; if a piece of mail I receive has a link to one of our internal web sites then clicking on it will automatically connect me to the web server.
DirectAccess works by taking advantage of several new features that Microsoft added in the new network stack introduced in Windows Server 2008 and Windows Vista and enhanced for Windows 7 and Windows Server 2008 R2. These include the ability to have the DNS client use different name servers for different domains, user level authentication in IPSec and a rich set of IPv4/IPv6 interoperation capabilities.
The DirectAccess Server runs on Windows Server 2008 R2 and the clients must be Windows 7. The backend systems can run Windows 2003 or Windows 2008; apart from the IPV6 requirements the DirectAccess setup is transparent to them.
One obvious question is how secure it is: the answer is 'very'. The computer that the user uses to connect must be an Active Directory ("AD") domain member and have a certificate issued by the domain. Secondly the user must be logged on to that computer using their domain user and password. Only if both these conditions are met will the DirectAccess server open a tunnel to the corporate network. The tunnel itself is protected via IPSec so that all data is encrypted (just like a normal VPN).
Notice also that the traffic works the other way too; management servers in the corporate network that need to connect to the user machine to perform housekeeping tasks can do so via DirectAccess even when the target machine is on the Internet.
DirectAccess also takes the IPsec deployment strategy called Server and Domain Isolation ("SDI") to the next level. It is seamlessly integrated into the DirectAccess setup experience; the admin just checks a box saying "yes I want end to end encryption of data." They can also choose to only allow certain machines access to those servers. This one wizard page replaces a very complex setup in older versions of Windows.
Where is this useful? Imagine I have a financial planning server and I want to ensure that all data flowing on the network to and from it is encrypted (even inside the corporate network , and I want to ensure that only a specific set of machine can access it: this is SDI. DirectAccess now allows that to work even though the permitted machines might be on the Internet; the data is always encrypted and only a specific set of machines may access the data.
[For more information, I found this article on the "10 things you need to know about DirectAccess" as providing a good introduction to DirectAccess.]
As you would expect DirectAccess works great with an all Windows environment; but what happens if the back end services are hosted on non Windows systems? The answer is that things don't work so well.
First, basic network connectivity. DirectAccess uses IPv6 extensively and so the corporate network must either be already running IPv6 (unlikely) or they must use an IPv4/v6 transition technology called ISATAP. ISATAP is transparent to the network itself but the hosts must support it and must be correctly configured.
Second, SDI. SDI is built on top of many Microsoft technologies, AD, Group Policy, Certificate server, etc. None of these are supported by non-Windows systems.
Centrify's DirectSecure product delivers both the ISATAP and SDI support to a heterogeneous DirectAccess deployment. By building on the AD infrastructure provided by our flagship DirectControl product we deliver a seamless Group Policy-driven implementation of all the necessary building blocks.
Microsoft's Forefront Unified Access Gateway (acquired with the purchase of Whale Communications) can be deployed with DirectAccess. It changes a few things but does not impact the value that Centrify brings. If a customer deploys the NAT64 feature of UAG then the need for ISATAP disappears. The SDI piece stays basically the same.
The bottom line is that Centrify's DirectSecure product enables DirectAccess to securely communicate with UNIX and Linux systems via end-to-end (versus just end-to-edge) IPsec authentication and encryption of network traffic.
So this means that Bill Gate's vision of "secure anywhere access" can now be extended to enterprise resources running on any platform (well ok, just the major modern UNIXes and Linuxes :-) via Centrify as well as more recent Windows OSes via Microsoft). In other words, even better together.