Tuesday, 14 December 2010

Forefront UAG SP1 Endpoint Assessment Changes Impact Mobile Devices like iPads/iPhones

I noticed from the Forefront UAG SP1 release notes that endpoint assessment for mobile devices has changed within SP1. I have also seen a few people reporting issues on the TechNet forums with UAG portal access problems when using Apple iPhone/iPad devices since applying SP1. These changes are covered by the following statement:

“In Forefront UAG RTM, mobile devices including the iPhone, Android and Windows Mobile were included in the Windows, Mac, and Linux platform-specific policies, and allowed access by the Forefront UAG Default Session Access policy. In Forefront UAG SP1, mobile devices were removed from this policy, and now belong to the Other platform-specific policy.”

The net result of this change is that mobile devices like iPads/iPhones will receive  the following error when attempting to access the UAG trunks: The endpoint does not meet access policy requirements for this site.

To continue to include them in the Default Session Access Policy, do the following:

  1. In the trunk that allows access to these devices, open the Endpoint Access Settings tab, and click Edit Endpoint Policies.
  2. In the Manage Policies and Expressions list, click Default Session Access, and then click Edit Policy.
  3. In Other, select Always.
  4. Apply and activate the configuration.
image

To continue to include them in the Default Web Application Access Policy, do the following:

  1. In the trunk that allows access to these devices, open the Endpoint Access Settings tab, and click Edit Endpoint Policies.
  2. In the Manage Policies and Expressions list, click Default Web Application Access, and then click Edit Policy.
  3. In Other, select Always.
  4. Apply and activate the configuration.

image

To ensure published applications appear in the portal when using mobile devices like iPads/iPhones (when applications are supported for mobile devices):

  1. In the trunk that allows access to these devices, review the Applications area, click the required application, and then click Edit.

  2. On the Application Properties dialog box, click the Portal Link tab.

  3. On the Portal Link tab, select the Premium mobile portal check box to show this application in the premium mobile portal.

  4. On the Application Properties dialog box, click OK.

  5. Activate the configuration.

image

Thursday, 9 December 2010

Microsoft Forefront UAG DNS64 Service Incorrectly Set to Manual After Forefront UAG SP1 Installation

The Forefront UAG SP1 Release Notes document the following issue:

“After installing SP1 RTM on a Forefront UAG server running SP1 RC and acting as a DirectAccess server, the DNS64 service will be set to Manual. Following the installation, set the DNS64 service to Automatic and start the service.”

However, although this problem is a known issue when upgrading from Forefront UAG RC1 to SP1, from my recent deployment experience it can also happen when deploying UAG SP1 onto an RTM version (including RTM U1 and RTM U2 versions).

Please Note: A good overview of UAG version numbers provided by Ben@MSFT can be found here.

The fix is easy, after applying SP1, simply reconfigure the Microsoft Forefront UAG DNS64 Service service startup type to be Automatic as opposed to Manual; then start the service manually.

image

This issue (obviously) assumes you are actually using the DNS64 service in your UAG DirectAccess deployment and consequently need the DNS64 service to be started and running to provide DNS translation services from IPv6/IPv4.

A bit annoying I agree, but an easy fix nevertheless Smile

Thursday, 2 December 2010

Silversands Microsoft Security Consultant Wanted!

Microsoft Security Consultant Role

£Excellent + profit share scheme + flexible benefits + car allowance

We are seeking an experienced security consultant to join our expanding consultancy team.

The role involves all areas of consultancy from presales activities and presentations to detailed design planning and implementation of solutions.

The successful candidate will have outstanding customer facing skills along with a sound working knowledge of Microsoft Forefront products and other third party security products.  A good business understanding is essential as is the ability to help clients identify their needs and work with them to deliver quality solutions.

You should have experience in the following technical areas:

  • Design and implementation of Microsoft security solutions including Certificate Services, ISA Server, Threat Management Gateway (TMG), Unified Access Gateway (UAG) and DirectAccess
  • Conducting in-depth technical design workshops and creation of detailed design documentation
  • Experience of publishing Exchange and SharePoint application services using TMG and UAG  
  • Excellent understanding of TCP/IP and networking topologies
  • Excellent IT security awareness
  • A broad understanding of all core Microsoft technologies including Active Directory, Exchange and SharePoint with an appreciation for following Microsoft security best practice is essential
  • Ideally the successful candidate will have an understanding of third party security solutions including Trend Micro, Juniper, RSA, Websense, Celestix etc. 
  • Ideally the successful candidate will be a MCITP Enterprise Administrator in Windows Server 2008 or CISSP

This is an outstanding opportunity to join a leading Microsoft Gold Partner committed to delivering quality solutions to its customers and work alongside our Microsoft Forefront MVP (that would be me!). Silversands’ close working relationship with Microsoft will ensure that you have the opportunity to keep abreast of developing technologies and exposure to new products through the Technology Adoption Program (TAP) and Customer Advisory Group (CAG) programmes.

Potential candidates can drop me an email or visit: www.silversands.co.uk for more information.

Thursday, 4 November 2010

Problems Accessing SharePoint 2007 RSS Feeds via Forefront UAG

During a recent deployment, I experienced problems accessing SharePoint RSS feeds when using Forefront UAG. After some assistance from Ben Ari @ Microsoft and a little of my own research, I thought it might be useful share the solution as it is a likely common problem when using Forefront UAG to publish SharePoint.

Forefront UAG trunks enable access to multiple web applications by using host address translation (HAT). While users communicate with the external websites to request, receive, and upload data to and from the applications they access via Forefront UAG, Forefront UAG transparently parses the requests and responses, using content-type parsers, and manipulates the URLs in those transactions, on the fly. The parsers manipulate the data so that, to the user, all links to the applications that are enabled in the portal point to one host, the public host.

However, sometimes this parsing process, can do more harm than good; as shown with the example presented in this blog post!

Having used the native Microsoft Office SharePoint Server 2007 template in order to publish the SharePoint web servers,  I then received Feed code errors in the browser when attempting to access SharePoint RSS feeds. After investigating this further, it was found that UAG was applying changes to the RSS page as part of the parsing process and consequently corrupting the feed data. 

In order to fix the issue, it was necessary to define a series of entries to prevent particular SharePoint responses from being parsed by UAG. In order to create these entries, we need to consider the application server being published and construct a regular expression that can be used to define the URL that should be excluded from parsing. This is achieved by using the Do not parse the response bodies to these requests: option available in the Portal tab of the Advanced Trunk Configuration page, as shown below.

Click Edit to begin the process:

image

In order to define the URLs which will not be subject to UAG parsing, we need to define a Server and URL combination to represent the requests used when accessing RSS data via SharePoint. These URLs can often be determined by looking at the browser address bar, or more likely using some form of web debugging utility like Fiddler, HttpWatch or Charles.

Click Add to define the Server field for our request:

image

In order to define the server name that matches the specific requests for our scenario, we need to enter the server as defined in the Web Servers tab of the SharePoint application within the portal. In our example, the server name listed under the Web Servers tab for our SharePoint application is sharepoint.internal.msedge.org.uk. The syntax for the server field needs to comply with RegEx which is common place within UAG as discussed here. However, in RegEx, dots are non-literals, which must be escaped using an escape character. Consequently, the server name needs to be entered into the server field including the use of backslash escape characters because our server name is an FQDN and contains dots:

image

Once entered, we then need to define a URL which matches one of the specific requests for our RSS scenario. Highlight the appropriate Server item and then click Add to begin defining the URLs:

image

For our particular RSS scenario we need to define the first URL using a regular expression (RegEx) of .*listfeed.* This essentially matches any URL that contains the text listfeed as this is used in the majority of SharePoint pages that contain RSS elements (called listfeed.aspx).

image

With the above changes, you should now have a the following configuration:

image

We also need to define a second URL using a RegEx expression of .*srchrss.* This essentially matches any URL that contains the text srchrss which is used when accessing RSS information from the SharePoint search page (called srchrss.aspx).

image

With the above changes, you should now have a the following configuration:

image

Click OK, followed by OK on the Advanced Trunk Configuration page and then click Activate to apply the changes.

Once applied, you should now find that RSS pages appear correctly and the feed code browser errors should be gone!

Hope this helps…

Wednesday, 3 November 2010

Forefront UAG DirectAccess: Application Compatibility Table

I don’t believe that Microsoft are planning on providing a list of known DirectAccess application compatibility issues and their respective solutions or mitigation methods. Consequently, I thought it might be useful to create a blog post that captures known UAG DA application compatibility issues I am seeing in the forums and also from my own deployment experiences. UAG DA sometimes has the upper hand over native DirectAccess implementations here, as the option to utilise the in-built NAT64 functionality is potentially available, but this is not always a sufficient solution as the communication between DirectAccess clients and UAG will always take place over IPv6.

Tom has a great article on the subject of DirectAccess Application Compatibility which I am going to reference as a good primer for this subject; it can be found here. The TechNet information available here is also useful background reading.

UPDATE: I was recently made aware of a TechNet article titled IPv6 Support in Microsoft Products and Services which may also be a useful reference. The TechNet information is available here.

UAG DirectAccess Application Compatibility Table

Application or Product Name Application Vendor Application Version Known Issues Known Solution or Mitigation Techniques
Office Communication Server Microsoft 2007 and 2007R2 OCS client does not support IPv6
NAT64 not possible.
Deploy an OCS edge solution and define NRPT exemption rules for OCS related host names to use the Internet facing OCS edge solution. More info here.
Lync Microsoft 2010 Lync client does not support IPv6
NAT64 not possible.
Same as above for OCS. Upgrade to Lync 2013 which fully supports IPv6.
Metaframe, XenApp Citrix 6.x and below Citrix client does not support IPv6.
NAT64 to Citrix servers is not possible.
Deploy an internal Citrix Secure Gateway (CSG) solution or define NRPT exemption rules to use an Internet facing CSG solution. More info here.
FlexNet Manager Flexera Software Unknown Product does not support IPv6. Host application using RDS RemoteApp, Citrix XenApp or use an SSTP/VPN fall-back method. More info here.
SAP GUI SAP 7.20+ Support for IPv6 is not enabled by default. Add a client system environment variable of SAP_IPv6_ACTIVE=1.
To be able to do load balancing you will also need to install SAPRouter. More info here.
Lotus Notes IBM 8.0+ Support for IPv6 is not enabled by default. Add the TCP_EnableIPv6=1 line to the [notes] section of the notes.ini file.
More info here.
vSphere Client VMware 4.1 Unable to resolve hostname errors when trying to open virtual machine consoles. This has been fixed in vSphere client version 5.0 update 1 and later.

Information last updated: 21st January 2013

I aim to amend the blog post at regular intervals to try and keep the information as up to date and dynamic as possible. This should then provide a reference location that people can refer back to when thinking about potential application compatibility issues, or when new solutions are found.

So, if you have problems with application compatibility when using UAG DirectAccess, please email me (my email address is provided on my blogger profile page here) or use the comments option at the bottom of this post. Please provide as much information as possible, ideally including the following minimum information:

  • Application or Product Name
  • Application Vendor
  • Application Version
  • Brief overview of the impacted functionality or problem
  • Known solution or mitigation technique/workaround

Community input would be of great value here, so please do provide feedback where possible! Additional comments and corrections to keep the table as accurate as possible are also welcome…

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

Wednesday, 29 September 2010

Microsoft Forefront UAG 2010 Administrator's Handbook – Shameless Plug!

Just a quick note to promote Ben and Ran’s upcoming Microsoft Forefront UAG book!

Overview: This book is the first to be dedicated solely to Microsoft Forefront UAG. It guides you step-by-step throughout all the stages of deployment, from design to troubleshooting. Written by the absolute experts who have taken part of the product’s development, official training and support, this book covers all the primary features of UAG in a friendly style and a manner that is easy to follow. It takes you from the initial planning and design stage, through deployment and configuration, up to maintenance and troubleshooting.

The book has been written by two friends and colleagues at Microsoft who I have had the great pleasure of working with as part of the Microsoft MVP programme and via the Microsoft TechNet forums.

Happy reading folks!

More information on the book can be found here: https://www.packtpub.com/microsoft-forefront-uag-2010-administrators-handbook/book

Wednesday, 18 August 2010

Should I Place Forefront TMG at the Edge of My Network?

Is Forefront TMG trustworthy?

Given that ISA is a EAL4+ certified firewall and that TMG is on the way to the same thing, and the decade long history of a firewall that has never been the focus of a successful, documented attack, I'd say you're in good shape for putting TMG at the network edge if that's what you want to do.

Is it all about security? 

As good as TMG is (and secure too) there are still some limitations with regard to NAT functionality that are often bettered by traditional network firewall vendors. There are some good improvements with Enhanced NAT in TMG, but you may be left wanting when it comes to full NAT control. Some of the changes in selection of source IP address introduced in Windows Server 2008 don't help either, as covered in the following article: http://support.microsoft.com/kb/969029/en-us which may not provide expected or wanted results. Consequently, there may be some advantage of placing another network device (border router or firewall) at the network edge, in front of TMG.

I always believed in placing ISA/TMG closest to the assets you want to protect, so its role as a back-end application firewall is often the most useful. Some folks are comfortable with a single-tier application level firewall (e.g. TMG at the edge) but many aren't and look for at least a two-tier firewall topology. Is this better? Not sure, but they often feel they have "covered their arse" anyhow by following a more defence in depth approach. 

The other element to consider is that people don't hack firewalls anymore; they hack applications. Consequently, good firewall protection is about protecting at the application level. A front-end "network" firewall can be handy for noise reduction and enhanced network functionality (like more advanced NAT perhaps) but often the application firewall behind it is actually doing most of the heavy lifting. Many times, the front-end firewall only ever sees encrypted incoming connections (SSL/TLS) to which it has no understanding, and hence provides pretty low security value. If you combine UAG or DirectAccess into the mix, the front-end firewall becomes even more clueless, as all the clever stuff happens behind it... 

With the advent of UAG DirectAccess and the need for public IPv4 addresses on the UAG external interface, I think many more people will (perhaps not always knowingly) put TMG on the edge (by placing UAG at the edge) as they have limited options with regard to meeting the DA public addressing requirements. This should consequently build confidence that Microsoft have a product which "they the customer" believe can be trusted in that role/location. More on this in a future blog post…

Is an appliance version of Forefront TMG more secure?

Finally, the use of a hardware platform (like the Celestix MSA range perhaps) shouldn't really change the overall risk and edge placement assessment, as this is a platform choice, not a security choice, and you should go that route for other reasons than improved security protection. Well, unless you believe that a "hardware device" is better than a "software firewall" that is ;)

Summary

I also not sure there is a right or wrong answer here, as peoples acceptance of risk varies greatly. Assuming you are happy with the native network level feature set of TMG (and potential limitations) I see no reason not to place it at the network edge, but as is often the case, your mileage may vary! :)

Thursday, 29 July 2010

Important Update to the ‘How to Configure ISA SSL Bridging for System Center Configuration Manager Internet-Based Client Management’ Documentation!

There is a lot of talk about the remote management capabilities of DirectAccess and there is no doubt that this is the future of Microsoft’s remote access strategy. However, for environments that are not running Windows 7 Enterprise/Ultimate client systems or who need to manage non-corporate (read non-domain joined) clients, then the DirectAccess solution may not be possible or appropriate. Other factors may also prevent the use of DirectAccess for some reason I can’t think of right now!

In these scenarios, it is possible to use technology provided by the System Center Configuration Manager (ConfigMgr) product and a feature called Internet-Based Client Management (IBCM). This feature allows external clients to securely connect to ConfigMgr in order to manage them as if they were connected to the LAN (doesn’t that sound familiar!). You can find more details on IBCM here. This is not quite the full capability provided by DirectAccess connectivity, but is still very worthy of consideration…

Some of the updates are a direct result of my feedback to Microsoft on real-world usage of the solution, especially when customers are running internal deployments of Windows Server 2003 Certificate Services or Windows Server 2008 Active Directory Certificate Services (AD CS) and a feature called Autoenrolment. It is great to see the document evolve and also provide customers with a realistic solution that is fully supported and tested by Microsoft. I have greatly enjoyed working with the folks involved (you know who you are!) and feel that the time invested is very worthwhile…

The updated article can be found here or you can read more about the specific document updates in the ConfigMgr Team Blog.

Wednesday, 21 July 2010

What Happens When a Forefront TMG Array Manager Fails?

Forefront TMG Enterprise Edition introduced the concept of a new array called the Standalone Array. This technology is based upon the old locally installed Configuration Storage Server (CSS) model and does not require the use of a dedicated management server. Unlike the existing model, there is now the concept of an Array Manager server and other array members are termed Array Managed servers. Only one array manager can exist within an array and this essentially becomes the master configuration owner.

A common question to ask (as people did with ISA Server 2006 EE and the CSS role) is What happens when the array manager fails or is offline for some other reason?

With the array manager offline:

  • The remaining Forefront TMG array managed servers will continue to operate and provide full firewall functionality using a locally cached version of the Forefront TMG configuration/policy.
  • The remaining Forefront TMG array managed servers will not enter Lockdown Mode due to the lack of an array manager as should operate normally.
  • You will not be able to access the Forefront TMG configuration or connect to it using the Forefront TMG Management console. Consequently you cannot make changes to the firewall policy or monitor the Forefront TMG environment, amongst other administrative tasks provided by the console.

When the array manager comes back online:

  • The remaining Forefront TMG array members will synchronise with the array manager to obtain updated local cache configuration.
  • You will be able to access the Forefront TMG configuration and connect to it using the Forefront TMG Management console from the array manager or the array managed servers.

When the array manager cannot come back online, or is going to be offline for a long period of time, it is probably unacceptable to lose access to the Forefront TMG configuration or be unable to connect to it using the Forefront TMG Management console. In this scenario, the recommended option is to designate an existing, fully functional array managed server as the new array manager. This is achieved using the Set as Array Manager link from Tasks tab of the Forefront TMG Management console.

This process is documented here and appears to be a simple task. However, this document does not cover the expectation of the administrator when it comes to actually performing the procedure on the following counts:

  • In reality, the process involves some considerable time delays where it is easy to think that the process has stalled or hung.
  • It does not cater for the fact that you may be using a workgroup deployment which requires the administrator to assign SSL server certificates to the array manager as part of the process.
  • The array name remains unchanged and will show the computer name of the existing array manager, not the current array manager computer name.
  • What happens if you start the existing array manager once you have designated a new array manager, or you want to bring the array manager back online as an array member.

So, I thought it would be useful to document this process with a real-world slant with a basic walkthrough…

The example environment I will use is the same as that used for my Workgroup Deployment with Forefront TMG Enterprise Edition series of articles, namely:

image

Where TMG03 is the array manager server and TMG04 is the array managed server. As this environment is based upon a standalone array for a workgroup deployment, this also allows us to see the additional steps required for this scenario (which is handy).

So, assuming that TMG03 has failed or is taken offline, we will need to designate TMG04 as the new array manager as shown below.

Starting the Forefront TMG Management console on TMG04 you will notice that you receive the following error as the existing array manager (TMG03) is not operational:

2010-07-15_1147

After clicking Continue it will take a long time for the console to load. From my testing this could take up to 3 or 4 minutes before the console is accessible. For many people, this is an unexpectedly long delay and it would be common place to assume the process has stalled or hung. However, please be patient!

2010-07-15_1148

 2010-07-15_1153

Once the console has loaded, there should be an option under the Tasks tab for Set as Array Manager as shown below:

 2010-07-15_1152

If you are using a workgroup deployment (as per our example environment) you will see the following prompt:

2010-07-15_1154

In order to designate this server as the new array manager, you will need to have created an SSL server certificate that can be used for workgroup authentication. In our case, the certificate will need a common name of TMG04.dmz.com as discussed in previous workgroup articles. The above prompt assumes that this certificate is available in an exported PFX file format with an associated password. Once you have selected the appropriate PFX file and entered the correct password, the Setting this server as the array manager… process will begin:

2010-07-15_1154_001 

Please Note: If you receive an error that the ISASTGCTRL service cannot be started, it may be necessary to reconfigure this service to use a startup type of Automatic as opposed to the default startup type of Disabled.

Once completed, you should now see the the console connected to the local Forefront TMG configuration storage server which contains all previous configuration and settings; TMG04 is now the new array manager:

2010-07-15_1335

2010-07-15_1336_001 

A quick look around the console should confirm that TMG04 is now the array manager and the Forefront TMG configuration is synchronised:

2010-07-15_1337

2010-07-15_1409

2010-07-15_1335_001

If you have an array with more than two array members, it will now be necessary to configure remaining array members to use the new array manager with the Change Array Manager option available on the Tasks tab of the Forefront TMG Management console.


Once you have designated TMG04 as the array manager, in the event that TMG03 is brought back online it will no longer be able to participate in the array and Forefront TMG will need to uninstalled, reinstalled and then rejoined to the array now managed by TMG04. It will also be necessary to delete the existing TMG03 server object from the Servers tab of the System node (on TMG04) before attempting to join the array and also remove the TMG03 entry from the Managed Server Computers computer set (on TMG04).

Hope this helps!