For me DirectAccess was a technical challenge including multiple technologies and involve multiple teams in a same project. I was involved in multiple DirectAccess deployments in witch customers choose DirectAccess for it’s user-experience focus rather than for the technical solution (until now none of the network teams I worked with is ready for a large IPv6 deployment ).
Customers witch experienced DirectAccess are satisfied of the solution. Some of them want more than the end-user experience. That’s why I start this series of DirectAccess post : The DirectAccess Challenge series. Many times customers asked me for additional configuration for their DirectAccess deployments. Most of the time, it’s simple and “by design”/built-in in the product itself or just require a little extra time. But for some customer requests, it’s a real challenge I had face to. Let’s start with our first DirectAccess challenge : Securing Access to a selected set of servers. This means mixing Direct Access and IPsec isolation.
From a high level point of view, that kind of architecture would look like that (I know, there is no back-end firewall, …). According to Microsoft technical documentation, architecture illustrated bellow is called “Selected Server Access” :
According to Microsoft TechNet, the Selected Server Access have multiple benefits and limitations :
Now let’s see if my knowledge and experience with DirectAccess allow me to to that. Until today, it’s not documented in TechNet but many of my customers were interested with that deployment scenario.
From the beginning, let’s start with the foundations. To make this as simple as possible, I will use a “simple” DirectAccess deployment based on a Forefront UAG 2010. This is the simplest deployment scenario to start with but also work for advanced DirectAccess based deployments using NLB of HLB. Before starting the configuration steps, let’s review the different IPsec implementation :
We have IPsec tunnels and IPsec transports. IPsec tunnels are designed to secure network traffic between two networks (from router to remote router) and protect both the Header (AH) and the payload (ESP). IPsec Transports are designed to secure network traffic between two computers and only protect the payload (ESP), not the header (AH). Remember that each time a router route network traffic headers information’s are updated.
Applied to a DirectAccess deployment we have the infrastructure and user IPsec tunnels and the Application IPsec transport. In this scenario we will keep the standard IPSEC tunnels (Infrastructure and Application) and setup a new IPSEC transport to secure a specific server.
Note : Technically, it is possible to use the Selected Server access model as foundation but for a reason I did not find, computer group membership filtering will not work.
For this scenario, we need a standard UAG DirectAccess deployment including the following considerations for the secured servers :
- Operating system must be Windows 2008 or Windows 2008 R2 to support IPv6 (ISATAP more precisely)
- Windows 2008 R2 will be required is you choose IPsec peer authentication without traffic protection
- Server must be able to reach the ISATAP router (the UAG box) to get the ISATAP prefix
- Server must be domain member
The challenge for this deployment is to be able to initiate a secure communication from a DirectAccess enabled computers located on Internet with a secured server located on company internal network. Access to the server will be filtered based on computer and user group membership for a specific protocol (RDP in my demonstration). Let’s start our IPsec inception (IPsec transport inside IPsec tunnels).
Our IPsec inception scenario start with the client-side configuration on a standard DirectAccess enabled Windows 7 client. IPsec transport must be configured only for a specific IPv6 destination located on my LAN. My SECURE server ISATAP address is 2002:836B:2:8000:0:5EFE:192.168.0.111.
Technically speaking, it is possible to build this connection security rule in a GPO but I will build it locally for a better understanding. I need a transport IPsec rule. According to the wizard, the first type of connection security rule should be fine :
Even if this IPsec transport will reach my secure server through an IPsec tunnel (inception), this is not a reason to do not enforce authentication whoever initiate the communication. In my scenario, it is always DirectAccess enabled laptops that need to reach my secure server.
Authentication means protocols. IPsec negotiation rely on the Authenticated IP protocol witch is an extension of IKEv1. Because I need to authenticated both the computer and the user I choose the “Computer and user (Kerberos v5)” choice.
My new connection security rule should only be used when DirectAccess is enabled, so only for the public and private firewall profiles.
At last, I will name my new rule “SECURE ZONE”.
We have the foundations of our IPsec transport, but it’s not specific to my SECURE server. We need to add a condition based to my destination : the ISATAP address of my SECURE server.
This is the end for the client-side configuration. Our new connection security rule will establish an IPsec transport to reach my SECURE server only if DirectAccess is enabled, whatever my local IP address (Teredo, IPHTTPS, …).
On the server-side configuration, we will use the same wizard and start with the same choices : Isolation.
Authentication will be required for both inbound and outbound connections. If my server is supposed to be secure it is a logic choice.
Just like on the client-side configuration we will chose the “Computer and user (Kerberos V5)” choice. Note that you can use the advanced authentication method to define your primary and secondary authentication method. This could be a good idea to enforce the use of a System Health Authentication certificate for the client. Accessing secured zone require your computer to prove it’s security level before (NAP is good for you!) .
Because my SECURE server is located on my internal network, my new connection security rule should be applied only to domain profile interfaces.
My new connection security rule will be named “SECURE ZONE”, just like on the client-side.
Now the fun begin. How to be sure that my server will apply this connection security rule only for DirectAccess enabled clients located on Internet. Simple, if they operate in DirectAccess they use IPv6 transition protocols such as Teredo and IP-HTTPS (I no longer recommend using 6to4 in DirectAccess deployments and this protocol is no longer use in Windows 8). So I need one filter for IP-HTTPS connections with a 56 mask (work for single-node up to eight-node UAG array farm) and a Teredo filter :
But I also need to be sure that my connection security rule only apply to the ISATAP address of my SECURE computer and not my server remote administration interface. For this reason, I add my ISATAP address in the Endpoint1 zone.
That’s the end for the tunnel. At this point, you can try to establish a connection with the SECURE server, you will have an IPSEC association established but no filtering capabilities, that’s for the next part.
Connection security rule configuration on the server-side end with ICMP exception management. We need to reconfigure IPsec exception at SECURE server level to ensure that IPsec traffic is not included in our IPsec transport.
This is an important point because otherwise you wont be able to ping the SECURE server from a DirectAccess client and DirectAccess clients using Teredo protocols will be blocked (ICMPv6 messages are used in Teredo for signaling usages).
Secure one protocol
Here things become tricky. In this scenario we are working with IPsec transports. This means we cannot filter who use at tunnel negotiation (we need an IPsec tunnel for that). Because of this limitation, filtering must be performed on my SECURE server at inbound Rules level. In my example we will secure RDP protocol usage.
By default, Windows Firewall include all standard protocols to be used. So we will find an incoming rule for Remote Desktop protocol. We will reconfigure this protocol definition to require a secured connection to use this protocol. Our IPsec transport will be our secured connections.
We will keep the standard choice. My connection must be authenticated and it’s integrity-protected. An interesting choice would be the ‘”Null encapsulation” that only protect the payload (ESP) buts it’s only available since Windows 7 and Windows 2008 R2.
Enabling the “Allow connection if it is secure” unlock the “Computer” tab of the protocol definition. Authentication information’s provided by the DirectAccess client during IPsec negotiation can be used to allow/deny connections based on computer group membership. In illustration bellow, I consider that I have a security group that permit usage of the RDP protocol from a group a clients computers and a group to deny usage. That’s an interesting scenario to limit remote administration capabilities with DirectAccess to a selected group inside DirectAccess clients.
We can apply the same filtering approach for users. Only a selected group of users will be able to use the RDP protocol on a selected set of DirectAccess enabled computers.
By now the RDP protocol on my SECURE server is secured because :
- Access to the RDP server requires IPsec infrastructure and user tunnels negotiation prior accessing the SECURE server (IPsec inception).
- RDP access to the SECURE server is limited to a subset of the DirectAccess-enabled computers
- RDP access to the SECURE server is only possible for a limited subset of users of DirectAccess-enabled computers
First, this scenario should be supported by Microsoft because no change is performed on the default configuration. We just add new connection security rules .
The most visible limitation is that each protocol must be reconfigured. In my opinion, only application level protocols should be reconfigured. Standard protocols such as RPC must remain accessible without enabling an IPSEC transport with the server.
And at last, clients located on LAN wont be able to access the SECURE server for the secured protocols because our connection security rule configured on the server filter only Teredo and IP-HTTPS access. An easy workaround for this limitation would be to create additional security rules for domain based profiles only. If a server is considered as sensitive for external access, it should be the same for internal access.
BenoitS – Simple and Secure but business compliant