Archive for the ‘DirectAccess’ Category

Connecting DirectAccess Clients to SAP

December 8th, 2010 Comments off

When a DirectAccess client computer is on the Internet, it connects to the corporate network using DirectAccess. All communications between the DirectAccess client and DirectAccess server are done over IPv6 (encapsulated by an IPv4 tunnel to carry the IPv6 traffic over the IPv4 Internet). In fact, the client application assumes that the connection is IPv6 from end-to-end, even when the destination server on the intranet is an IPv4-only capable resource. UAG DirectAccess can enable IPv4 connectivity to an intranet resource by using its NAT64/DNS64 IPv6/IPv4 protocol translation feature, which allows the UAG DirectAccess server to map an IPv6 address associated with the IPv4 address of the intranet resource. This mapped IPv6 address is used by the DirectAccess client to connect to the IPv4 resource on the intranet. The UAG DirectAccess server will translate this to an IPv4 address and forward the connection to the desired IPv4-only resource on the intranet.

While NAT64/DNS64 solves the problem of IPv4-only capable systems on the intranet, the client side application on the DirectAccess client must be IPv6 capable. If the client-side application is not IPv6 capable, it must use a non-DirectAccess method to reach the application server, such as an Internet accessible application gateway.

In the context of connectivity to SAP resources, you had to use an alternate method outside the DirectAccess tunnels before the release of SAP GUI version 7.1. With the introduction of SAP GUI 7.1, the DirectAccess client can connect to SAP resources on the intranet over the DirectAccess tunnels. However, to get this to work, you need to set a specific environment variable, which we will discuss later in this post. This solves the IPv6 problem on the client side.

If the SAP server is not IPv6 capable (meaning that it isn’t using ISATAP or native IPv6 addressing), then the UAG DirectAccess server’s NAT64/DNS64 feature will be used for IPv6/IPv4 protocol translation. While this will allow access to a SAP server, it will break SAP load balancing. The end result is that if you don’t need SAP load balancing, then all you need is to do is set the environment variable on the SAP GUI client and connectivity will work over DirectAccess because NAT64/DNS64 will take care of the protocol translation for you.

Solving the Load Balancing Problem

However, if you need load balancing for your SAP servers, NAT64/DNS64 isn’t going to do all the work. In this case you’re going to need to bring in another component, called a SAPRouter.

A SAProuter is a non-transparent gateway that can accept both IPv4 and IPv6 connections and do protocol translation between IPv4 and IPv6. NAT64/DNS64 are not used. Instead, the DirectAccess client connects to the SAPRouter using the SAPRouter’s IPv6 address, and then the SAPRouter can route  the connections to the IPv4-only SAP servers behind the SAPRouter. At this point the SAP servers are able to load balance the connections and also return the responses to the SAPRouter, which is then able to return the responses to the DirectAccess clients through the UAG DirectAccess server.

Figure 1 illustrates the request/response path between the DirectAccess client and the SAP resource servers (note that the load balancing component of the SAP servers is called out to make the path easier to understand).

Figure 1

  1. The DirectAccess client sends a request to the IPv6 address of the SAPRouter to gain access to the SAP CRM resource on the intranet.
  2. The UAG DirectAccess server forwards the connection request to the IPv6 address of the SAPRouter.
  3. The SAPRouter forwards the connection to the IPv4 address of the SAP server load balancer.
  4. The SAP server load balancer forwards the request to the IPv4 address of the SAP CRM resource server.
  5. The SAP CRM returns a response to the IPv4 address of the SAP server load balancer.
  6. The SAP server returns the response to the IPv4 address on the SAPRouter.
  7. The SAPRouter returns the response to the IPv6 address of the UAG DirectAccess server.
  8. The UAG DirectAccess server returns the response to the IPv6 address of the DirectAccess client.

Configuring the SAPGUI 7.1 Client

The following are instructions should configure the SAP GUI 7.1 client to work with DirectAccess:

  1. Start SAP Logon.
  2. Click the button ‘New Item‘.
  3. Click the button ‘Next
  4. In the window "Create New System Entry" choose the connection type "Custom Application Server".
    Add the following into the dialog:
    Field "Description"                  > A description
    Field "Application Server"    > enter the hostname of the SAP Application Server
    Field "System Number"         > The number of the instance
    Field "System ID"                      > The System ID

If you are using a saprouter you would have to add an entry in the field "SAProuter String", for example "/H/saprouterxy".


  • If you don’t need load balancing for your SAP CRM resources, then all you need to do is configure the SAP GUI 7.1 client
  • If you need load balancing for your SAP CRM resources, then you will need to introduce a SAPRouter
  • The SAPRouter can translate IPv4 to IPv6 and back so that the DirectAccess client can be configured with the IPv6 address of the SAPRouter

If you have further questions regarding this issue, please write to the address in the sig line below.


Noam Ben-Yochanan, Senior Program Manager, DA

Tom Shinder
Knowledge Engineer, Microsoft DAIP iX/Forefront iX 
UAG Direct Access/Anywhere Access Group (AAG)
The “Edge Man” blog (DA all the time):
Follow me on Twitter:

Categories: DirectAccess, SAP, SAP GUI, SAPGUI, SAPRouter, UAG Tags:

UAG DirectAccess and the Windows Firewall with Advanced Security – Things You Should Know

December 1st, 2010 Comments off

Both the Windows DirectAccess and the UAG DirectAccess solutions are heavily dependent on the Windows Firewall with Advanced Security. DirectAccess clients take advantage of both firewall rules and Connection Security Rules. Connection Security Rules are IPsec rules that control the IPsec tunnel mode connections between the DirectAccess clients and the DirectAccess server. In addition to the IPsec tunnel mode connections, Connection Security Rules are used to enable IPsec transport mode connections for servers for which you want the DirectAccess clients to connect using end-to-end security.

In order to get the most out of DirectAccess and how DirectAccess works, it helps to have a better understanding of the different components of the Windows Firewall with Advanced Security and how some of the important settings work and how they interact with DirectAccess

Windows Firewall Profiles – Public Profile, Private Profile and Domain Profile

Windows Firewall offers three firewall profiles: domain, private and public. The domain profile applies to networks where the host system can authenticate to a domain controller. The private profile is a user-assigned profile and is used to designate private or home networks. Lastly, the default profile is the public profile, which is used to designate public networks such as Wi-Fi hotspots at coffee shops, airports, and other locations.

Different firewall and connection security rules can be configured for each profile. There are default settings that are applied to each profile, but the administrator can customize their default settings.

What Does This Have to Do with DirectAccess?

The different profiles are important because a computer only works as a DirectAccess client when it is not on the corporate network. In order words, if the DirectAccess client detects that it can connect to its domain controller and is on the corporate network, it will use the domain profile. The DirectAccess client will only act as a DirectAccess client when the Private or Public Profiles are enabled. The reason for this is that the Connection Security Rules that enable the IPsec tunnel mode connections to the DirectAccess server are included only in the Public or Private Profiles. There are no Connection Security Rules that enable IPsec tunnel mode connections to the DirectAccess server in the Domain Profile.

The UAG DirectAccess server (as well as the Windows DirectAccess server) will create the Connection Security Rules that allow for the creation of the DirectAccess IPsec tunnels (and the end-to-end IPsec transport mode connections for servers configured for end-to-end security). However, the UAG DirectAccess wizard does not import any firewall rules that you might have configured to work on the corporate network. Those rules that you created for the intranet hosts were created for the Domain Profile. If you want your Domain Profile firewall rules to apply to DirectAccess clients, you will need to enable those rules on the Public Profile and Private Profile too.

How Do I Create Firewall Rules for DirectAccess Clients?

In order for intranet computers to connect to DirectAccess clients, there need to be firewall rules in place on the DirectAccess clients that allow the incoming connections from the intranet servers. In addition, if you are blocking outbound connections, you may need to create rules that enable required protocols outbound. There are several things you need to know about these firewall rules:clip_image001

  • Teredo clients need to have the Edge Traversal setting enabled on inbound firewall rules that allow the intranet clients to connect to DirectAccess clients that are using Teredo to connect to the DirectAccess server (
  • Teredo clients must have also have rules that allow them ICMPv6 access to intranet clients, such as ICMPv6 neighbor discovery. This rule is enabled by default and you should not delete it. In addition, Teredo clients require ICMPv6 Echo Request access to your intranet if you are using ISATAP or native IPv6 on the intranet. If you are using NAT64/DNS64, then you need to enable ICMPv4 Echo Requests to your intranet (
  • With reference to the second bullet point, you should be aware of a scenario where domain policy doesn’t allow firewall rules to merge with local policy. While the required rule is enabled by default in local policy, if your organization disables merging local with domain policy, then only rules created for domain policy will be applied to the DirectAccess client, which will cause this rule to be disabled. If this is the case, you should manually create all of the required infrastructure rules, such as those required for IP-HTTPS, Teredo, 6to4, ESP, IKE and ICMPv6.
  • DirectAccess clients using 6to4 and IP-HTTPS to connect to the UAG DirectAccess server don’t require the Edge Traversal setting to allow for remote management. However, since you can’t predict which IPv6 transition protocol will be used by the DirectAccess client, you should always enable Edge Traversal on the firewall rules.
  • The firewall rules that enable intranet hosts to connect to the DirectAccess clients should be applied to the Public and Private profiles. You can apply them to the domain profile if you like, but in order for the computer that is acting as a DirectAccess client to apply these rules, they must be enabled on the Public and Private Profiles.
  • When creating these firewall rules, make sure that one of the endpoints (can be the remote endpoint, it doesn’t matter) includes the IPv6 prefix of the intranet. Failing to configure this type of access control in the rule may create a security issue that allows anyone on the Internet to connect to the DirectAccess client using these protocols. You can find the ISATAP IPv6 prefix in the details of the intranet tunnel rule as Endpoint 2.
  • If you have firewall rules that you enable for intranet clients using the Domain profile, be aware that these are not automatically applied to the DirectAccess clients, since they will be using either the Public or Private profile. Therefore, if you want your domain firewall rules applied to DirectAccess clients, make sure to replicate them for your DirectAccess clients’ Public and Private profiles.

While it’s possible for you to create your firewall rules in the DirectAccess Clients GPO, that’s not a good idea because your rules will be overwritten the next time you use the UAG DirectAccess wizard and deploy updated GPO settings. Instead, create a new GPO with the firewall settings and apply it to your DirectAccess clients security group or OU.

For a very good tutorial on configuring firewall rules for DirectAccess client, check out How to enable Remote Desktop Sharing (RDS/RDP) from corporate machines to DirectAccess connected machine at

And if you want to try it out for yourself in your UAG DirectAccess Test Lab, check out Test Lab Guide: Demonstrate UAG DirectAccess Remote Management over at

Anything Else I Need to Know About DirectAccess Client Firewall Rules?

I’m glad you asked! Yes, there are a few more things you should think about when configuring firewall rules for DirectAccess clients. These are:

  • Don’t turn off the Windows Firewall on either the DirectAccess client or DirectAccess server. This will disable IPsec and Edge Traversal – so it essentially breaks all DirectAccess connectivity
  • Avoid allowing all inbound connections to the DirectAccess clients. Doing so will disable Edge Traversal. This breaks Teredo and manage-out.
  • Avoid blocking all outbound connections as well. If you block all outbound traffic, you will not only need to enable the infrastructure protocols, you will also need to allow any other protocol required by the DirectAccess client, such as HTTP, SMT, RDP, etc) on the Public and Private Profiles.
  • If your organization manages all of your firewall rules through a central GPO, you need to make sure that you enable the rules that are required for DirectAccess to work. These include rules to support IPv6 Transition Technologies, ICMPv6 (as mentioned previously) and ESP and AuthIP. However, you do not need to any rule to the UAG server, as the Firewall capability is disabled on the UAG and the TMG server is in control.


Yaniv Naor, SDE
Tom Shinder, Knowledge Engineer/Principal Technical Writer, Anywhere Access Group (AAG)

Supporting Business Continuity, Disaster Recovery and Multi-Site Scenarios with UAG 2010 RTM and UAG 2010 Service Pack 1

December 1st, 2010 Comments off

With the upcoming release of Unified Access Gateway 2010 (UAG) Service Pack 1, we decided it was important to discuss some important scenarios that many of our customers have asked us about. These scenarios are:

  • Business Continuity
  • Disaster Recovery
  • Multi-Geo (Multi-site) deployment

We believe that support for each of these scenarios is important for an enterprise ready solution. Business continuity and disaster recovery needs to be part of any solution designed to provide your users seamless and transparent connectivity to resources that give your firm a competitive advantage. In addition, support for multiple, geographically dispersed sites is also considered important in an era of international business can travel and we consider support for this scenario to be central in our near term goals for UAG.

While UAG Service Pack 1 (UAG SP1) can provide you basic support for business continuity, disaster recovery and multi-geo scenarios, we want you to know that we plan to address each of these scenarios with a post-UAG SP1 update and that work is already underway.

However, until we are able to deliver this update to you, we want to provide you some guidance for supported workarounds for these scenarios.

Business Continuity and Disaster Recovery

In the area of business continuity and disaster recovery we recommend that you create a “mirrored” installation of your UAG DirectAccess server or array. This can be a hot or cold standby that is configured with the same IP addresses as the production server or array. If the production array should fail, you can bring up the standby server or array and take advantage of ISP subnet redundancy so that traffic is routed to the backup deployment. When the primary UAG DirectAccess server or array comes back up, you take down the backup and route the traffic back through the original route.

Multiple Geographic Locations and Load Balancing Multiple Entry Points

There are two primary scenarios to consider when deploying UAG SP1 DirectAccess servers or arrays in multiple locations:

  • Your intranet resources are all IPv4
  • Your intranet resources are a mix of IPv4 and IPv6

Intranet Resources are all IPv4

If all your intranet resources are accessible only through IPv4 addresses (IPv4-only network), then you will take advantage of the UAG SP1 NAT64/DNS64 IPv6 to IPv4 protocol translator. In this scenario the source IP address of the incoming connections from DirectAccess clients is always an internal IP address on the UAG DirectAccess server or array. Your existing IPv4 routing infrastructure will be able to route these connections from the UAG DirectAccess server or array to the destination resource and responses back to the UAG DirectAccess server or array that the DirectAccess client is connected to. In this scenario you do not need to worry about IPv6 routing on the intranet.

You would install multiple UAG DirectAccess servers or arrays and apply the DirectAccess client and server settings by using different GPOs (which are specific to the particular UAG DirectAccess server or array)and assigning those GPOs to different OUs or security groups. If you are using a pre-SP1 deployment of UAG, you can use the methods discussed in the blog post to deploy the settings to different OUs. If you plan to deploy this scenario with UAG SP1, you can take advantage of the new GPO deployment features included in UAG SP1 which make custom deployment of GPOs to OUs or security groups available in the UAG DirectAccess wizard.

This method enables you to assign a fixed number of clients (based on the fixed number of computer accounts that belong to an OU or security group that you configure) to each UAG DirectAccess server or array. While this method allows for a static level of load balancing (DirectAccess clients can be split relatively evenly between servers or arrays), this approach does not allow users to change which array they connect to. This change requires that an administrator move the computer account to a different security group or OU.

Intranet Resources are IPv4 and IPv6

In this scenario, you would take advantage of the same distribution of DirectAccess clients are you would with an IPv4-only intranet – by assigning clients to a specific UAG DirectAccess server or array through the use of different GPOs or security groups. What changes in this scenario is how you handle the IPv6 routing requirements in a geographically distributed environment.

In this scenario you can configure a single ISATAP cloud and deploy multiple ISATAP routers that are on-link with the UAG DirectAccess server or array at each location. To make this work, you need to do the following:

  • Prevent DirectAccess clients from connecting to the UAG DirectAccess server or array using the 6to4 protocol. You can accomplish this by blocking IP Protocol 41 inbound through your edge firewalls.
  • Install an ISATAP router on the same link as the internal interface of the UAG DirectAccess server or array (that is to say, on the same physical or virtual segment).
  • Generate an IPv6 address space and assign both the ISATAP and UAG server or array addresses from this address space. You can find detailed instructions on how to generate an internal IPv6 address space and how to assign and use these IPv6 addresses on a UAG DirectAccess server or array in the blog post
  • Allocate a /64 ISATAP prefix for your entire intranet and use the same prefix for all your ISATAP routers.
  • On each of the ISATAP routers, add a specific /64 Teredo route, based on the Teredo address space that is generated by the UAG for that server’s or array’s clients.
  • On each of the ISATAP routers, add a specific /64 IP-HTTPS route based on the IP-HTTPS address space that is generated by UAG for that server’s or array’s clients.
  • Add a resource record for ISATAP for each ISATAP router. ISATAP hosts will receive all ISATAP resource records from the DNS server and will send router solicitation requests to each ISATAP server so that the ISATAP hosts are aware of all routes back to DirectAccess clients.

One other thing worth highlighting is the fact that the ISATAP Router needs to be configured with two IPv6 addresses:

  • The ISATAP address is used by the entire organization to reach the ISATAP router
  • The native IPv6 address is used on the ISATAP router to communicate with the UAG server

Figure 1 provides a high level overview of what this configuration looks like.


Figure 1 Workaround for an intranet with IPv6 ISATAP resources

Figure 1 shows that the ISATAP router in Asia is configured with routes for the Asia UAG Teredo and IP-HTTPS address space to the Asia UAG DirectAccess server. It also shows that the ISATAP router in the USA is configured with routes for the USA UAG Teredo and IP-HTTPS address space to the USA UAG DirectAccess server.

If you have some experience with IPv6 and ISATAP, the configuration should not be too difficult to accomplish. However, if you would like to see how this configuration works in a Test Lab, we plan to publish a Test Lab Guide – Test Lab Guide: Demonstrate UAG SP1 DirectAccess in a Multi-Site Configuration soon after the release of UAG SP1, which should help speed you understanding of the overall solution. For a list of current UAG Test Lab Guides, be sure to check out UAG DirectAccess Test Lab Guide Portal page at


Ben Bernstein, Senior Program Manager, DirectAccess
Tom Shinder (, Knowledge Engineer/Principal Technical Writer, Anywhere Access Group (AAG)

DirectAccess Policy Management – Have it your way!

November 22nd, 2010 Comments off

Forefront UAG 2010 makes extensive use of group policy objects for client provisioning, corporate servers, and the gateway itself. Customers familiar with this capability asked for more. More flexibility defining objects, and more control over their naming, placement and creation. Here are a couple of enhancements we’ve made in SP1 to meet these requests.

Organizational Units

Prior to SP1, you could define security groups that contained applicable end-users for DirectAccess. With the service pack are able to choose organizational units (OUs) instead.


Support Multiple Domains

In some scenarios the end-user’s machine is joined to a different domain than the one that user is authenticating against. For example, Bob is authenticating against CORPUSER domain while his machine belongs to domain CONTOSO. This scenario is now possible with UAG SP1, because you can define separate domains for clients’ computers and authentication.


Control Policy Names & Creation

Some customers use their own naming conventions for objects, so with SP1 you can not only change the name of the GPO, but also pre-create it, and let UAG fill in the designated containers. This can be useful when edge and GPO management responsibilities are handled by different administrators.


Categories: DirectAccess, UAG 2010 SP1 Tags:

UAG DirectAccess monitoring and troubleshooting in UAG 2010 SP1

November 10th, 2010 Comments off

After deploying your UAG DirectAccess environment, you need to ascertain that it’s up and running, and is providing the remote access as planned. There are a few things you’ll want to check:

  • Are all the relevant services up and running? Were there any failures?
  • Are there users currently connected to the system? Are they hitting any errors?
  • A user reports that he or she had trouble connecting yesterday evening – how can you know what happened?

Fortunately, the new DirectAccess logging and monitoring functionality provides answers to these questions. Starting from SP1, UAG supports out-of-the-box logging and monitoring functionality for DirectAccess user activity, based on the TMG SQL logging infrastructure.

What’s new in UAG DirectAccess logging & monitoring?

In SP1, we augmented the existing UAG monitoring tool (Web Monitor), with real-time DirectAccess monitoring information. Two new screens were added: DirectAccess Monitor – Current Status, and DirectAccess Monitor – Active Sessions.

DirectAccess Current Status screen displays a “SCOM-like” health indication of UAG DirectAccess servers and relevant DirectAccess sub-components. On this screen, you can see whether the UAG DirectAccess servers in your deployment are configured for DirectAccess, and that all relevant sub-components (DNS64, IP-HTTPS, etc.) are up and running. Everything is presented at the array level so that the admin can access all the information from the console of any array node.


Figure 1: DirectAccess server health status screen

DirectAccess Active sessions screen presents the list of DirectAccess sessions currently connected via all UAG DirectAccess array nodes. You can see a list of currently logged on users, access level (infrastructure or intranet), NAP health status, machine account, user account, and other fields.


Figure 2: DirectAccess active sessions

Web Monitor is useful for monitoring the current state of your DirectAccess deployment. In order to search across DirectAccess sessions that occurred in the past, you can use either the user monitoring PowerShell snap-in or the TMG SQL log viewer. The user monitoring PowerShell snap-in now presents the user and server monitoring information at the array-level, without enabling the Security Auditing event logs.


Figure 3: TMG log viewer displaying DirectAccess events

How does it work?

At the beginning of a DirectAccess session, the DirectAccess client and UAG DirectAccess server establish security associations (SAs). This is a security agreement with which both computers agree on how to exchange and protect information transferred during the DirectAccess session. You can see the configured and currently opened SAs on the “Windows Firewall with Advanced Security” screen.

The UAG DirectAccess logging mechanism monitors the currently opened SAs, and uses the SA info to log and monitor DirectAccess user activity. Changes in session state are written to the SQL log for persistency. Errors encountered during the session (e.g., “a smartcard wasn’t provided”) are also monitored and written to the SQL log. In this way the logging mechanism collects and stores information about DirectAccess sessions that can be subsequently viewed on the Web Monitor DirectAccess Active Sessions screen, or via the PowerShell snap-in or TMG log viewer.

What else?

What happened to DirectAccess user monitoring mechanism supported in earlier UAG releases? What is the difference between the new mechanism and the old one?

The DirectAccess user monitoring mechanism supported in Forefront UAG 2010 RTM (TechNet article here) was based on IPSec logging messages printed to the Security event log. The new SP1 implementation doesn’t require IPSec logging to be enabled, but rather collects the required SA information programmatically. The PowerShell snap-in was re-designed to work over the new infrastructure for both current and historic sessions. The snap-in was also augmented to include server health info.

How do I enable the new DirectAccess logging and monitoring feature?

DirectAccess logging and monitoring functionality is on by default. It collects DirectAccess events from the moment DirectAccess is configured and running on a UAG SP1 machine. Note that SQL logging is mandatory for DirectAccess monitoring functionality, so make sure it’s not disabled on your system.

Where can I find more info on this feature?

See for more info on UAG DirectAccess logging and monitoring, including information on the different PowerShell snap-in parameters.


We appreciate your feedback: please post comments for any questions you have, or for issues you might encounter with the new DirectAccess monitoring mechanism.

Categories: DirectAccess, UAG 2010 SP1 Tags:

UAG 2010 SP1: The New and Improved DirectAccess Features

October 27th, 2010 Comments off

We received some great feedback from customers about deploying DirectAccess in their organizations. One notable quote was “it works like magic!” Our customers also told us how we can make the product better by adding features and making existing features easier to manage.

After discussions and prioritization we are now proud to present the DirectAccess enhancements in service pack 1:

  • One-time-password support including: Integrated RSA SecurID agent and support for other 3rd party RADIUS based OTP products
  • Added optional settings in each step for advanced deployment scenarios
  • Support for deploying DirectAccess Group Policy across multiple domains, and pre-created GPOs
  • Support for the “I only want to manage my computers” scenario using integrated UAG UI
  • Support for Force Tunneling scenario using integrated UAG UI
  • Integrated NAP for simplified endpoint policy enforcement with simple “for dummies” setup of NAP+DA and integrated NAP troubleshooting tools included in Web Monitor
  • Improved monitoring and troubleshooting


One Time Password Integration

We’ve been hearing this request a lot from customers and potential customers – so we’ve gone ahead and did it.

Server side

On the server side UAG now provides a choice between smartcards and OTP. We did this by adding support for OTP in the UAG UI as part of the UAG DA Wizard’s optional settings. UAG comes out-of-the-box with an RSA SecureID agent so you can be up and running in no time if you have SecurID tokens.


Figure 1: UAG DA UI with OTP

You can use OTP solutions from other 3rd party vendors as long as they are RADIUS based (OATH compliant).

Client side

On the client side the users are given the same experience and look & feel as the smartcard authentication “pop-up”. Our implementation is not based on credential provider so that requiring OTP for authentication in the UAG DA server UI does not enable the user to login to Windows on the client using an OTP token.


Figure 2: OTP authentication balloon


Figure 3: OTP authentication popup


When deploying OTP you need to set up a dedicated Certificate Authority server (CA) and cannot use an existing CA. UAG makes life easier by generating a script which you can apply on the dedicated CA for use with OTP instead of performing CA configuration manually. Another bonus is that you do not need to make changes to the existing RSA ACE servers.


NAP Integration

NAP setup

NAP integration in UAG 2010 seemed easy enough. All you had to do was select a checkbox and NAP was enforced. In reality, there is more to it than that. Someone needs to install and configure an NPS, HRAs and CAs. This is not a simple task. In SP1 we decided to ask a few more questions, but have UAG do the bulk of the work for you. We did this by installing and configuring NAP roles on the UAG server, and by adding the NAP settings to the client GPO. You still need to set up a dedicated CA server and health template, and point to them in the UAG UI.

In the wizard you can choose between enforcing and monitoring health. If you select to enforce, client machines cannot create the second (intranet) tunnel until they can obtain a health certificate. Monitor only, on the other hand, will make sure that client health is checked and reported, but unhealthy clients will not be blocked.

NAP client health troubleshooting

Another non-trivial task that administrators face when using NAP is trying to understand why a particular client machine is considered unhealthy. Although the data exists, it is buried in the Windows EventLog and the actual events are not very clear. We’ve decided to add NAP troubleshooting to the UAG DA UI, specifically to the Web Monitor. You can query the last event for a specific machine, the last five events, or all of the events in a range of dates.

Existing NAP infrastructure

If you already have a NAP infrastructure or just want to have separate NAP and UAG servers, you can select not to use the internal NAP server, no questions asked. You then have to:

  • Setup the NPS, HRA and CA server
  • Create your own client GPO to turn on NAP client settings
  • Use Event Viewer on your NPS server to troubleshoot client health problems
  • Replicate the NPS configuration if you have more than one deployed

Integrated Multi Domain Support

Many of our customers have more than one domain. We have added support for managing DirectAccess in a multi domain deployment.

Using the UAG DirectAccess UI you can specify which domains the DirectAccess GPOs will be applied to. You can also specify which GPO the UAG will use, allowing for better role separation between the DirectAccess admin and the UAG admin. In addition, the GPOs can now be linked to OUs, not only to whole domains.



Figure 4: Selecting client computer domains

Figure 5: Selecting OUs/Security groups



Figure 6: Selecting Preconfigured/New GPO

Domain controller auto-discovery has also been extended to discover DCs across all selected domains.


Always managed

Some customers wanted to deploy DirectAccess for the purpose of managing remote client machines, but do not wish to have users connect to application servers on the intranet. Using a new setting located on the first page of the client wizard, the admin can now choose to enable only the first (infrastructure) tunnel, without enabling the second (intranet) tunnel.


Force tunneling

Some customers want to enable client machines to connect via DirectAccess, but while connected they do not want the clients to connect to anywhere else (i.e. creating a split tunnel). The UAG DirectAccess UI enables you to specify force tunneling in one of two flavors:

  • Web-only through the intranet web proxy
  • All traffic, using DNS64 and NAT64 to translate every IPv4 address returned in DNS

If you are thinking of utilizing this feature, please read Tom Shinder’s blog post ( in full prior to deployment.


Improved monitoring and troubleshooting

Server side

Since UAG has a built in monitoring tool called Web Monitor, we’ve integrated DirectAccess information into it, providing a unified monitoring experience. The information is stored in an internal SQL database. You can display a list of currently logged on users, access level (infrastructure/intranet), NAP health status, machine account, user account and other fields.

At the array level, there is a “SCOM-like” health indication for each UAG array member. Everything is presented at the array level so that the admin can access all the information from the console of any node of the array.

The user monitoring PowerShell snap-in can now present the user and server monitoring information at the array-level, without enabling the Security auditing event logs.

Client side

DirectAccess Connectivity Assistant (DCA) is an application that runs on the DirectAccess clients. DCA enables the user to easily check the status of the DirectAccess connection to the corporate network and resources. It also provides troubleshooting features that will help in solving connectivity issues.

In SP1 you can centrally configure the DCA using the UAG DirectAccess UI. Configuration is propagated to clients via GPO. The DCA binary distribution is not done by UAG – you need to do it manually or automate it via GPOs, SCCM or other means.

We’ve added 7 new diagnostics to DCA, E.g. “IPv6 is disabled on the client” and now provide an HTML based troubleshooting summary.


Figure 7: HTML Summary with Hyperlinks

We are excited about this new release and we encourage you to share with us any feedback you have.


Categories: DirectAccess, UAG 2010 SP1 Tags:

Steve Riley on Windows 7 Security

April 23rd, 2009 No comments

While walking the show floor here at RSA, I ran into Steve Riley, who’s an incredibly passionate and knowledgeable Security Evangelist (or officially “Senior Technical Evangelist”) in Microsoft’s Trustworthy Computing organization. He’s a well respected and sought out speaker on security topics. So I thought it would be great to get Steve’s take on his favorite two security features in Windows 7. Take a look at what Steve has to say about Windows 7 security!

Steve Riley discusses Windows 7 Security Features at RSA