Two questions that come up often with regards to UAG is its support for the following two scenarios:
1. Publishing Office 365 (O365)
2. Accessing a UAG trunk that’s configured with ADFS authentication through mobile devices.
With the release of UAG SP2, several customers have misinterpreted the release notes that were included with it, and concluded that with SP2, UAG supports these two scenarios. However, this is not the case. The release notes read:
Improved Active Directory Federation Services 2.0 support You can provide remote employees and partner employees with access to published applications that have AD FS 2.0 enabled. For example, you can do the following:
· Use AD FS multi-namespace support: Multi-namespace support for AD FS 2.0 lets you use a single AD FS 2.0 server that has multiple Forefront UAG trunks when the fully qualified domain names (FQDNs or public host names) of the trunks are in different domains. For example, the FQDN of the first trunk is portal.contoso.com, and the FQDN of the second trunk is portal.fabrikam.com. Both trunks can be configured to perform AD FS authentication by using the same AD FS 2.0 server (sts.contoso.com). In this kind of deployment, the AD FS 2.0 server is published through one of the Forefront UAG trunks or by an AD FS proxy that is parallel to Forefront UAG.
· Use the AD FS proxy to publish the AD FS 2.0 server: Publishing the AD FS 2.0 server by using an AD FS proxy has many advantages over publishing the AD FS 2.0 server through Forefront UAG. These advantages include support for Office 365 authentication and mobile devices.
· Enable complex topologies: You can use Forefront UAG to publish a SharePoint website that is located in one site when the AD FS server is located in another site.
The placement of the highlighted paragraph in the middle might be confusing to some, but what it really means is really simple. In the context of that paragraph, “use the AD FS proxy” refers to the AD FS proxy role that is part of Windows Server. This role was built into Windows Server for the purpose of allowing organizations to publish ADFS to the public internet. UAG, when hosting a trunk with ADFS authentication, serves as an ADFS proxy too, and so these are two distinct ways of publishing ADFS. Each has benefits and limitations, and every customer can choose the one that best suits his needs. This is the ADFS proxy role in Windows Server 2008 R2, if you’ve never seen it:
So, what this important paragraph in the release notes say is that using the ADFS proxy role in Windows has certain advantages over using UAG as an ADFS proxy. These advantages are that the ADFS proxy role supports Office 365 authentication and mobile devices, which UAG does not support. In other words, if you need to deploy ADFS with O365 authentication, or want to provide access to mobile devices to ADFS-authenticated applications, UAG cannot support this, and you should use the ADFS proxy role in Windows Server instead. On the other hand, the ADFS proxy role doesn’t provide you with some of UAGs features, such as the portal, endpoint detection, SSL-VPN etc.
Another topic that’s close to this is mobile device detection. If you’ve been using UAG with ADFS authentication for a while, then you may have noticed that earlier versions of UAG would allow some mobile devices to login to ADFS trunks, while later versions of UAG would block them with the message “A mobile device user could not be signed in because the site uses federated authentication”. Indeed, earlier versions of UAG would allow some clients in, but not because it was supported. The reason is that the detection module that identifies mobile devices was created earlier than many current mobile devices. As a result, UAG is simply unable to detect that these devices (such as an iPad, for example) are mobile devices. Updating the detection module in SP2 (and more in SP3) allows UAG to correctly detect most current mobile devices on the market, and block them, as it should. Some customers might wish to avoid installing SP2 in order to avoid having these devices blocked, but I must point out that failure to detect doesn’t mean these devices are supported. These clients may be able to gain access to older versions of UAG, and some functions might work, but others will not and this will inevitably lead to issues and dissatisfaction. On the same note, editing the detection module (by editing the web.config file on UAG), while supported in itself, is not supported for the purpose of hacking around the ADFS blocking. Editing the detection module is designed to allow proper detection of devices so that the proper UAG portal may be displayed to them and not as a means of bypassing UAGs design limitations and support boundaries.
"On the same note, editing the detection module (by editing the web.config file on UAG), while supported in itself, is not supported for the purpose of hacking around the ADFS blocking. Editing the detection module is designed to allow proper detection of devices so that the proper UAG portal may be displayed to them and not as a means of bypassing UAGs design limitations and support boundaries."
Will mobile devices ever be supported in a uag adfs scenario, or is it a limitation of the mobile devices thats preventing this?
What is the exact reason UAG is not supporting mobile devices? Is there a security risk involved? Does it have to do something with the NLSessionSTRUNKNAMEPersistForOffice cookie?
We have a trunk on UAG that identifies the users through AD FS 2.0, which is still published by a Microsoft ISA server. So on UAG this has nothing to do whether AD FS is published through UAG or not.
I also wonder why "Accessing a UAG trunk that’s configured with ADFS authentication through mobile devices" is not supported. Can you offer any clarity?
A fellow Ben