Category Archives: Office 365

Office 365 and MFA in AD FS 2016 (TP4)

March 11, 20162FA, AD FS 2016, AD FS 4.0, MFA, Multi-Factor Authentication, Office 365, Powershell, Relying Party, Windows Server 2016AD FS;ADFS;ADFS 4.0;ADFS 2016;MFA;2FA;O365;Multi-Factor Authentication;Office 365mylo

I recently added my O365 tenant, for testing purposes, to a AD FS in Windows Server 2016 TP4 and noticed something rather unusual. Via the AD FS Management snap-in it was not possible to assign an access-control policy in AD FS to my Office365 Relying Party (RP). Looking at my RP Trusts, I could see the Access Control Policy section was blank.

Right-clicking over a Relying Party in AD FS 2016 TP4 reveals an additional menu option for editing Access Control Policies:

Doing this on the O365 RP, only the Issuance Authorization Rules pipeline is visible, nothing else.

If we compare that with a normal RP.

Right-clicking and selecting access control policy, the administrator is presented with the option of choosing an appropriate policy for that RP: in our case, the desire to use multi-factor authentication.

Why this does not appear on the O365 pipeline, I can only speculate. It might be partially explained by the fact that creating the Office 365 Identity Platform relying party is normally performed via PowerShell and Microsoft wanted to keep this procedure ubiquitous across all versions of AD FS since v2.0. For example, the following command will create the Office 365 Identity Platform RP should it not exist.

Update-MsolFederatedDomain -SupportMultipleDomain -DomainName mydomain.com

Alternatively, following the principle of Occam’s Razor, it could be Microsoft have simply not got round to updating their code to detect AD FS 2016 during O365 Relying Party creation Smile Either way, from previous experiences of using MFA under Office 365 via AD FS 2012 R2, we do know it IS possible to use MFA with O365, so getting it working with AD FS 2016 just requires a little more effort. ..

Looking at our O365 RP in PowerShell (Get-ADFSRelyingPartyTrust) , we see no access policies configured. Under the O365 Relying Party it’s blank.

Compare this to an RP that does have an access control policy configured:

Since the UI doesn’t allow enabling MFA in an access policy for our O365 RP, playing around with PowerShell reveals that it is possible using the Set-ADFSRelyingPartyTrust cmdlet .

Set-AdfsRelyingPartyTrust -AccessControlPolicyName ‘Permit everyone and require MFA’ -targetidentifier https://login.microsoftonline.com/extSTS.srf

Check the O365 relying party (Get-ADFSRelyingPartyTrust) that an Access Control Policy has been added.

In the GUI, we then see the applied policy (Permit Everyone and require MFA) appearing.

Connect to Office 365 and we’re redirected to our AD FS instance. Enter the AD credentials for the user and then MFA kicks in:

As ever, play and test at your own peril Smile

Automated Update of Federation Metadata with Office 365

July 1, 2012AD FS 2.0, Office 365, Powershellmylo

Another Powershell script from the ADFS team that makes life a little easier.

http://gallery.technet.microsoft.com/scriptcenter/Office-365-Federation-27410bdc#content

When the token signing certificate of your home AD FS organization expires, then federation metadata between AD FS and Office 365 falls out of synch. Equally, when changes are made on the Office 365 that require updating the metadata, a similar issue arises. The script provide by the AD FS team checks the that federation metadata is validated regularly and any changes replicated between the two federating parties.

What does the script do? It calls the Update-MSOLFederatedDomain cmdlet and updates the settings in both the Active Directory Federation Services 2.0 server and Office 365. It also adds an item on the task scheduler queue:

It’s worth bearing in mind that the password policy that is being applied to your organization (Enterprise or Standard O365) will render the script unusable in the event of a password change on either the O365 side with the account you specify and the Domain side with the user account used to initiate the scheduled task. It is possible to create service accounts to do this on both sides. However, I’d consider the security consequences of such a change before automatically doing so. This can be done on the O365 side with an Office 365 standard account via the Set-MSOLUser cmdlet. For example,

Set-MSOLUser –identity user@mydomain.com –PasswordNeverExpires $true –StrongPasswordRequired $true

The account could also technically be a federated account, but I don’t believe that’s a good idea. In the event that the trust is broken, then a federated account won’t be able to connect to MSOL to update the federated domain information Smile

On the AD side, a more suitable compromise may be found by using a least privilege account for the task service account.

TMG 2010 and Office 365 Single Sign Out with AD FS 2.0

July 1, 2012AD FS 2.0, Forefront TMG, Office 365mylo

A while back (June 2011), I wrote a post on how to implement TMG, Single Sign-On (SSO) and strong authentication with Office 365. It was, as it turns out, an incomplete story.

Tristan Watkins has written an excellent article on how to implement single sign-out using TMG with Office 365 and ADFS 2.0. It goes into great detail about issues with sign-out from non-federated proxies with ADFS/O365 and explains the various nuances associated with Office 365 sign-in…. you can read this article here:

http://tristanwatkins.com/index.php/office-365-single-sign-out-isa-tmg-adfs-proxy/

AD FS 2.0 Client Access Policy Builder for O365

July 1, 2012AD FS 2.0, Office 365mylo

Those nice folks in the ADFS team have release a policy builder to simplify the creation of Client Access Policies for Office 365 in AD FS 2.0 Rollup 1 onwards.

Available here:

http://gallery.technet.microsoft.com/scriptcenter/Client-Access-Policy-30be8ae2

Enjoy..

Expiring AD FS 2.0 Token Signing Certificates

January 8, 2012AD FS 2.0, Office 365, PKI, Sharepoint 2010mylo

The above error surfaced recently when logging in at an O365 tenant. While the message itself is a fairly generic one, and can be attributed to a number of possible causes, in this case the organization (using identity federation) had an expired token signing certificate in their AD FS 2.0 configuration. They had automatic certificate rollover disabled on their AD FS farm so that AD FS could not rollover the configuration with new certificates. For some organizations, with web applications such as Sharepoint 2010, this may be a desirable configuration, with the process of certificate rollover being manually administered, rather than AD FS silently and automatically handling it.

Hindsight is a wonderful thing in this case and paying heed to warning messages about expiring certificates in the event logs in the preceding weeks may well avert some nasty surprises. However, calamities happen and should this problem evade your radar in the future, looking at what recovery options are available may be useful.

When the token signing certificate is due to expire (2-3 weeks before), the AD FS 2.0 Admin Event Log will begin to blurt out warning messages (Event ID:385).

AD FS 2.0 detected that one or more certificates in AD FS configuration database need to be updated manually because they are expired, or will expire soon. See additional details for more information

Additional Details:
Token-signing certificate with thumbprint ‘4E8F5194309E48EDB7EF8440B47082FB3D1594B6’ is set to expire on 12/30/2011 1:00:00 AM.

Should the warnings be ignored, and the certificate has expired, the Event ID 385 warning changes to:

Token-signing certificate with thumbprint ‘4E8F5194309E48EDB7EF8440B47082FB3D1594B6’ expired on 12/30/2011 1:00:00 AM.

At this point the AD FS wheels are wobbling and an Event ID 381 may start popping up:

An error occurred during an attempt to build the certificate chain for configuration certificate identified by thumbprint ‘4E8F5194309E48EDB7EF8440B47082FB3D1594B6’. Possible causes are that the certificate has been revoked or certificate is not within its validity period.
The following errors occurred while building the certificate chain:
MSIS2013: A required certificate is not within its validity period when verifying against the current system clock.

User Action:
Ensure that the certificate is valid and has not been revoked or expired.

This may be followed closely behind by Event ID 102:

There was an error in enabling endpoints of Federation Service. Fix configuration errors using PowerShell cmdlets and restart the Federation Service.

Additional Data
Exception details:
System.ArgumentNullException: Value cannot be null.
Parameter name: certificate
   at System.IdentityModel.Tokens.X509SecurityToken..ctor(X509Certificate2 certificate, String id, Boolean clone, Boolean disposable)
   at System.IdentityModel.Tokens.X509SecurityToken..ctor(X509Certificate2 certificate)
   at Microsoft.IdentityServer.Service.Configuration.MSISSecurityTokenServiceConfiguration.Create(Boolean forSaml)
   at Microsoft.IdentityServer.Service.Policy.PolicyServer.Service.ProxyPolicyServiceHost.ConfigureWIF()
   at Microsoft.IdentityServer.Service.SecurityTokenService.MSISConfigurableServiceHost.Configure()
   at Microsoft.IdentityServer.Service.Policy.PolicyServer.Service.ProxyPolicyServiceHost.Create()
   at Microsoft.IdentityServer.Service.SecurityTokenService.STSService.StartProxyPolicyStoreService(ServiceHostManager serviceHostManager)
   at Microsoft.IdentityServer.Service.SecurityTokenService.STSService.OnStartInternal(Boolean requestAdditionalTime)

As the original title graphic intimated, federated logon at this point is not working.

Depending on your AD FS configuration you may have automatic certificate rollover enabled. This can be checked via Get-ADFSProperties

In this particular case it was set to:

This meant that that once the signing token certificate expired, a replacement was not automatically assigned. In this case a new certificate needs to be provisioned manually. Of course, you could also elect to activate the autocertificaterollover function.

Preparing to make the change

Whether you elect to go the manual or the automatic route, in either case, you’ll still have some investigation to do. Before nuking your AD FS configuration, consider the impact of assigning / replacing the token signing/decryption certificates in AD FS.

Who are the claims providers and relying parties involved?
Can they process metadata?
What application specific changes are required to support the certificate change?

Of course, if you’re facing a production federation service outage then there’s likely to be other pressures to consider as well Smile , but try and determine which relying parties or claims providers will be able to process the details of the change (automatically) via updated federation metadata exchange or not. In the case of the latter, some sort of manual intervention may be required. Applications, for example, such as Office 365 and Sharepoint 2010 will need to be informed of this change.

Option 1: Manual Rollover

Via this method, you can generate your own certs using the Self-SSL feature built into IIS 7.x, or use Keytool, OpenSSL etc.. Alternatively, you may have your own internal PKI. I don’t see any benefit in using a third-party certificate for token signing encryption/decryption. No doubt someone out there may have a valid reason for doing so, but self-signed certs / internal PKI serve the purpose in this scenario. With IIS, under Service Certificates, I opted to create a self-signed certificate

Give the certificate a recognizable “friendly” name and IIS creates the certificate.

If you’ve elected to use an internal PKI, then there may be a certificate chain involved. Claims providers or relying parties will require a copy of the corresponding chain (.P7B) file or individual CA (.cer) files. The AD FS service account needs to be able to manage the private key of the certificate. This can be accomplished through the MMC Certificates|Computer snap-in. Right-click over the certificate:

Select Manage Private Keys and give the AD FS service account Full Control to the certificate. Now you need to prepare to make the change.

Option 2: Automatic Rollover

To configure automatic rollover:

Set-ADFSProperties -AutoCertificateRollover $true

To trigger an automatic replacement of the existing certificates the following needs to be entered.

Update-AdfsCertificate –Urgent

BEWARE! By selecting the urgent option you are voluntarily hitting the self-destruct button and hosing any working configuration. Relying parties and claims providers will not have refreshed their federation metadata with you and at this stage will be working against stale metadata. It is best, therefore, to carry out these activities out out-of-hours and co-ordinate with the parties concerned refreshing of metadata. As I discuss later in this post, some parties need manual intervention.

With the automatic rollover option selected, any existing token signing / decrypting certificates will be deprecated and replaced with a fresh one years’ validity alternate.

Exporting certificates to file

Once you’ve added a new token-signing certificate (manual route) or run the Powershell script to set automatic rollover you’ll need to export the certificate to file. Double click on the AD FS Token Signing certificate, click on the Details tab and then select Copy to File. The export format varies according to the target system. Windows systems will generally accept DER and Base64. If it’s a Java web container / application server then use Base64. Ditto with Linux/Unix…

In the examples below, I’ve used Office 365 and Sharepoint 2010 as two examples of web applications that need manual intervention.

Office 365 – MSOL

To rectify the problem of a token signing certificate change in Office 365, we need to update Online Services with new information concerning our certificate. As covered in the post here: https://blog.auth360.net/2011/10/15/ad-fs-2-0-rollup-i-multiple-issuer-support/ AD FS 2.0 now supports multiple UPN suffixes, so you’ll need to run this per UPN domain to update the respective information in Powershell.

$Cred=Get-Credential
Connect-MSOLService -cred $cred
Update-MsolFederatedDomain -DomainName mydomain.com -SupportMultipleDomain
Update-MsolFederatedDomain -DomainName yourdomain.com -SupportMultipleDomain

Substitute your own UPN suffixes with the examples above and the effect should be instantaneous and logon to MSOL possible once the update has been carried out. Run this through your test environment first to make sure you get the desired effect.

Sharepoint 2010

Sharepoint throws an error when the token signing certificate is invalid when accessing the Sharepoint Security Token Service at https://sharepoint.mydomain.com/_trust/

An operation failed because the following certificate has validation errors:\n\nSubject Name: CN=ADFS Signing – sts.mydomain.com\nIssuer Name: CN=ADFS Signing – sts.mydomain.com\nThumbprint: 611CBD4AE55FE2F2C3F0648C16C57A231AA51491\n\nErrors:\n\n The root of the certificate chain is not a trusted root authority..

In the above example, I triggered automatic certificate rollover on the AD FS side without notifying Sharepoint of the change and this threw an error (screenshot). To rectify this we’ll need to export the token signing certificate from AD FS instance and import it into Sharepoint 2010. We’ll then assign the register and assign the replacement certificate. This occurs at two levels:

Registering the certificate as a root authority. The certificate is self-signed and Sharepoint stores its own certificate trust hierarchy, outside of normal Windows conventions. This means that the self-signed certificate, effectively a root certificate, needs to be assigned as a Trusted Root Authority.
Updating the existing trusted token issuer. This means replacing the existing trusted identity token issuer value for the signing certificate with the new one.

The following Powershell script shows an example configuration.

$certPath = "C:\temp\ADFS Token.cer"
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("$certPath")

$root = New-SPTrustedRootAuthority "AD FS 2.0 STS" -Certificate $cert
$upd = Set-SPTrustedIdentityTokenIssuer -Identity "ENTER THE NAME OF YOUR EXISTING ADFS INSTANCE " -ImportTrustCertificate $cert

Your own configuration may vary and you’ll need to ensure that the identity to be updated is set correctly.

As ever TEST, TEST, TEST!!!!…..

AD FS 2.0 Rollup 1: Client Access Policy Support for O365

October 31, 2011AD FS 2.0, Office 365Office 365 Gridmylo

As I mentioned in a previous post, earlier this month Microsoft released an update for AD FS 2.0 on 12th October.

There are a few of us who have been waiting for client access policy support. Enterprise customers, in particular, will be a little happier with the options the enhancement offers. Client Access Policy support provides a means to restrict access by extranet clients to O365 resources. In particular, use of Outlook Anywhere outside of the organization can now be blocked, should your security policy require it and without this being at the expense of ActiveSync connectivity.

Note that changes to the Exchange Online environment come at the expense of Lync support:

"All client access policy scenarios have the effect of blocking external access to Microsoft Lync Online and Office Subscription Services."

Additionally, this approach is geared around limiting the user rather than the device, so at this moment we still cannot handle managed/unmanaged clients. Nonetheless, far be it from me to begrudge progress Smile … the fact that we are able to limit the use of rich clients such as Outlook to certain access conditions is good news.

Onto the new capability….

AD FS can now process new claims types sent by Exchange Online and then use these in acceptance transform rules with the O365 identity platform relying party. There are five new claim types:

X-MS-Proxy

Claim type: http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy

This claim is inserted by the AD FS Proxy, before passing the authentication request to the back-end AD FS server farm. For example, the servername of the AD FS proxy proxy.mydomain.local will be inserted into the X-MS-Proxy caller identity.

X-MS-Forwarded Client IP

Claim type: http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip

This claim is used for assisting in determining the IP address of the user, populated in the authentication request sent from Exchange Online, thereby allowing for limiting traffic to certain locations (e.g. corporate only). I’d suggest using some form of IP lookup tool to help determine where your IP/translation boundaries lie (this caught me when I discovered my “IP” was that of my upstream ISP).

X-MS-Client-Application

Claim type: http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application

For example, use to lockdown external access to just Exchange ActiveSync.

X-MS-Client-User-Agent

Claim type: http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent

This one is optional but allows targeting of the user agent header to further assist in determining which mobile device types are allowed within the organization. I didn’t try this, but I’d use this with care also because

the proliferation of different types of user agents
how this reacts to normal browser-based clients.
you can always use Exchange ActiveSync device policies for soliciting access to mobile clients.

X-MS-Endpoint-Absolute-Path (Active v Passive)

Passive clients are browser-based clients: Outlook Web App, Sharepoint Online, Office 365 Portal

Active clients are rich clients such as Outlook and ActiveSync.

Since Lync isn’t part of Exchange Online, Lync clients will not pass an endpoint absolute path.

Step 2 – Add five claim rules to the Active Directory Claims provider trust

You can paste the claim URL directly into claims rule itself as the document describes, but I decided that I might want to use these claims descriptions later, so for expediency I added them as claims descriptions for each of the five new claims identifiers described in the document. This can be accomplished through the AD FS 2.0 console under AD FS Service | Claims Descriptions using the Add a Claims Description option. Here’s an example for X-MS-Forwarded-Client-IP.

Once all five were added:

Time to add them to a Pass thru claim rule. For example:

Step 3: Update the Microsoft Office 365 Identity Platform relying party trust

On the relying party trust we create an Issuance Authorization Rule that is used to restrict actions based upon our specific requirements. In this case, the following limitation is to be applied.

Allow access to users to the Office 365 based on a certain set of criteria defined in the issuance authorization rule.

The interesting part of course is making all this work together: the various rule nuances/conditions and defining them according to the requirements of your organization. Let’s have a look….

EXAMPLE

In this test case, I wanted to deny Outlook Anywhere access to unauthorized users. Other functionality such as ActiveSync must continue to work, as must Outlook Web App and Sharepoint Online and Outlook Anywhere internally.

So, an Active Client (Rule 4:TRUE), using Outlook Anywhere (Rule 3:TRUE), not connected to the corporate network (Rule 2: TRUE), connects to Exchange Online from the Internet via the AD FS Proxy (Rule 1:TRUE) and if the (allowed) Group SID does not exist in the claim (Rule 5:TRUE) then the subject is DENIED access.

The group support is experimental and the documentation appeared to contradict itself. Scenario 4 states:

“The following example ……blocks access from clients residing outside the corporate network that have an external client IP address, except for those individuals in a specified Active Directory Group.”

And then the Descriptions of the claim rule language syntax section observes:

“This rule states that the only users in a particular Active Directory group (based on SID value) should be denied. Adding NOT to this statement means a group of users will be allowed, regardless of location.”

exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "{Group SID value of allowed AD group}"])

So which is it? From testing, if the Group SID (allowed) exists in the claim, then the client will be allowed access. If the Group SID does “NOT EXIST” then they will be denied access (all other rules notwithstanding).

AD FS 2.0 Rollup I : Multiple Issuer Support

October 15, 2011AD FS 2.0, Office 365mylo

As you may already know, update Rollup 1 for AD FS 2.0 is available. Big news if you’re an Office 365 user:

Multiple Issuer support (support for multiple UPN suffixes thus remedying issues described below)
- https://blog.auth360.net/2011/06/12/office-365-sso-and-ad-fs-2-0-namespaces-there-can-be-only-one/

It’s all described here:

http://support.microsoft.com/kb/2607496

What is not obvious from the above document is how one actually goes about setting up multiple domains. To work that one out you’ll need to read this post.

http://community.office365.com/en-us/w/sso/support-for-multiple-top-level-domains.aspx

In short, plan for this! The relying party for the Microsoft Online Identity Platform will need to be deleted, the federation trust for the existing AD FS realm updated with the –SupportMultipleDomain option, thus allowing support for (further) issuer/domain suffixes.

Thanks to Ross Adams from MSFT for the tip… this one had me scratching my head Smile

TMG Pre-Authentication Options with Office 365

September 3, 2011AD FS 2.0, Forefront TMG, Office 365Office 365 Gridmylo

Let’s have a look at some of the authentication methods/options that are possible with TMG, Federation and Office 365. I believe Microsoft at some point will expand on the supported TMG scenarios for O365 and how these options work in conjunction with AD FS 2.0. In the meantime, there are a few TMG front-end pre-authentication methods/combinations to try out with O365 and AD FS 2.0.

As the diagram above illustrates, TMG supports a number of authentication types. Let’s have a look at authentication combinations with TMG and AD FS 2.0 with the Office 365 suite as a relying party.

No Authentication

The basic reverse proxy scenario, or No Authentication scenario as I’ll refer to it, is described here on the Office 365 community site.

http://community.office365.com/en-us/w/sso/293.aspx

This is the only Microsoft-documented TMG configuration thus far for Office 365. The article provides an excellent starting point for configuring TMG with AD FS 2.0, so I’d recommend beginning with this configuration.

From a user experience perspective, using OWA as an example, the user may approach the web application through the Microsoft portal at https://portal.microsoftonline.com or directly via https://www.outlook.com/mydomain.com. Once the user hits AD FS, the user logon is processed according to whether:

If the machine isa domain member, the URL of the TMG (e.g. sts.mydomain.com) is in the trusted sites zone, and the browser is configured to automatically logon with username and password, then the user will silently logon to the on-premise AD FS and be redirected to their OWA mailbox
If the machine is not a AD domain member, or the URL of the AD FS is not in the trusted sites zone, the user will be challenged to enter their domain username and password (NTLM)

With no AD FS proxy present, the TMG is setup to reverse proxy traffic to the AD FS backend. The user request is proxied to the AD FS server and the AD FS picks up the logon request.

This scenario is called No Authentication as a reference to the fact that TMG isn’t performing any pre-authentication itself. It’s simple and doesn’t “interfere” with the federation logon process like the other approachesdescribed. It’s downside, one can argue, is that this approach may be less than satisfactory from a security perspective, with some form of pre-authentication at the edge more preferable.

For browser-based clients there are pre-authentication options with TMG, in conjunction with authentication delegation to the AD FS service that can be used. They are:

HTML Forms Authetnication
HTTP Authentication
SSL Client Certificate Authentication

From a Office 365 web application testing perspective (for browser-based applications), logon from the following apps was performed:

Outlook Web App
Sharepoint Online
Microsoft Office 2010 Clients (excluding Outlook)

HTML Forms Authentication

HTML Forms Authentication or Forms-based logon is likely familiar to most TMG administrators as it is often used in web publishing scenarios. The use enters their credentials via a form; username/password, One-Time-Password etc.

On the TMG-side, when configuring the web listener for HTML-Forms authentication, there are a number of authentication validation methods.

In this case we’re interested in seeing what authentication options are possible with the Delegation tab on the publishing rule and which ones are available according to the authentication validation method selected.

For a more detailed read on authentication methods versus supported delegation, refer to the following Technet article:

http://technet.microsoft.com/en-us/library/cc995215.aspx

Using Windows (Active Directory) as an authentication method, we can see on the publishing rule that a wide selection of delegation methods to AD FS are possible. For completeness, I tested a variety of HTML forms logon configurations using various authentication delegation methods:

I didn’t have an RSA Authentication Manager/ACE server in my sandpit so was unable to test SecurID.

Logon in the majority of pre-authentication scenarios using Forms Logon worked fine. Basic authentication didn’t work because the AD FS farm uses the default local authentication type of Integrated. Shifting Basic to the top of the pile in the AD FS web.config might have meant that basic delegation would have worked for forms-based username/password scenarios, but I can’t think of any reason why I would use basic delegation when integrated authentication (Negotiate) was available Smile

HTTP Authentication

With HTTP Authentication configured on the TMG (AD FS) web listener , the user will receive a challenge prompt rather than a form when the Office 365 relying party redirects the user to AD FS through TMG.

TMG then processes those logon details entered in the dialogue. Depending on the client authentication method we have selected (Basic, Digest or Integrated), there are typically fewer supported authentication validation methods against which credentials can be evaluated.

From a delegation perspective, I used the HTTP Basic Authentication method on the TMG side.

Results-wise, the majority of pre-authentication mechanisms involving TMG and various delegation scenarios worked. The same caveats concerning configuring web publishing rules, delegation etc. apply here.

Changing the client authentication method to HTTP Integrated Authentication on TMG were unsuccessful (so far).

HTTP Authentication with Digest was not tested.

SSL Client Certificate Authentication

SSL Client Certificate Authentication is an interesting approach as it logs the user on using an X509 certificate. I issued my client (in this case my domain user account) with a client certificate from a local issuing CA. If the incoming connection does not possess a client certificate, then TMG can be configured to fallback to HTTP authentication, e.g. HTTP Basic.

Once OWA had redirected the browser to TMG, a selection dialog requesting the client certificate for authentication was prompted.

After processing the client certificate, logon was completed and access to OWA given. Note that Client Certificate Authentication only supports Kerberos Delegation as a delegation method. This approach deserves a little more attention and I’ll look at how this works in a future post. In particular, I’m curious how smart cards would work in this configuration and/or with the TLSClient option in the AD FS backend.

Web Publishing Rules

On the TMG side, two publishing rules are required.

a web publishing rule for web applications that will use forms-logon such as Sharepoint Online, Outlook Web App, Office etc,
a web publishing rule for rich applications such as Outlook Anywhere, Lync Communicator Client and ActiveSync. that have special requirements.

Passive Clients: Outlook Web App / Sharepoint Online / MSOL Portal / Office 2010 (except Outlook)

Attached are the relevant screenshots for the Office 365 web applications that will use TMG for pre-authentication (forms-based logon).

The To: field in the publishing rule is important. In the above example, the computer name field contains myserver.mydomain.local, referring to the FQDN of the test AD FS server. In a highly available AD FS scenario where the admin wishes to use Kerberos Constrained Delegation, this field will be blank and the load-balanced URL and service principal name (SPN) of the AD FS federation service will need to be configured with the AD FS application pool service account (via the Delegation tab in AD Users and Computers)

The public name of the TMG matches that of the AD FS federation service and an (A) record is registered to the public IP of the TMG FBA listener.

We also need to specify certain paths for TMG as pre-authentication scenarios require two publishing rules, with the public URL of the AD FS service being shared across the two rules.

With forms logon example I’m using Kerberos Constrained Delegation. If Kerberos is to be used as the delegation method (recommended), ensure that the TMG computer account is trusted for delegation in AD Users and Computers, either for the AD FS server (single server scenario) or for the application pool (AD FS farm scenario).

We’re bridging SSL traffic as AD FS is HTTPS only.

The built-in All Authenticated Users group should be used in this rule, contrasting with the All Users group mentioned later in the Outlook Anywhere / EAS / Lync configuration section.

As the Office 365 wiki article mentions, AD FS 2.0 requires link translation to be disabled.

HTTP Filtering will also need to be modified to ensure that Verify normalization and Block high bit characters are disabled.

Let’s have a look at how TMG works for our non browser-based friends.

Active/MEX Clients: Outlook Anywhere / Lync 2010 Communicator / Exchange ActiveSync

As mentioned earlier, a second web publishing rule is required for certain “rich” clients. Active clients (Outlook/ActiveSync) and MEX clients in Microsoft speak, cannot be authenticated at the TMG. Instead, we must adopt the reverse proxy approach for selective paths to the AD FS service endpoints that can handle authentication of these clients.

The Active client uses a password proxy-based mechanism where the Office 365 Exchange service will authenticate against Exchange services on behalf of the client using Basic Authentication. We can see the WS-Trust service endpoint used on the AD FS service handler.

Conversely, the MEX client is a true federation web service (MEX = Metadata Exchange) that can perform authentication without the use of a “proxy”. This supports multiple forms of authentication. The metadata document for MEX clients is:

I’ve included the MEX above MEX path in the publishing rule for reference. It’s not mandatory. The actual service handler for authentication:

While this distinction is important in understanding how the client works, it makes no difference to TMG Smile We use the same publishing rule, with anonymous access through TMG for Active/MEX clients and a connection proxied to AD FS where the actual authentication is processed.

Configuring this second web publishing rule, be aware of the following key points:

All Users on the users tab is required rather than Authenticated Users (TMG is not authenticating)
Publish only the relevant service endpoints for Active and MEX clients through this rule (and optionally federation metadata)
Delegation is set to none but the clients may authenticate directly
All the other TMG configuration setup points are as is

Again, I’ve attached screenshots and hopefully they’ll assist.

The paths field needs to contain the AD FS service endpoints that are used by the Outlook client (/adfs/services/trust/2005/usernamemixed/*) and Lync (/adfs/services/trust/2005/windowstransport/*). The Federation Metadata (/federationmetadata/2007-06/*) and MEX endpoints (/adfs/services/trust/mex*) are optional (I use them for testing the publishing rule).

UPDATE: 05/09 – /adfs/services/trust/mex needs to stay in the web publishing rules otherwise connection problems may arise.

The clients communicate directly with the AD FS endpoints, so no pre-authentication via TMG is possible.

With the absence of authentication on the listener for the above paths, the All Users user set should be used rather than the All Authenticated Users user set seen in the previous rule.

Summary

I always finish these posts thinking I’ve forgotten something Smile … I did find this Technet article a useful reference.

http://support.microsoft.com/kb/2510193

A word of caution, aside from the usual test test test waiver I throw in, it’s important that you think of the use cases under which you intend to deploy this type of configuration. If there are other relying parties that are in use behind AD FS 2.0 then it will serve you well to test integration-wise whether these are affected. TMG is not federation-aware and we animate the logon process to federation services through credential delegation. While this works well enough in this scenario, TMG is effectively becoming the Internet proxy for AD FS activity.

Share your experiences and have fun testing!

Mylo

Just Another Relying Party: Federation with Forefront UAG 2010 SP1 and Office 365

July 27, 2011AD FS 2.0, Forefront UAG, Office 365mylo

I wrote in previous posts about some of the more unusual access scenarios involving Office 365 and UAG with AD FS 2.0. In doing so I’d not gone through and covered setting up a basic federated trunk scenario using UAG, AD FS 2.0 and Office 365. With this post I’ll attempt to remedy that.

In a normal O365 federated identity setup, UAG would be configured as a relying party to provide single sign-on to web applications at the edge. As a relying party UAG then processes security tokens issued by the AD FS security token service. For UAG admins, there is a key difference in the way UAG works with AD FS compared to other authentication services. Normally speaking, it is the UAG that is directly responsible for front-end authentication. Here, however, UAG adopts the role of an AD FS proxy and uses the AD FS infrastructure to provide the authentication and process the requisite claims required for single sign on to back end web applications. There is no authentication taking place on the UAG. This is borne out when we look at the web application configuration the for the trunk, with UAG configured like any other claims-aware application or relying party.

On the AD FS web application itself, we must allow unauthenticated access to the AD FS web server / farm

Additional authentication services cannot be used on the same trunk. Also, unlike the AD FS proxy, UAG does not provide a forms-based logon page. Instead it uses challenge/response. So a user who is accessing O365 from a non-domain joined machine can expect to an NTLM challenge response.

Because UAG does not process AD FS authentication, the request is proxied to the AD FS service in the backend using the Integrated Windows Authentication (IWA) handler. This can be seen in the redirect to https://sts.mydomain.com/adfs/ls/auth/integrated/……

Connecting to an Office 365 web resource from the Internet with a domain joined machine on the Internet, users can logon via IWA and get the single sign-on experience to the O365 resource when the STS is in the Local Intranet zone of the browser. Looking at Fiddler, one can see a kerberos service ticket in the negotiate header.

No Proxy-Authorization Header is present.

Authorization Header (Negotiate) appears to contain a Kerberos ticket:
60 82 06 38 06 06 2B 06 01 05 05 02 A0 82 06 2C `‚.8..+….. ‚.,
30 82 06 28 A0 30 30 2E 06 09 2A 86 48 82 F7 12 0‚.( 00…*†H‚÷.
01 02 02 06 09 2A 86 48 86 F7 12 01 02 02 06 0A …..*†H†÷……

From a non-domain joined machine, the fact that we’re doing IWA and and Negotiate means that it falls-back to NTLM (and the logon challenge/response)…..

No Proxy-Authorization Header is present.

Authorization Header is present: Negotiate
4E 54 4C 4D 53 53 50 00 03 00 00 00 18 00 18 00 NTLMSSP………
96 00 00 00 60 01 60 01 AE 00 00 00 00 00 00 00 –…`.`.®…….

Whether you like the idea of challenge/response over form-based logon is down to personal preference Smile

Office 365 SSO and AD FS 2.0 Namespaces: There can be only one…..

June 12, 2011AD FS 2.0, Office 365mylo

If you are an E3 customer and you’ve been setting up federated identities for Office 365 then doubtless you’ll be familiar with the following prose:

$cred=Get-Credential
Connect-MsolService -Credential $cred
Set-MsolADFSContext -Computer myADFSserver
Convert-MsolDomainToFederated -DomainName mydomain.com

This little bit of Powershell connects the (AD FS) organization to the Microsoft Online domain and converts a standard MSOL domain to a federated one…

Successfully updated ‘mydomain.com’ domain.

And the process completes…cue muffled screams of joyous rapture / sighs of relief (delete as applicable), as we have a federated domain ready for use with Office 365, with SSO to the corporate mothership (AD). For 90% of us this is a most satisfactory result and worthy of a few grunts of appreciation. However, for the 10% whose avaricious nature compels us to add more Internet domains / or we simply have a morbid curiosity that can only be satiated by trying to break things with O365, we decide to try the same command again:

Convert-MsolDomainToFederated -DomainName yourdomain.com

Convert-MsolDomainToFederated : The federation service identifier specified in the Active Directory Federation Services 2.0 server is already in use. Please correct this value in the AD FS 2.0 Management console and run the command again

At line:1 char:30
+ Convert-MsolDomainToFederated <<<< -DomainName yourdomain.com
+ CategoryInfo : InvalidData: (:) [Convert-MsolDomainToFederated], FederationException
+ FullyQualifiedErrorId : DomainLiveNamespaceUriConflict,Microsoft.Online.Identity.Federation.Powershell.ConvertDomainToFederated

Hmm.. this time round the very same command fails .. note that I’m adding a 2nd hypothetical domain called yourdomain.com… Looking at the Office 365 documentation for an explanation of why, a few pearls of wisdom are offered:

“Active Directory Federation Services only allows for one namespace per farm/instance”.

I’ll ghost the words “with Office 365” on the end of that. Apparently, this is an O365 beta issue that is, according to feedback from the forums, slated for resolution before go-live…… if you can’t wait, and need to add a second namespace, it entails standing up a completely new AD FS farm/instance in the meantime… an incentive methinks, if ever I’ve seen one, to move off bare metal and virtualise Winking smile

1:1 Trunk to AD FS 2.0 Farm

June 12, 2011AD FS 2.0, Forefront UAG, Office 365mylo

In recent posts, I’ve been flicking between two configuration states on two different trunks:

Federated Trunk A
Non-Federated Trunk B

I’ve been using two ADFS instances in the back-end, testing various combinations using the mythical sts.mydomain.com and sts1.mydomain.com endpoints.

There is one limitation that becomes very clear during testing:

an AD FS instance may be used by a single trunk only

AD FS instances cannot be shared across trunks. What !@#!.. that’s crazy!! Well, not really.. When you consider that UAG is proxying federation services endpoints, this does make a lot of sense. We cannot arbitrarily share instances of our federation service across different trunks, because that goes against the very nature of a federated trust. It can be represented in one and only one place. When we try and share the same service across multiple trunks, UAG chucks out the following message:

The AD FS authentication server ‘AD FS 2.0 …" is used in more than one trunk: TrunkA, TrunkB. Configure the UAG to use the AD FS 2.0 authentication server in one trunk only.

Which reminds me of something else I needed to post………………………

Federated Identities with UAG 2010 SP1 and Office 365

June 9, 2011AD FS 2.0, Forefront UAG, Office 365UAG 2010 Office 365 AD FS 2.0 Federation Active Directory Federation Servicesmylo

Following recent posts and discussions on the Office 365 forums, it seemed like a good time to look at integration between UAG 2010 SP1 and AD FS 2.0 and logon scenarios using Office 365 beta. Not much has been written about this to date, so I’ve been wading through the pre-production landscape of Office 365, trying to come terms with the complexities that these co-existence scenarios can bring.

Since UAG 2010 SP1, Microsoft have provided out-the-box support for AD FS 2.0. For Office 365 as a claims-aware platform, this gives us an opportunity for integrating UAG and AD FS 2.0 on-premise with Office 365 Enterprise web applications. UAG 2010 SP1 supports the WS-Federation passive profile, allowing for Office 365 web apps to be published through the UAG portal.

Microsoft highlight a number of integration topologies in their Forefront UAG 2010 SP1 with AD FS 2.0 documentation.

http://technet.microsoft.com/en-us/library/gg274298.aspx

From an Office 365 perspective, there are two topologies in the above link that had particular resonance for me in testing:

1. Remote employee access using claims

UAG is configured as a relying party for an on-premise AD FS 2.0 server (Resource Federation server in the diagram). Remote users authenticate to both the UAG trunk using and also the back-end application using claims-based authentication.

2. Remote employee access using non-federated trunk and federated application authentication

In this configuration, users connect to the UAG trunk using non claims-based authentication, for example, strong/two-factor authentication. They then authenticate to the published application using federated authentication. This configuration is the supported two-factor authentication that the Office 365 documentation alludes to. If the front-end authentication solution uses a separate user database from the Active Directory, then also consider that some form of matching shadow accounts are required within Active Directory (remember that AD FS uses AD as its authentication repository) to bridge access between front and back-end.

Why use UAG?

If you’re wondering what benefits UAG may offer with Office 365.

Support identity federation at the edge
Support claims-aware applications for SSO
Support for strong/two-factor authentication with Office 365 web applications
Replace the AD FS Proxy function
Utilize access policies for web-based applications
AD FS Single Sign-Out

There are some limitations that you should be aware of. When Microsoft refer to the WS-Federation passive profile, they’re talking about UAG and the browser, meaning Outlook Web App, Sharepoint Onlne and the Office 365 administration portal. The sign-in experience that we’re referring to in this post is with federate identities. In this scenario a user may access the Office 365 sign-in service. The service determines that the domain name referred to (via the UPN) is part of a federated domain and accordingly redirects the user to the on-premise Active Directory Federation Server (AD FS) 2.0 instance. Where UAG is in front of AD FS, this call is intercepted because the UAG is in-line for processing traffic.

Pre-requisites

There are a couple of pre-requisites for our UAG/O365 configuration.

AD FS 2.0 Single Sign-On for Office 365 has been prepared:
Directory Synchronization between the organization/Office 365 tenancy is active.
An AD FS 2.0 server/farm is available and configured in the corporate environment.
UAG 2010 SP1 is a member of the corporate Active Directory domain. *
The Federation Services Endpoint certificate (SSL certificate) used by AD FS has been exported and imported into the UAG computer certificate store. This will be assigned to the trunk.
The external (A) record for the AD FS service points to the UAG federated/non-federated trunk. For client hosting a HOSTS file will suffice initially.

* This option is not mandatory and one could argue against its use in the federated trunk scenario, as we’re doing full claims authentication, i.e. domain membership is not really necessary. For the purposes of this post, however, we’re using AD domain-membership to perform kerberos constrained delegation for the non-federated trunk configuration scenario.

Configure an AD FS 2.0 Authentication Server

Both UAG access scenarios require the services of an AD FS 2.0 authentication server. This can be done during trunk creation or, in this example, from the Admin menu, by selecting Authentication and Authorization Servers.

To create the relationshjp with AD FS 2.0, we must create an authentication server, obtain federation metadata from AD FS and then define the claim that will be used as the lead value (of interest).

Add an ADFS 2.0 Server. In the example below, I’ve created an Authentication Server calling Training, pointed it to the on-premise AD FS 2.0 Server / Farm at (https://mydomain.com/FederationMetadata/2007-06/FederationMetadata.xml). I then retrieved the metadata from this URL and then selected Name to be the attribute of interest.

NOTE: If you get an error while retrieving metadata stating “the Federation Metadata is signed, but the UAG server does not trust the certificate”, check that the Token Signing Certificate, if it is self-signed, is imported into the Trusted Root Certification Authorities store of the UAG. Alternatively, if there is a certificate chain involved, via an internal authority, ensure that the corresponding chain is imported. Any PKI CDP URLs for internal issuing authorities should be visible/reachable. You may need to edit the underlying TMG CRL Download System Policy to ensure it is checked.

Once the authentication server has been created, it can be referenced for usage within a trunk. This can be:

for front-end authentication, with the AD FS 2.0 server as a federated trunk
for federated back-end authentication, whilst using a non-federated trunk on UAG

I’ll cover the federated trunk configuration first and the hybrid configuration immediately after.

Federated Trunk (Remote employee access using Claims)

In this configuration we define the ADFS security token service (STS) as an identity provider and authentication server for UAG

Create a Portal Trunk
Assign the trunk a name (imaginatively called ADFS in this example)
Give the public host name the same name as the federation services endpoint URL (e.g. sts.mydomain.com)

In the example below I created a trunk with the name of ADFS

As the above summary screen warns, the UAG relying party must be configured in AD FS. This needs to the point to the UAG URL assigned by the wizard,. This URL must be the public (external) address of the (federated) trunk.

You can review the Advanced Trunk Configuration afterword, under the Authentication tab to confirm the configuration information for the UAG relying party necessary in AD FS.

For example,

Realm: https://sts.mydomain.com/InternalSite/ADFSv2Sites/ADFS

Federation Metadata: https://sts.mydomain.com/InternalSite/ADFSv2Sites/ADFS/FederationMetadata/2007-06/FederationMetadata.xml

The STS should be reachable through the internal DNS of your organization, i.e. UAG is configured to use internal DNS and not external DNS.

Configure AD FS 2.0

In AD FS 2.0 we need to add a relying party trust.

Start the Add Relying Party Trust wizard.
Import data about the relying party published online

Add the federation metadata endpoint described in the previous section. This needs to point to the (external) trunk. Before this will work you’ll need to create HOSTS file entry(s) on the AD FS server(s) pointing to the UAG federated trunk. This enables AD FS to resolve the address of the relying party. Remember that the UAG federation trunk URL is proxying traffic to the AD FS federation services endpoint (sts.mydomain.com) and internally that resolves to the AD FS farm/server(s). We need the AD FS to be able to reach and resolve the UAG address.

Having created the HOSTS file and successfully connected to the UAG relying party, we need to create a claim rule for the UAG. In this example, I’ve created a simple Pass-thru claim that passes thru the Name attribute.

Now we’re set to create an Office 365 web application… skip the next section and go to Configure an Office 365 web application.

Non-Federated Trunk (Remote employee access using non-federated trunk authentication and federated application authentication)

Non-federated trunk mixes authentication protocols between front-end and back-end systems, namely:

Front-End authentication using classic UAG authentication
Back-End authentication using claims-based authentication through AD FS 2.0

The initial configuration for this scenario should be familiar if you’ve used UAG or IAG before as we select one of the classic supported authentication protocols (e.g. LDAP, AD, RADIUS, SecurID etc). For the purposes of this article, the front-end authentication type (RADIUS/LDAP etc) that we settle for is not important.

In this example, I’ll be using a front-end authentication process through RADIUS. It helps for purposes of demonstration to choose a different front-end authentication provider, e.g. a 2FA OTP provider, from that of the the back-end provider (AD FS). In this setup, therefore, I’m using an OTP solution (Pointsharp ID) with software tokens.

Generating an OTP code from my smartphone, I enter my user ID and OTP to successfully complete the logon process. However, for this process to work correctly, we need to integrate AD FS 2.0 as a back-end authentication provider.

To setup AD FS 2.0 in a non-federated trunk scenario, we need to add it in UAG via the Add Application wizard. In this configuration, AD FS does not “live” on the trunk; rather, it exists as a web application.

From the Add Application Wizard, select the Active Directory Federation Services 2.0 template.

I’ve used the defaults here until Step 5. On the web servers screen fill out the details for the AD FS server/farm address. Enter the FQDN of the federation service, e.g. sts.mydomain.com

The server address (FQDN) and the public host name assigned must be the same.

On Step 6 – Authentication, leave the SSO checkbox unchecked, we’ll fill this in in a moment.

On Step 7 – Portal Link, leave the Add a Portal and toolbar link unchecked (we call the application implicitly through the published relying party web application).

Once the application has been created, enter the application properties and click on the Authentication tab. Check the SSO tab and change the radio dialog to Use Kerberos constrained delegation for single sign-on. AD FS uses an application pool identity for the farm AD account, so the http://* application SPN should be used.

NOTE: When AD FS 2.0 is configured for trunk authentication, you may notice the between the way that it is configured when non-trunk authentication is done on the front-end and claims authentication in the backend. In the latter configuration, as the above graphic indicates, we’re using Kerberos constrained delegation to trigger the logon process (to AD). In the federated trunk scenario, however, we’re doing pure claims-based authentication. In this configuration, the checkbox Allow unauthenticated access to web server is checked.

This actually does make sense. In the federated trunk scenario, UAG is in essence claims-aware and needs to allow unauthenticated proxy requests to reach the web server so that logon can be initiated.

Configure an Claims-aware application (Office 365)

To add a claims-aware web application within UAG, there are a number of steps involved:

Select a web application template
Define a name and type for the application
Define endpoint / access policies
Specify the address/location of the web server
Specify how (SSO) credentials are passed to the published application
Define whether the application will be shown within the portal

In this example, we’ll use Outlook for Web Access (OWA 365) as a sample web application. The inbuilt Exchange 2010 wizard doesn’t work in this scenario so we’ll create a web application using the portal trunk..

In the Applications window, click on Add to Launch the Add Application Wizard

At Step 1, Select an Application, choose Web | Other Web Application (Portal Hostname)

Give the application a name and select whether the endpoint policies you wish to enforce. I’ve used the defaults until Step 5 – Web Servers. In the addresses box here enter: www.outlook.com .

On Step 6 Authentication, check the SSO checkbox and select the AD FS 2.0 server created earlier as the authentication server.

In Step 7, enter the URL for your Outlook for Web Access 365 web application

In the above I’m using https://www.outlook.com/owa/mydomain.com as an example.

Summary

The processes described above support portal-initiated logon (via the UAG) and also relying-party initiated logon from the Microsoft online website itself.

As ever, please read the documentation on the Office 365 website as those gaps are being filled every day. Oh…and validate your single sign-on usage scenarios!!!

http://onlinehelp.microsoft.com/en-us/office365-enterprises/ff652538.aspx

As always, if you have any comments, corrections, questions or have some insight on this subject , please contribute!

Mylo

O365 and TMG with Strong Authentication (Part II)

June 2, 2011AD FS 2.0, Claims-based Authentication, Forefront TMG, Office 365mylo

Using TMG as a strong-authentication capable proxy for passive O365 clients and reverse proxy for rich/active clients

In the previous post I looked at configuring TMG to allow it to support both strong authentication of Office 365 (passive) web clients and at the time act as a reverse proxy for rich/active clients that use classical username/password for authentication.

Attached is a diagram highlighting the high-level communication flows associated with the previous post. I’ve emphasised the HTTPS traffic between the Federation Gateway and TMG for rich/active clients (the thick arrow), as it’s bi-directional in nature.

Unlike the passive client where all communication occurs through HTTP redirects, rich/active clients bounce around from server to server. This makes building a solution that supports multiple (strong/weak) authentication schemes difficult to implement and why, in the long term, customisation of the AD FS proxy pages may be the easiest route.

O365 and TMG with Strong Authentication (Part I)

June 2, 2011AD FS 2.0, Claims-based Authentication, Forefront TMG, Office 365AD FS 2.0, Forefront TMG, Office 365, Strong Authenticationmylo

This post looks at how TMG 2010 may occupy a role of hybrid AD FS Proxy for Office 365.

In previous posts on this blog we looked at using TMG as an AD FS 2.0 proxy .. When testing this back in Q4 2010, there was some uncertainty when testing (at least on my part), as to whether TMG as an AD FS proxy replacement was actually a supported configuration. Happily, it looks like these questions have been answered. In TechEd in Atlanta, the Office 365 deck on Identity and Access Solutions (OSP215) describes TMG as an alternative proxy offering for Office 365.

Here TMG substitutes the role of the AD FS proxy for corporate users using identity federation, with it being responsible for authentication of browser traffic (passive clients) coming from the Internet and traffic from Microsoft (active/MEX clients). One of the things about TMG is its flexibility and versatility. This was borne out in testing and it’s possible to support multiple flavours of access through a single web listener. For example, let’s say we need to support strong authentication for external / Internet-based clients using OWA 365 and Sharepoint 365, whilst at the same time we support internal/external users with rich clients, using conventional username and passwords, running Outlook and Lync. Let’s list those again:

Single factor (username/password) authentication for rich/active clients inside/outside the corporate environment… covering ActiveSync access from the outside, Outlook 200x from the inside/outside and MEX clients, such as Lync 2010 inside/outside
Single-factor authentication (username/password) for passive clients inside the corporate environment (OWA/Sharepoint)
Two factor authentication (2FA) for passive clients outside the corporate boundary (OWA/Sharepoint)

Inside the organisation, passive clients make use of the local AD FS 2.0 instance (rather than TMG), whereas Rich/Active clients use a more complex process . In fact, the latter makes for an interesting challenge, for any would-be admin, as the Microsoft Federation Gateway needs to call-back to the on-premise AD FS instance. Normally speaking, active and rich clients must, therefore, go through the AD FS Proxy for logon. In this post, we substitute the AD FS Proxy role for TMG, so that we may leverage capability that TMG can offer (I’m using the example of strong authentication).

The key to making this approach work with TMG lies in creating multiple web publishing rules, each with their own authentication requirements, using a single web listener. In doing so, we:

Create a web publishing rule that allows direct communication to the AD FS back-end for active and rich clients (effectively anonymizing authentication on the listener for the published paths in question)
Create a web publishing rule that triggers authentication (two-factor) on the TMG front-end and then uses delegation to the AD FS back-end using Negotiate authentication.

We are then able to support access requirements for both two-factor (external) logon from the browser, whilst also supporting the ability of single factor logon for active/rich clients, domain-joined and non-domain joined……..

There are a couple of tweaks in the TMG configuration necessary to ensure compatibility with AD FS 2.0…..

Disable Verify Normalization on the HTTP Filtering tab of each publishing rule
Disable Block High-Bit Characters on the HTTP Filtering tab of each publishing rule
Disable Link Translation on each publishing rule

Also, please ensure that:

DNS records for the AD FS Proxy point to the TMG web listener
A SAN or wildcard certificate is installed on the TMG listener with the appropriate FQDNs for the AD FS Federation Service endpoint (hint: export the certificate plus private key from AD FS and import into TMG)
Kerberos Delegation is configured for the AD FS Farm Application Pool Account or ADFS Computer Account (if the AD FS server is a single machine)

We create two publishing rules with the public name matching that of our AD FS 2.0 server/farm, sts.mydomain.com. :

Rule	Authentication Delegation	Paths	Users
#1	Kerberos Constrained Delegation	/adfs/ls/*	All Authenticated Users
#2	No delegation, but client may authenticate directly	/adfs/services/trust/2005/usernamemixed//adfs/services/trust/mex/	All Users

Rule #1 applies for the passive clients doing two-factor authentication on the web listener
Rule #2 applies for the rich/MEX and Active client profiles for Lync and ActiveSync/Outlook respectively.

The more restrictive rule (two-factor) should be applied first in the firewall list. As a general rule of thumb, let the TMG Logs and Reports tracker, together with Fiddler, help debug any protocol issues that may arise.

Next stop ….. UAG !!!!

(FOOT) NOTES

According to official documentation, Office 365 strong authentication scenarios include:

Two-factor authentication at Windows/Domain Logon
Two-factor authentication via Forefront UAG 2010 SP1 for web applications
Two-factor authentication via customized AD FS Proxy sign-in pages

If you have a fully-fledged public key infrastructure with smart cards, then you’re probably wondering what the fuss is about 😉

Option 2 looks promising.. However, after testing it and then reading and then re-reading the Office documentation, it appears that the working two-factor scenarios are limited to passive clients only (OWA/Sharepoint) and that Outlook and ActiveSync (O365) are not supported via UAG. Because a UAG server doing 2FA is acting as non-federated trunk, rich/active clients get stumped during authentication. Now, this may be possible to get working with some tweaking but it looks like some sacrifices would be required (e.g. disabling access policies on the trunk). I’m hoping I’m missing something here and some bright spark will put me right, part the clouds and show how it can be done Smile

Option 3 is very much possible if you’re prepared to roll up your sleeves and do some sort of customization of the ADFS Proxy sign-in pages to support 2FA, with your strong authentication vendor of choice. I’d expect to see some sort of progress from MS on this, given that Office 365 launches this month.

Getting this working through TMG was really the motivation for me here. If, as a prospective Office 365 customer, you have a requirement for strong authentication for external users, whilst at the same time you need to support traditional username/password logon internally, then maybe this option can assist..… as ever, your mileage may vary and please don’t deploy before testing this to death in anything close to production!

The Access Onion

Access Management and Identity Federation on a plate.