Wednesday, 27 January 2010

Enabling RSA SecurID Authentication in Forefront UAG

A common requirement for most remote access solutions is the use of two factor authentication (2FA); RSA SecurID 2FA being a common choice for many organisations.

During UAG release candidate testing, it was not possible to utilise RSA SecurID authentication as there was no RSA Windows Agent available for Windows Server 2008 R2 (the platform used by Forefront UAG).

With the full RTM release of the UAG product, RSA still have not released a supported agent for Windows Server 2008 R2, hence I was keen to see if RSA SecurID authentication was supported by Microsoft.

So, does that mean RSA SecurID is not a supported authentication scheme on UAG? No, actually, it doesn’t, as Microsoft have now integrated the agent into the UAG deployment (like they did with ISA/TMG) such that it is not necessary to manually install the RSA Agent as you did with its predecessor, IAG. This is great news and brings UAG nicely in line with ISA/TMG deployments.

However, when attempting to configure RSA SecurID authentication using the Forefront UAG Management console, you may be surprised to receive an error message stating the following: Error message: ACE client is not installed. An example screenshot is shown below.

uagrsaservererror 

Now at this point, most UAG admins would probably give up and assume that they need to go and speak to RSA about a Windows agent for Windows Server 2008 R2; only to find that one is not currently available.

However, this error message is actually quite misleading and is something incorrectly left over from IAG. Basically this error can be ignored, as the product now includes the RSA agent as a native DLL, thereby negating the need to install any RSA software.

So, I thought the following walkthrough on configuring Forefront UAG with RSA SecurID may be useful for those early adopters out there, especially as there seems to be limited documentation available for this particular scenario.

Configuring RSA Authentication Manager

As with all RSA integration, the first thing to do is to define an RSA host agent in the RSA Authentication Manager console which will be used to represent the Forefront UAG server (or servers if using an array).

The key requirements here are to define a Network Address that represents the IP address that is bound to the UAG internal interface, and then define the agent type as a Net OS Agent.

uagrsahostagent

Please Note: If you are using an array deployment, it will be necessary to create an RSA host agent entry for every array member to ensure authentication is successful during load balancing or failover conditions.

Depending on your RSA configuration, you may need to define specific Group Activations or enable the Open to All Locally Known Users option.

Preparing the RSA Agent

As UAG has multiple networks interfaces, it is recommended (as with ISA/TMG before it) to define the primary interface that should be used when communicating with the RSA Authentication Manager server; normally the internal interface. This is achieved by adding the the following registry string:

HKEY_LOCAL_MACHINE\SOFTWARE\SDTI\AceClient\PrimaryInterfaceIP

with a value which represents the IP address that is bound to the UAG internal interface, as shown by 1.1.1.1 in the example below.

uagrsaip

More info here: http://support.microsoft.com/kb/925165

The last thing to do is copy the sdconf.rec file from your RSA environment to the UAG server (or servers if using an array). This file should be placed into the %Windir%\System32 folder as shown below:

uagrsasdconf 

Please Note: If you are using an array deployment, it will be necessary to repeat the above steps for every array member to ensure authentication is successful during load balancing or failover conditions.

Configuring Forefront UAG

With the RSA Server configured and the RSA Agent prepared, we can now define a new authentication server within UAG.

Start the Forefront UAG Management console and select Admin from the menu, followed by Authentication and Authorisation servers…

Click Add and select the RSA SecurID server type. You can now define the appropriate details for your environment as shown below:

uagrsaserver

Please Note: When defining the Server Name: field, be aware that the name chosen here will be displayed to users on the authentication page so should be chosen wisely.

When you click OK, you will still receive the same error message discussed previously; which we now know can be ignored. Therefore, click Yes to continue.

Click OK to finish adding the authentication server. Click on the Activate Configuration option to activate the new changes.

Once activated, UAG will make the appropriate firewall policy changes in TMG to permit the necessary RSA communications, as shown below:

uagrsafwpolicy 

Other UAG Array Considerations

One final note for those using UAG arrays; as we need to define individual RSA agents hosts, this means that it will be necessary for RSA Authentication Manager to create individual node secrets for each array member. Therefore, it is recommended to test authentication for each array member individually to ensure this has been completed successfully. This can be verified by editing the relevant RSA host agent entries in the RSA Authentication Manager console. Each host agent should have the Node Secret Created option enabled if node secrets are successfully present. Node secrets will not be fully created until a successful authentication has taken place on each of the Forefront UAG servers in the array.

Please Note: One final caveat, I am unaware if there is any intelligence built into UAG to compensate for array scenarios when using RSA SecurID authentication. Consequently the steps defined throughout this article are recommended to be completed per array member for completeness.

I imagine Microsoft will fix the unnecessary RSA ACE client error prompt in due course, but until then, I hope this blog article has been useful…

Friday, 8 January 2010

How to Temporarily Disable DirectAccess Functionality on a DirectAccess Client

A surprising, but increasingly common question that comes up when talking to customers about Forefront UAG DirectAccess is:

Can we temporarily disable DirectAccess when using low bandwidth or expensive mobile Internet data tariffs and don’t need corporate network access?

Although this question seems a little strange and counter production when talking about a technology that is designed to specifically be ‘always on’, it is actually very valid for the given scenarios.

The best way I have found to temporarily disable DirectAccess is to stop the IP Helper service on the DirectAccess client.

This can be done using the Computer Management snap-in or using the following command line:

net stop “IP Helper”

to regain full DirectAccess functionality it can be restored by starting the service in Computer Management or using the command line:

net start “IP Helper”

The IP Helper service is used to provide tunnel connectivity using IPv6 transition technologies (6to4, ISATAP, Port Proxy, and Teredo), and IP-HTTPS. If this service is stopped, the computer will not have the enhanced connectivity benefits that these technologies offer.

Please Note: This method will not work if you have DirectAccess clients using native IPv6. However, this scenario is unlikely for most DirectAccess clients as a majority will be using 6to4/Teredo transition technologies or IP-HTTPS.

Simple, but handy at times…

The Path to DirectAccess – Part 1: Choosing the DirectAccess Platform

So, let’s begin by asking a simple question; what is DirectAccess? Well, DirectAccess is a new feature in Windows 7 and Windows Server 2008 R2 that gives users the experience of being seamlessly connected to their corporate network any time they have Internet access. With DirectAccess enabled, requests for corporate resources (such as email servers, shared folders, or intranet Web sites) are securely directed to the corporate network, without requiring users to connect to a virtual private network (VPN).

I began looking at DirectAccess while getting to grips with Windows Server 2008 R2 during its early release. Although the technology was hugely impressive, it had limited application potential for many customers as the required dependencies set the bar pretty high in terms of an expected supporting infrastructure; the killer element being the need for native Internet Protocol version 6 (IPv6).

Until more recently, my exposure to IPv6 had been relatively small and was placed in my “I really need to learn more about that…” mental R&D queue. Slightly naively, I also saw it as ‘IPv4 with longer addresses’ which I now know is very far from the truth as the protocol includes a lot of new concepts and considerations. The extent to which you need to understand these concepts and considerations is obviously very dependant on the specific application though. As DirectAccess is hugely dependent on IPv6, we have a little work to do in this area…more to follow with regard to IPv6 in a future article…

Having been exposed to this new technology path, I thought it might be useful to share my experiences and offer some guidance for those undertaking a similar journey. A working DirectAccess deployment is a joy to behold, where seamless and transparent access to intranet resources brings back a little IT sparkle for users when compared to other traditionally cumbersome remote access solutions.

I plan to provide a series of articles that cover the key elements in order to deploy DirectAccess (DA); specifically when using Forefront Unified Access Gateway (UAG) as the DA platform, as opposed to the native DirectAccess offering provided by Windows Server 2008 R2. So, why do we need to use UAG? Well, we don’t need to, but there are some very compelling reasons for doing so, and that is the whole point of this first article in the series…

From this point forwards, I will use the following terms throughout this and the upcoming articles:

  • Native DirectAccess => This term is used to imply the use of DirectAccess which is provided as part of the native Windows Server 2008 R2 feature set.
  • UAG DirectAccess => This term is used to imply the use of DirectAccess which is provided as an integrated offering of the Forefront UAG feature set.

So, back to my previous question, why do we need to use UAG? Well, this is best answered by looking at what native DA cannot do and what UAG DA provides over and above the native DA solution; time for a summary table, I think:

Feature

Native DirectAccess

UAG DirectAccess

Access to IPv6-only intranet resources

Yes

Yes

Access to Legacy IPv4-only intranet resources

No

Yes

Easy to Scale Out

No

Yes

High Availability

Basic

(needs Hyper-V failover)

Advanced

(NLB included “in the box”)

Centrally managed

No

Yes

Support for Legacy Windows clients

No

Yes, via SSL VPN

Support for non-Windows clients

No

Yes, via SSL VPN

Deployment

Complex

Simpler

Cost Included with Win2k8 Win2k8 + UAG Server + CALs
Edge Ready No Yes

If we now consider operating systems with support for IPv6, this can be summarised as shown in the following table:

Operating System

IPv6 Enabled

IPv4 Enabled

Windows Server 2008 R2

Yes

Yes

Windows Server 2008

Yes

Yes

Windows 7

Yes

Yes

Windows Vista

Yes

Yes

Windows XP

No*

Yes

Windows Server 2003

No*

Yes

Windows Server 2000

No

Yes

Legacy Application Server

No (Unlikely)

Yes

Non-Windows Server

No (Maybe)

Yes

* IPv6 is not natively enabled, but can be configured. However, hosted applications are unlikely to be IPv6 aware on this server platform.

Looking at both tables, it should be pretty easy to see that the two key areas which are likely to be the most deployment restrictive (highlighted in red) when using native DA are:

  • Access to Legacy IPv4-only Intranet Resources
  • High Availability

Obviously, if you have basic high availability requirements and already meet the requirements for an internal IPv6 deployment then the native solution may be viable. However, in my experience, the environments who can achieve this are very much in the minority.

So, why are the limitations of native DA so impacting? Well, I have yet to meet a customer who has fully deployed IPv6 on their internal networks and configured the appropriate addressing on all clients and servers. Consequently, native DA will not be able to provide access to existing IPv4 only resources like Windows Server 2003 or other IPv4 based application servers. For most environments, this will represent a considerable proportion of the existing server estate and hence represents a highly undesirable limitation.

UAG DA solves this problem using two translation technologies called NAT64 and DNS64 (pronounced NAT-6-to-4 and DNS-6-to-4).

NAT64 (as the name suggests) provides DirectAccess clients with access to IPv4-only resources. The NAT64 function in Forefront UAG allows IPv6 traffic to be initiated towards IPv4 servers and for the traffic responses to return correctly.

Please Note: NAT64 does not work in reverse; so if traffic needs to be initiated outbound to the DirectAccess-enabled clients, this capability is not available with NAT64. Consequently, in order to achieve outbound access to DA clients (usually for client management) it is necessary to configure Management Servers with native IPv6 support <hint>

DNS64 (as the name also suggests) modifies the DNS query replies, so that requests for the name of an intranet server have their IPv4 addresses converted into an appropriate IPv6 address response. This ensures that DNS queries from DirectAccess clients are resolved to the IPv6 address of the UAG server performing the inbound NAT64 translation.

A good overview of these elements is presented in the following UAG team blog article:

Deep Dive Into DirectAccess – NAT64 and DNS64 In Action

Once you begin using DA day to day, you will quickly become used to ubiquitous access to corporate resources and your expectations of remote access availability will be far greater than ever before. Consequently, when DA stops working, you will feel hugely isolated and the impact to productivity will ultimately be felt by all DA users. Therefore, high availability for the DA service soon becomes a very important consideration, even if not considered so at the beginning. Based upon the limited options available with native DA, this becomes a strong secondary driving force in the decision to use UAG DA. As expected, this was one of the key design goals for the Microsoft UAG product group, in addition to the use of critical NAT64 and DNS64 features to provide IPv6 to IPv4 translation, as discussed above.

Forefront UAG allows DirectAccess services to be placed into an array to load balance DirectAccess client requests. It its native form, DirectAccess is integrated with NLB; so if one of the servers in the array fails, it’s removed from the array and requests are sent to the remaining servers. It is interesting to note that currently, only one hardware load balancer vendor (F5 Networks) provides support for Forefront UAG when it is used with an array for DirectAccess. Therefore, NLB is pretty likely to be used for many UAG DA deployments when designing a high availability architecture.

In my opinion, these two limitations alone, are a good enough reason for UAG DA to be the only realistic entry level option for any DirectAccess deployment. In my ‘day job’ I strongly recommend that customers looking at DirectAccess move straight to using UAG DA, without even considering Native DA, where possible.

So, with our DirectAccess platform choice made, let’s get started deploying UAG DA! Well, that’s enough for Part 1, so I hope to see you back soon for the next instalment in the series titled Part2: Thinking About IPv6. For those of you who have been reading closely, you may now be thinking “Why do we need to worry about IPv6 if we are using NAT64?”; and that is a very good question I will leave with you…

For the remaining articles in the series, we will look at deploying UAG DA for an example environment and attempt to provide a real-world slant on how best to use the technology available. I hope to share some useful lessons learnt from my release candidate deployment experiences and also how to extend the solution with Network Access Protection (NAP).

Generating a TMG HTTPS Inspection Certificate Using a Windows Server 2008 Certificate Authority

From what I could tell, there is no specific guidance or Microsoft documentation (yet) on creating a HTTPSi certificate using an internal Microsoft Active Directory Certificate Services (AD CS) Certificate Authority. Hence, I thought it might be useful to document the process I used recently.

Although it is possible to publish the default TMG generated HTTPSi certificate into Active Directory so that it is published to the Trusted Root Certificate Authorities certificate store on client machines, this is an unnecessary process if you already have your own internal CA. For the purposes of this article, I have used a Windows Server 2008 CA, but the process would be similar using Windows Server 2003.

The HTTPSi creation process involves the following high-level steps:

  • Create a TMG HTTPS Inspection certificate template
  • Configure TMG to communicate with the internal CA
  • Request the HTTPSi certificate from the internal CA
  • Export the HTTPSi certificate to PFX format
  • Import the HTTPSi certificate using the Forefront TMG Management Console
  • Test HTTPSi

So, looking at these steps in turn…

Create a TMG HTTPS Inspection Certificate Template

The first step in the process involves creating a certificate template which will be used to define the properties of the HTTPSi certificate.

Based upon my understanding from the documentation that is available, the HTTPSi certificate requires a Certificate Signing key usage. Therefore, a good starting point for creation of the HTTPSi template is to duplicate the existing Subordinate Certificate Authority template.

On the internal CA, start the Certificate Authority snap-in, right-click the Certificate Templates node and then select the Manage option:

In the Certificate Templates Console right-click the existing template titled Subordinate Certificate Authority, and select the Duplicate Template option:

Select Windows 2003 Server, Enterprise Edition template version:

image 

Please Note: As Forefront TMG 2010 does not support CNG (Certificate New Generation) based templates, you cannot use Windows Server 2008, Enterprise Edition templates (also called v3 templates).

On the General tab, enter Forefront TMG HTTPS Inspection, or a similar name, in the Template display name: field.

Set the required certificate lifetime in the Validity period: field or accept the default value of 5 years.

image

On the Extensions tab, select the Key Usage extension and click Edit:

Deselect all Signatures except the Certificate Signing option.

image

On the Extensions tab, select the Basic Constraints extension and click Edit:

Enable the Do not allow subject to issue certificates to other CAs option.

image

On the Security tab, ensure that TMG computer object has Read and Enroll permissions:

Please Note: If you are using a TMG Enterprise Edition, all TMG array member computer objects will require these permissions.

Click OK to complete the certificate template creation process and close the Certificate Templates Console.

In the Certificate Authority snap-in, right-click the Certificate Templates node and then select the New, Certificate Template to Issue option:

On the Enabled Certificate Templates window, select the Forefront TMG HTTPS Inspection template (or your chosen name) and click OK.

The new template should now be listed in the right-hand pane of the Certificate Authority snap-in.

Configure TMG to Communicate with the Internal CA

As discussed in one of my previous blog entries here we need to prepare TMG in order to request certificates from an internal CA. Rather than reinvent the wheel, you can simply use the following section from this previous blog article along with the included link (see below) to Stefaan’s article.

Preparing the Firewall Policy

Rather than re-invent the wheel, it makes more sense to point readers to an existing article which covers the process of defining a firewall policy which allows certificate requests from the ISA Server computer itself.

The required firewall policy changes are covered very well in the Certificate Enrollment Requires a Custom Protocol blog entry by Stefaan Pouseele. The remainder of this blog entry assumes that you have successfully completed the firewall policy changes as described above (or in a similar fashion with a slightly more open policy).

So, assuming that you now have the correct Firewall Policy in place, we can move onto requesting the actual HTTPSi certificate.

Request the HTTPSi Certificate from the Internal CA

In terms of requesting the HTTPSi certificate, we have a couple of common options:

  • Use a command line approach with Certreq
  • Use the Certificates snap-in

The first option is discussed in detail in my previous entry titled Requesting ISA Server Certificates from a Windows Server 2008 Certificate Authority and provides an ideal approach for those who are happy to work with command line tools. This approach is also the recommended option when using certificate templates that are configured to disallow private key exports.

However, as the Forefront TMG Management Console requires the HTTPSi certificate to be provided in Personal Information Exchange (PFX) format rather than selected from the local certificate store, we have no option but to create a template that allows the private key to be included as part of the PFX export process. Consequently, we are therefore able to use the Certificates snap-in to request the certificate and are not forced to use command line tools for this particular scenario; the command line approach is still viable though.

As I have already covered the command line approach (in detail) within the previous blog entry, I think it is more useful to provide a walkthrough of the Certificate snap-in approach, as this is a viable method in this scenario.

Please Note: If you are using a TMG array, the HTTPS inspection certificate is stored to the configuration storage, and array members can begin using the HTTPS inspection certificate after synchronising with the configuration storage. Subsequently, the import process only needs to be completed once per array.

Open the Certificates snap-in choosing the Local Computer account certificate store. Right-click on the Certificates node and select All Tasks, Request New Certificate.

Follow the Certificate Enrollment Wizard as follows:

On the Certificate Enrollment window select the Active Directory Enrollment Policy option and click Next.

image

Select the Forefront TMG HTTPS Inspection certificate template (or chosen name) and click on the More information is required to enroll for this certificate. Click here to configure settings link:

image

On the Subject tab, select the Common Name type from the Subject name: field and enter Microsoft Forefront TMG HTTPS Inspection Certificate Authority (or a similar name) into the Value: field. Click the Add button to assign the value:

image

On the Extensions tab, verify that the key usage contains only Key Certificate Signing and verify that the Basic constraints option of Allow subject to issue certificates is disabled.

On the Private key tab, verify the the Make private key exportable is enabled option is enabled.

Finally, click OK, followed by Enroll to finalise the certificate request. The wizard should indicate that the certificate has been enrolled successfully.

Export the HTTPSi Certificate to PFX Format

Once you have created the certificate, it will have been placed into the Local Computer account certificate store. However, the Forefront TMG Management Console requires the HTTPSi certificate to be provided in Personal Information Exchange (PFX) format rather than selected from the local certificate store. Hence, we need to export the HTTPSi certificate using a PFX format.

Open the Certificates snap-in choosing the Local Computer account certificate store. Select the Certificates node and select the newly create HTTPSi certificate from the right-hand pane. Right-click the certificate and select All Tasks, Export…

Follow the Certificate Export Wizard ensuring that you select the option to Yes, export the private key and the Personal Information Exchange – PKCS #12 (.PFX) format; save the export file to a local folder/drive.

Important: Make a note of the password used to protect the PFX file, as this will be required later.

With the HTTPSi certificate now available in PFX format, we can import this into the TMG configuration using the Forefront TMG Management Console.

Import the HTTPSi Certificate Using the Forefront TMG Management Console

Open the Forefront TMG Management Console and select the Web Access Policy node. Click on the Configure HTTPS Inspection option from the Tasks pane.

Select the Import a certificate option and click the Import button to browse to the location of the previously saved HTTPSi certificate PFX file. When prompted, provide the password used previously to protect the PFX file.

To validate that the certificate has been imported successfully, click the HTTPS Inspection Trusted Root CA Certificate Options button, followed by the the View Certificate Details… option.

The existing self-signed Forefront TMG certificate should now have been replaced by a certificate titled Microsoft Forefront TMG HTTPS Inspection Certificate Authority (or chosen name) which appears to have been issued and signed by the internal CA.

image

So, you should now have successfully completed the HTTPSi configuration and all we need to do is test the final deployment.

Test HTTPSi 

Finally, in order to test HTTPS inspection, we can simply browse to a HTTPS enabled web site using TMG as our proxy server and examine the SSL certificate properties.

Using IE with an example URL of https://www.amazon.com, you should see the following:

image

As can be seen, the issuer is now shown as the Microsoft Forefront HTTPS Inspection Certificate Authority (or the name chosen). This should be same name given as the Common Name (CN) value defined for the HTTPSi certificate during the request process.

If you examine the certificate common chain, you should also now see that the website certificate chains to the internal CA, as shown below:

image

It is interesting to note that if the destination website is using Extended Validation (EV) certificates, the use of HTTPSi will break the default behaviour of IE and will not present the usual ‘green address bar’ for a highly trustworthy web site.

This is an expected limitation that is well documented in the TMG Unsupported Configurations document available here.

Update: Adrian Dimcev also covers some interesting thoughts on this particular area (and some overlap with this article) in his recent blog entry here.

So, that completes our walkthrough, which hopefully provides a good overview of the process involved.

As certificates are a common cause of frustration for many administrators, I plan to provide some more blog articles on the subject of issuing certificates very soon, this time for use with a Unified Access Gateway (UAG) DirectAccess deployment…