Tuesday, 19 October 2010

Deploying a Forefront UAG DirectAccess Array in 10 Easy Steps!

Following on from my previous blog post, I thought it might be useful to also provide a high-level list of steps for deploying Forefront UAG DirectAccess, this time using an array topology for a more highly available solution. Again, this is not an exhaustive step-by-step walkthrough, but it should cover the key high-level tasks involved. More detail can be found in the Forefront UAG DirectAccess TechNet documentation or by looking at Tom’s excellent Test Lab Guides (TLGs).

These steps are based upon deploying Forefront UAG DirectAccess using an array topology combined with ISATAP to support IPv6 intranet connectivity and NAT64 to support IPv4 intranet resources. This is a likely scenario for deployments with a larger number of users, or specific high availability needs, and an existing IPv4 based intranet. 

Please Note: This deployment scenario does not include NAP or Smartcard authentication.

Step 1: Configure Supporting Infrastructure

  • Create ISATAP, NLS and IP-HTTPS DNS records
  • Create DirectAccess client and server security groups
  • Create DirectAccess certificate templates
  • Create service account for UAG array management

Step 2: Configure Network Location Servers

  • Create website and enrol/bind NLS certificate
  • Repeat for additional NLS servers and potentially implement NLB

Step 3: Prepare and Install UAG Servers

  • Install OS, activate, run Windows Update, join AD domain
  • Configure network interfaces and amend bind order – see here
  • Configure static routes – see here
  • Enrol IP-HTTPS and IPsec certificates
  • Install UAG + UAG Update 1 + UAG Update 2 + TMG SP1 + TMG SP1U1
  • Repeat for additional UAG servers

Step 4: Configure UAG Array

  • Configure first UAG server as the array manager
  • Add additional UAG servers to the ‘Managed Server Computers’ computer set in TMG
  • Join additional UAG servers to the array

Step 5: Configure UAG NLB 

  • Define internal NLB virtual IP address with unicast mode
  • Define external NLB virtual IP addresses (at least two) with unicast mode
  • Start NLB on each array member

Step 6: Configure UAG DirectAccess

  • Enable NAT64/DNS64
  • Define appropriate NRPT entries

Step 7: Configure DirectAccess Clients

  • Enrol IPsec certificates
  • Add clients to DirectAccess security group and reboot
  • Install DCA client

Step 8: Configure Active Directory and DNS

  • Add IPv6 prefixes and assign to AD sites
  • Add DNS reverse lookup zones for IPv6 prefixes

Step 9: Test DirectAccess

  • Test internal ISATAP
  • Test external Teredo, 6to4 and IP-HTTPS

Step 10: Complete Post-Installation Tasks

  • Define custom TMG rules for systems management (SCOM, SCCM, Cert Enrolment etc.)
  • Apply UAG SCW hardening template using Group Policy
  • Install and run UAG BPA

Hopefully this provides some structure to the recommended deployment process and should allow you to define a high-level checklist of the key tasks for an array deployment.

Happy DA array deployment! 

Deploying Forefront UAG DirectAccess in 8 Easy Steps!

Based upon recently spending some time creating customer build guides, I thought it might be useful to provide a high-level list of steps for deploying Forefront UAG DirectAccess. This is not a exhaustive step-by-step walkthrough, but should cover the key high-level tasks involved. More detail can be found in the Forefront UAG DirectAccess TechNet documentation or by looking at Tom’s excellent Test Lab Guides (TLGs).

These steps are based upon deploying Forefront UAG DirectAccess using a single server topology combined with ISATAP to support IPv6 intranet connectivity and NAT64 to support IPv4 intranet resources. This is a likely scenario for deployments with a relatively small number of users and an existing IPv4 based intranet. 

Please Note: This deployment scenario does not include NAP or Smartcard authentication.

Step 1: Configure Supporting Infrastructure

  • Create ISATAP, NLS and IP-HTTPS DNS records
  • Create DirectAccess client and server security groups
  • Create DirectAccess certificate templates

Step 2: Configure Network Location Server

  • Create website and enrol/bind NLS certificate

Step 3: Prepare and Install UAG Server

  • Install OS, activate, run Windows Update, join AD domain
  • Configure network interfaces and amend bind order – see here
  • Configure static routes – see here
  • Enrol IP-HTTPS and IPsec certificates
  • Install UAG + UAG Update 1 + UAG Update 2 + TMG SP1 + TMG SP1U1

Step 4: Configure UAG DirectAccess

  • Enable NAT64/DNS64
  • Define appropriate NRPT entries

Step 5: Configure DirectAccess Clients

  • Enrol IPsec certificates
  • Add clients to DirectAccess security group and reboot
  • Install DCA client

Step 6: Configure Active Directory and DNS

  • Add IPv6 prefixes and assign to AD sites
  • Add DNS reverse lookup zones for IPv6 prefixes

Step 7: Test DirectAccess

  • Test internal ISATAP
  • Test external Teredo, 6to4 and IP-HTTPS

Step 8: Complete Post-Installation Tasks

Hopefully this provides some structure to the recommended deployment process and should allow you to define a high-level checklist of the key tasks for a single server deployment.

Happy DA deployment! 

Saturday, 9 October 2010

Publishing OCS 2007 R2 Web Components using Forefront UAG

Background

A good resource for understanding unsupported scenarios for Forefront UAG is the Support Boundaries document. This is dynamic resource that is updated by Microsoft at regular intervals to reflect changes in supported UAG scenarios; sometimes due to new features added by updates, or sometimes based upon completion of additional scenario testing.

During a recent UAG engagement which involved Office Communications Server (OCS) I referenced the above resource to try an determine the level of supportability in UAG for OCS. The following statement is included within the document:

You can publish the following applications via Forefront TMG:

  • Exchange SMTP/SMTPS
  • Exchange POP3/POP3S
  • Exchange IMAP/IMAPS
  • Office Communications Server (OCS)

Due to the location of the statement within the Support Boundaries document, I suspected this reference to OCS was actually related to the use of server publishing for the Session Initiation Protocol (SIP) element (which uses TCP5060/5061) as opposed to the web publishing aspects. After confirming this with the product group, I then began thinking about how to support the OCS web components for customers using UAG as their only remote access gateway solution.

Disclaimer: At this time, it is my understanding that support for OCS Web Component publishing via Forefront UAG is not available from Microsoft, so please consider the implications of using the procedures in this blog post. However, the reverse proxy configuration is actually based on the current TMG guidance, just re-interpreted for the UAG platform.

Support for publishing the OCS web components with ISA/TMG is well documented, but not for UAG it would seem. One option, as covered here, is to use the web publishing feature set of the TMG instance that exists below UAG. However, with no offence to Kevin (OCS Guy), the unbinding is a pretty brutal approach and very unlikely to ever be supported by Microsoft support. As an alternative, I took inspiration from a recent blog by Tom called How to Configure UAG to Publish Your Private Certificate Revocation List in order to define the solution provided in the walkthrough below. The key difference with this approach being that we are using the UAG management console and native feature set.


OCS Web Components

In order for the OCS communicator client to provide full functionality when away from the office, it is necessary to provide access to several web services that are not natively handled by the OCS edge roles. These web services or components include:

  • Download meeting content for your meetings.
  • Expand distribution groups.
  • Download files from the Address Book Service.

These components are defined using a public (external) fully qualified domain name and utilise the HTTPS protocol for secure communication.

So, why do we actually need a reverse proxy?

The reverse proxy role provides additional functionality not provided by any of the three edge roles. Consequently, it is recommended to deploy a reverse proxy server if you want to enable remote users to do one or more the following:

  • Download the address book.
  • Expand distribution groups.
  • Download Live Meeting content.

Specific guidance is provided for Microsoft ISA Server (and consequently Forefront TMG) in the OCS 2007 R2 Edge Configuration Guide. If you already have a dedicated instance of ISA Server or Forefront TMG (or other third-party reverse proxy) you do not need to utilise UAG for OCS web component publishing. However, if UAG is your only inbound remote access gateway, read on… 


The Problem

Even though UAG can act as a reverse proxy for many web applications, it does not provide a default template or wizard for any OCS services (including SIP publishing) or provide any specific UAG guidance/documentation for OCS. So we are kind of on our own here. By looking at the documentation available for Forefront TMG and using the concept of configuring UAG as a generic reverse proxy (with input from Tom’s article) we have most of the answers we need to begin the configuration.

Please Note: It is likely that existing UAG trunks will be configured to enforce authentication, so are not suitable for use with OCS web components which cannot handle default UAG pre-authentication. Consequently, it will be necessary to define a new trunk to host the OCS web components which will require an additional IP on the UAG external interface. Unless you are already using a suitable SAN or wildcard certificate on UAG, you will also likely need to purchase an additional SSL server certificate to cater for the public name (FQDN) used to reference the OCS web components (often termed the OCS external web farm FQDN).


The Solution

Step 1: Assign a unique IP address for use with the OCS trunk

If you are using a UAG array with integrated NLB, it will first be necessary to define a new external VIP using the Network Load Balancing option from the Admin menu of the UAG management console. Otherwise, you will just need to add a new IP address to the external interface.

This IP address will need to be registered in your external DNS zone and assigned to your OCS external web farm FQDN. For this purposes of this post, this will be defined as ocsrp.msedge.org.uk

Step 2: Create the OCS trunk

With a dedicated IP address (or VIP for an NLB array) now available, we can begin the trunk creation process. Create a new trunk as follows:

image

Select Portal trunk:

SNAGHTML15ebbe61

Enter an appropriate Trunk name, Public host name and IP address binding. The public host name is not actually used for our scenario, so it can be a fake entry and doesn't need to specifically match the OCS external web farm FQDN. However, the fake name must contain the same parent DNS domain as the external web farm FQDN (e.g. [name].msedge.org.uk in our example):

image

When presented with the Session authentication server option, add an existing repository or create a new one. As we will be disabling authentication later, this step is only really needed to satisfy the wizard and allow us to progress:

image

Select the appropriate certificate that contains a Common Name (CN) or Subject Alternate Name (SAN) that matches the chosen OCS external web farm FQDN (e.g. ocsrp.msedge.org.uk in our example):

image

Accept the default Use Forefront UAG access policies option; although we will be disabling endpoint component activation later:

image

Accept the default Endpoint Policies options; although we will be disabling endpoint component activation later:

image

Verify your settings and click Finish:

image

Step 3: Configure advanced OCS Trunk properties

Once created, amend the trunk as follows:

Disable (untick) the Require users to authenticate at session logon option from the Advanced Trunk Configuration | Authentication tab:

image

Disable (tick) the Disable component installation and activation and Disable scripting for portal applications options from the Advanced Trunk Configuration | Session tab:

image

 

Step 4: Add the custom OCS Web Components application

Create a new custom application as follows:

image

Select the Other Web Application (application specific hostname) template:

image

Enter an appropriate Application name and Application type:

image

Accept the default Endpoint Policies (these are irrelevant for our particular scenario anyhow):

image

Assuming you have a single OCS server, select the Configure an application server option, otherwise use the farm option:

image

Enter your OCS server name (pool name) in the Addresses field, select HTTPS port:443 and enter the appropriate Public host name that matches your OCS external web farm FQDN (e.g. ocsrp.msedge.org.uk in our case):

image

Accept the default SSO setting of Disabled (we cannot use this for our scenario):

image

Accept the default Portal Link settings:

image

Accept the default Authorisation setting:

image

Verify your settings and click Finish:

image

Step 5: Amend the OCS Trunk properties

Define the custom OCS Web Components application as the Initial Internal Application, disable (untick) the Use portal frame option and remove the default Portal application from the Applications list. This should leave you with the following:

image

Step 6: Create the HTTP to HTTPS redirection trunk

Although I don’t believe this is entirely necessary, for completeness, we can create a HTTP to HTTPS redirection trunk which maps to the OCS HTTPS secure trunk. This ensures that any attempted access over HTTP will automatically be redirected to the secure OCS trunk.

Step 7: Configure UAG Servers to Support Full Authentication Passthrough

The default behaviour of UAG is to “downgrade” the supported authentication schemes that a backend web server sends in the WWW-Authenticate header within an HTTP 401 Unauthorised response. However, when using the OCS Communicator client this behaviour introduces unwanted authentication prompts when the client attempts to access OCS web components (like during an address book download). In order to prevent this default UAG behaviour we can use the FullAuthPassthru registry key as defined here. When this registry key does not exist, or added with a value of ‘0’, UAG will only send the client a WWW-Authenticate:Basic request, even if the backend web server also sent NTLM and/or Negotiate. When the registry key is added with a value of ‘1’, the WWW-Authenticate headers are no longer modified by UAG and the original response from the backend server, will reach the client unchanged. Therefore, we need to amend the default UAG behaviour by using the following registry file:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\WhaleCom\e-Gap\von\UrlFilter]
"FullAuthPassThru"=dword:00000001

When making changes to the registry on UAG servers, it is useful to understand the correct process as discussed here.

This change will ensure that the WWW-Authenticate headers sent from the OCS edge role are not modified and subsequently will allow the OCS Communicator client to transparently provide credentials without prompting the user.

Step 8: Activate the new configuration

Activate the new configuration to apply the changes to UAG.

By activating the changes, we also ensure that custom UAG registry keys (as defined in Step 7) will be written to TMG storage and will not be lost during a reboot cycle.

Please Note: If necessary, use the Forefront UAG Activation Monitor application to monitor the activation process and be patient as it often takes a while to complete Sleepy smile


Testing

In terms or testing, we can achieve a good level of confidence by using a standard browser combined with some specific OCS web component URLs, as follows:

Test the Address Book Service

Open a web browser and access https://<Public Hostname>/abs/ext/

as this virtual directory is protected with Windows Integrated authentication, you should expect to see an authentication pop-up. Enter valid domain credentials and you should be presented with the following (a blank screen):

image

Test the Group Expansion Service

Open a web browser and access https://<Public Hostname>/GroupExpansion/ext/service.asmx

as this virtual directory is protected with Windows Integrated authentication, you should expect to see an authentication pop-up. Enter valid domain credentials and you should be presented with the following (the Live Server Distribution List Expander page):

image

Test the Web Conferencing Service

Open a web browser and access https://<Public Hostname>/conf/ext/Tshoot.html

as this virtual directory is not protected with Windows Integrated authentication, you will not expect to see an authentication pop-up and you should be presented with the following (the Microsoft Office Live Meeting Client Troubleshooting page):

image

Once the above tests have been completed successfully, you can then test the communicator client from an external location. You can use the Forefront UAG Web Monitor Event Log to verify application access and troubleshoot any potential problems. However, if the above tests were successful, it is very likely that the communicator client will also work. 


Summary

So, that completes this walkthrough for publishing the OCS web components using UAG. I hope it proves useful until such time as official Microsoft documentation or guidance is available.

Please Note: From what I understand, the above walkthrough should also support Microsoft Lync (the impending successor to OCS 2007 R2) as the web component elements of the product remain largely unchanged.

I plan to write a follow up article very soon which covers UAG publishing for OCS 2007 R2 Communicator Web Access (CWA) with specific support for the iDialog iPhone application from Modality Systems. This is a pretty cool iPhone app that provides OCS communicator client functionality on your iPhone – nice! Nerd smile

Props: Many thanks to Ran Dolev (MSFT) and Steve Mercieca for valuable input to this blog post.

Thursday, 7 October 2010

The Curious Case of Forefront UAG DirectAccess and the Teredo Failure…

I experienced a slightly unusual problem during a recent Forefront UAG DirectAccess (DA) deployment which I thought would be interesting to share…

Background

The particular DirectAccess deployment was a little unusual because DA clients were located on a private MPLS cloud and not the Internet as you would normally expect. The DA solution was designed to allow home workers with dedicated connections into the MPLS cloud to experience seamless and transparent access to corporate resources, as opposed to using some form of traditional VPN offering. As the MPLS cloud was not running a native IPv6 infrastructure, it was necessary use IPv6 transition technologies in order for DA clients to reach the UAG array of DA servers.

The UAG infrastructure consisted of an array of UAG servers combined with integrated Network Load Balancing (NLB) for failover and load balancing duties. The UAG server external network interfaces were connected to a public IPv4 addressed DMZ and assigned two public IPv4 addresses.

During the design process I was faced with the following interesting question:

“If DA clients are using private addresses but have a fully routed (non-NAT’ed) connection to the UAG array with no firewall limitations, which transition technology would be used?”

It is usually easy to answer this type of question for an Internet connected DA client, based upon the following knowledge:

  • If the DA client is using a public IPv4 address, 6to4 will be used.
  • If the DA client is using a private IPv4 address, Teredo will be used.
  • If the DA client is using a private IPv4 address and is located behind a firewall device that is blocking UDP3544 (Teredo), IP-HTTPS will be used.

If you consider a standard Internet connected DA client, the ability to be able to use a private IP address and reach the UAG DA array with a routed connection (e.g. without the use of NAT) just does not exist. Consequently, my gut feeling in this particular scenario was that Teredo would be used as opposed to any other transition technology, but couldn’t be 100% sure it would work.


Establishing a Baseline

During the early stages of testing, we placed a DA client on the same network as the UAG DA servers external interfaces to provide a simple, direct connection and establish a working baseline. In this particular scenario, the DA client was using a public IPv4 address because it was in the same network as the UAG DA servers. Hence, the DA client used the 6to4 transition technology and connected successfully to corporate resources first time – DirectAccess was working! So, we now had a working baseline upon which to move forward.#


The Problem

However, upon connecting a DA client to the MPLS cloud, the DA connection failed. Early observations revealed the following:

  • The DA client was using a private IPv4 addresses, assigned by the local MPLS router.
  • The DA client was attempting to Teredo, but could not complete the connection with “State: offline, Error: primary teredo server unavailable over UDP” errors.

The first observation was achieved using the ipconfig /all command. The second observation was achieved using the netsh interface teredo show state command.

Based upon experience with other deployments, my first thoughts turned to some form of in-path firewall blocking UDP3544 (Teredo) from reaching the UAG DA array. After investigating the only in-path firewall (located between the MPLS cloud and the UAG DA array) it could be seen that UDP3544 was not being blocked and we could see traffic from the DA client passing through the firewall successfully.

To begin troubleshooting, we first looked at the general DA client state using the netsh dnsclient show state command, looking for the following key states:

  • Machine Location: Outside Corporate Network
  • DirectAccess Settings: Configured and Enabled

Next, we determined whether we could ping the actual IPv6 address of the UAG DA array (well, to be precise, the IPv6 address of the first public IPv4 NLB VIP in this case).

By using a netsh namespace show effective we were able to list the Name Resolution Policy Table (NRPT). Within this table, it is possible to see the IPv6 address of the UAG DirectAccess DNS server listed under the DirectAccess (DNS Servers) section.

This resulted in successful replies and we provided we were able to successfully ping the IPv6 address. I repeated the process with the relevant IPv4 address, which also resulted in successful replies.

In order to verify potential IPv4 routing problems and ensure that traffic was indeed reaching the UAG DA servers, I looked at the TMG real-time logs which showed both Ping and Teredo protocols as Initiated/Allowed.

Please Note: In order to test IPv4 Ping, it was necessary to amend the default system policy Remote Management | ICMP (Ping) access behaviour by adding the IPv4 address of our DA client to the Remote Management Computers computer set. After testing, this temporary entry was removed for security reasons.   

So, to summarise our findings:

  • DirectAccess was configured and enabled on the DA client.
  • The DA client had successfully determined it was located outside of the corporate network.
  • We could ping the IPv6 address of the DA DNS server.
  • We could ping the IPv4 address of the first public IP address assigned to the UAG DA array.
  • The in-path firewall was not blocking Teredo on port UDP3544.
  • DA client traffic for both Ping and Teredo protocols were being logged by the local TMG instance on UAG.

At this point, I was a little confused as we appeared to have good connectivity and had met all the necessary requirements for DA to function. From our testing of the DA client “on subnet” I also knew that DirectAccess connectivity could be achieved and it must be a specific issue with Teredo, as connectivity via 6to4 was already proven.


The Solution

After a little research into the mechanics of the Teredo protocol, I suddenly released that the detection of NAT was actually inherent to the Teredo protocol. However, in this particular scenario we were using DA clients with private IPv4 addresses yet no form of NAT was actually being employed because we didn’t actually need it.

After reconfiguring the in-path firewall to employ NAT for for the associated DA firewall rule, the Teredo protocol successfully negotiated a connection with the UAG DA server and DirectAccess was finally working! Hot smile


Bonus Question!

Now, a sensible question for those paying attention would be:

“If Teredo was not able to connect, why didn’t the DA client fall back to using IP-HTTPS?”

Well, this is a very good question and is easily answered. During the design stages the customer had decided to specifically prevent the use of IP-HTTPS; mainly because of the associated performance loss and there was just no need for it due to the inherent openly routed private network design. Consequently, I had disabled the IP-HTTPS interface using a custom Group Policy object (more on this in a future blog post) on all DA clients to meet this requirement. With the IP-HTTPS interface disabled, and 6to4 not available, Teredo is, and was, the only remaining option.


Summary

So, a slightly unusual deployment scenario but I gained a much better understanding of the Teredo protocol and a useful exercise for troubleshooting failed DA client connectivity. Hopefully you have learned something too Winking smile

Forefront MVP–Year 3 Award

Another MVP award this year, making it my third year as a Forefront MVP…I’m very honoured, grateful, and it’s fantastic to see that my community input is valued…the best bit is a trip to Redmond for the MVP Summit early next year; I can’t wait! Winking smile