You might have noticed that the Edge Man has been absent for a while (at least I hope you’ve noticed). The reason for my absence is that I was doing some interesting work on the upcoming UAG Service Pack 1 over in the Israel Development Center (ILDC). And I have some great news for you! UAG Service Pack 1 is going to include a number of new features and capabilities that you’ve been asking for.
I tested most of these new features and found that the new user interface was cleaner and more intuitive than what we have now, which is really going to help the new UAG DirectAccess administrator. Even better, everything I tested worked!
While I can’t tell you the schedule for the release of the Service Pack at this time, you should be seeing a release candidate of UAG Service Pack 1 sometime in the next couple of months. I really hope you all get a chance to play with UAG SP1 in your own test labs, as I’m sure you are really going to like the new options we’ve exposed to you that will make it easier than ever to get a working DirectAccess configuration and deployment that meets your organization’s requirements.
Some more good news – I plan to release some updates to the UAG DirectAccess Test Lab Guides (TLGs) at the same time that the RC of the Service Pack is released. I consider this to be very important as a working TLG is the best way for you to get quickly up to speed on a new product or technology. If you haven’t seen the TLGs we already have, then check them out on the TechNet wiki over at http://social.technet.microsoft.com/wiki/contents/articles/test-lab-guides.aspx
If you haven’t got into the TLG swing of things yet, and you think you’ll want to check out UAG SP1 in a lab – then I recommend you prepare for it by building out the Base Configuration. Once you have the Base Configuration in place, putting together the UAG SP1 RC test lab will be a no brainer!
Check out the Base Configuration Test Lab Guide over at:
http://go.microsoft.com/fwlink/?LinkId=198140
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): http://blogs.technet.com/tomshinder/default.aspx Follow me on Twitter: http://twitter.com/tshinder Facebook: http://www.facebook.com/tshinder
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 (http://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:
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 http://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.
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
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
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
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.