A Short Introduction to UAG DirectAccess End to End Security

I’m thinking of putting together a Test Lab Guide module for configuring end-to-end security for UAG DirectAccess clients and selected application servers on the intranet, so I configured the scenario in the Test Lab to see how it worked. I figured that since everything is working in the Test Lab now, I should take some time to share with you what end-to-end security looks like when you configure it using the UAG DirectAccess wizard.

If you want to follow along with what I’m describing in this blog post, you can fire up your UAG DirectAccess lab if you have a snapshot handy. If you haven’t completed the UAG DirectAccess lab yet, then you might want to download the Test Lab Guide: Demonstrate UAG DirectAccess (https://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=c243c30c-6476-4061-9520-124710dbdd27)and you can get a snapshot saved. Then you can see how the same things I describe in this blog post in your own Test Lab.

Before I go into the details, it’s worth going over some basic UAG DirectAccess concepts. UAG DirectAccess supports two types of network security access models:

• End-to-edge. End-to-edge security refers to the IPsec connections between the DirectAccess clients and servers. Both the intranet and infrastructure tunnels are encrypted using AES-CBC 128 bit encryption. This is configurable if you want a higher bit level.
• End-to-end. In UAG DirectAccess scenarios, end-to-end security refers to connections between DirectAccess clients and destination servers on the intranet. In contrast to the IPsec tunnel mode connections between the UAG DirectAccess server and the DirectAccess clients, end-to-end security uses IPsec transport mode to secure the connection from end to end with AES-CBC encryption. You have the option to use ESP null encryption, or even null encapsulation, if you need to make the packets available to IDS devices on the intranet.

Note that ESP null encapsulation is different than (ESP)-NULL. With null encapsulation only the first packet of the connection is authenticated, so that the remainder of the communications are available to the IDS for inspection. For more information on this subject, see https://technet.microsoft.com/en-us/library/ee382325(WS.10).aspx

Also, if you want to do end-to-end security, the server on the intranet needs to be IPv6 capable, which means it has a native IPv6 address or an ISATAP address. This essentially limits your servers to being Windows Server 2008 and above, although there products available that you can use to enable non-Microsoft servers to participate end-to-end IPsec security, but I won’t go into those methods today.

On the UAG DirectAccess Server

If you want to enable end-to-end security, you’ll need to assign the intranet servers to groups that can be used by the object-picker used in the UAG management console. You can use existing groups if you like, but in most cases you’re probably better off creating your own groups for this purpose. The figure below shows that I’ve created a group called AppServers and I’ve added the APP1 computer account to that group.

Figure 1

Open the UAG management console on the UAG DirectAccess server after you create the group. In the UAG Management console, click the Configure or Edit button in the Application Servers section (it will say Edit if you’ve already configured DirectAccess, and it will say Configure if this is the first time you’ve configured DirectAccess).

Figure 2

On the Application Server Configuration page you’re given the option to Require end-to-edge authentication and encryption and Require end-to-end authentication and encryption to specified application servers. These “options” aren’t really options, as you must always have end-to-edge encryption and authentication. Remember, end-to-edge security represents the security delivered by the IPsec tunnels between the DirectAccess client and UAG DirectAccess server.

However, the Require end-to-end authentication and encryption to specified application servers option is an option. If you want to require end-to-end security between the DirectAccess client and the server on the intranet, you will need to select this option and then click Add to add the groups that contain the computer accounts of the servers that you want end-to-end security enforced.

Figure 3

Notice in Figure 3 that there is a link for Edit IPsec cryptography settings. You might run into some issues using that link if you’re using UAG RTM, so if you want to change the Quick Mode settings, it’s best to do it in the Group Policy Object that’s created for the Application Server connections. However, it should work fine with UAG Update 1 and above. Make sure to confirm. If you don’t use Update 1 (which shouldn’t be the case since you should always install it, but we didn’t have Update 1 available when the Test Lab Guide was written.) You can see where this is done in Figure 4. I won’t go into the details on how to do this, but if you are already comfortable with IPsec configuration, it’s relatively easy. However, each time you redeploy the UAG Group Policy settings when using the UAG DirectAccess wizard, you should confirm that your custom changes have been retained; you may need to reconfigure them.

Note that the name for the Application Servers Group Policy Object is:

Figure 4

(UAG DirectAccess: AppServer{f7b77f47-7c33-4d8c-bb9a-a913c5675d8d}

Figure 5

DirectAccess Client

After you make the changes in the UAG DirectAccess wizard in the UAG management console, you need to deploy the settings. After the GPO settings are deployed, make sure you refresh Group Policy on the Application Servers and the DirectAccess clients so that they receive the new Connection Security Rules. You can use gpupdate /force to do this in the Test Lab.

After Group Policy is refreshed, you can go to a DirectAccess client and open the Windows Firewall with Advanced Security console and check the Connection Security Rules. You will see a new Connection Security Rule named UAG DirectAccess Client – Clients E2E Authentication.

Figure 6

If you double click on the rule you’ll see on the General tab the description that explains that the policy is to enable secure corporate resources over IPsec.

Figure 7

On the Computers tab, you see in the Endpoint 2 section that the rule is applied when the DirectAccess client connects to the IPv6 address of the secure server on the intranet. This is why end-to-end security only works when the DirectAccess client connects to IPv6 capable hosts – the Connection Security Rule needs to use the IPv6 address of the secure server on the intranet. In the example in Figure 8, that address is assigned to APP1.

Figure 8

When you click on the Protocols and Ports tab, you can see that the rule applies to all protocols, as seen in Figure 9.

Figure 9

Click on the Authentication tab. Note that the authentication mode is to Require inbound and outbound authentication. Click the Customize button.

Figure 10

This brings up the Customize Advanced Authentication Methods dialog box (Figure 11). Remember, you can’t change anything here because these settings are managed via Group Policy, but you can see what the Group Policy controlled settings are. Both Computer certificate and user Kerberos authentication is required to establish the secure IPsec connection between the DirectAccess client and secure server on the intranet.

Figure 11

Click on the Advanced tab (Figure 12) and you’ll see that this rule is active only for the Private and Public profiles. This is important because you want these settings to apply only when the DirectAccess client is acting as a DirectAccess client; that is to say, when the DirectAccess client is off the intranet. When the DirectAccess client is on the intranet, you don’t want this Connection Security Rule to activate. The reason for this is that you might have other Connection Security Rules and IPsec policies that you want your intranet clients to use, perhaps as part of your Server and Domain Isolation configuration.

Figure 12

After you establish a connection to the secure server (I did a net view \\APP1 in this example), click the Monitoring\Security Associations\Main Mode node and expand the Remote Address column. There you will see a Main Mode SA with APP1 to its IPv6 ISATAP address, using both Computer Certificate and User (Kerberos V5) authentication, as seen in Figure 13.

Figure 13

Double click on the Main Mode SA to the secure server on the intranet and you can be more details. As you can see in Figure 14, the name of the user is listed, as well as the encryption and integration methods used by the connection.

Figure 14

Similarly, if you click on the Quick Mode node in the left pane of the console, you’ll see the Quick Mode SA established with APP1 on the intranet. Here you can see the local and remote address, and the integrity and encryption methods used for the connection, as seen in figure 15.

Figure 15

Intranet Server

Now that we’ve seen what things look like on the DirectAccess client, let’s move our attention to the secure server on the intranet. If you’re following along with the Test Lab Guide, open the Windows Firewall with Advanced Security console on APP1 and click on the Connection Security Rules node in the left pane of the console. Here you’ll see that there are two new rules: UAG DirectAccess AppServer – Clients E2E Authentication and UAG DirectAccess AppServer – HTTPS Clients E2E Authentication, as you can see in figure 16.

Figure 16

Why are there two Connection Security Rules? To get a clue, double click on the UAG DirectAccess AppServer – Clients E2E Authentication rule and click on the Computers tab (figure 17). Here you can see that Endpoint 1 has two IP address ranges. One of the ranges reflects the addresses that are assigned to Teredo DirectAccess clients and the other is for 6to4 DirectAccess clients. Endpoint 2 represents the secure server on the intranet, so no IP address needs to be assigned there.

Figure 17

Click on the Advanced tab (figure 18). Notice that the Connection Security Rule is assigned to the Domain profile. The reason for this is that the secure server on the intranet isn’t going to be moving anywhere, so there’s no reason to have the rule apply to Private or Public Profiles.

Figure 18

Now let’s take a look at the other Connection Security Rule, UAG DirectAccess AppServer – HTTPS Clients E2E Authentication. Double click on that rule and click on the Computers tab. Notice the address range for Endpoint 1. If you’re been working with DirectAccess for a while, you might recognize this IPv6 address range. If not, this range represents the DirectAccess clients that are using IP-HTTPS to connect to the UAG DirectAccess server.

Figure 19

Summary

In the article we took a short look at some of what you’ll see when configuring end-to-end security between the DirectAccess client on the Internet and a server on the intranet. In contrast to IPsec tunnel mode that is used to connect the DirectAccess client to the UAG DirectAccess server, the DirectAccess client uses IPsec transport mode to connect to the secure server on the intranet. When you configure end-to-end security, the UAG DirectAccess wizard will create new Connection Security Rule that are applied to the DirectAccess clients and secure servers on the intranet. You can use the Windows Firewall with Advanced Security console to see the Connection Security Rules and the status of the IPsec connections.

This article is just an short introduction to end-to-end security. I plan to put together a Test Lab Guide on configuring UAG DirectAccess with end-to-end security, so keep your eyes open for it! See you soon –Tom.

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Microsoft DAIP iX/SCD iX
UAG Direct Access/Anywhere Access Group (AAG)
The “Edge Man” blog (DA all the time): https://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: https://twitter.com/tshinder
Facebook: https://www.facebook.com/tshinder