Hi folks. Welcome back to Part II of our first look at the new AD FS release in Windows Server 2012 R2. This one has been a while in the making and for those who have been waiting, thanks for your patience. This is a pretty long post and the longest to date. For the most part it emphasises what is new and good in the Windows Server 2012 R2 incarnation of AD FS, in particular concentrating on the authentication and UI changes in the latest release.

In the last post we looked at some of the new architectural changes in AD FS with Windows Server 2012 R2, such as the Web Application Proxy, Extranet soft lockout and a lightweight domain join facility, otherwise known as Workplace Join. In this post we’ll extend the look to some of the authentication/UI changes and how their application embraces a more conditional access approach and philosophy within the product.

In AD FS 2.0, customization of IIS and sign-in pages could be performed on both the AD FS Proxy and AD FS farm with authentication types being used configured in the web.config file of each.

The AD FS 2.0 proxy supported the following authentication types:

• Username and Password (Forms)
• X509/Client Certificate (including Virtual Smart Card/Smart Card Authentication)
• Basic Authentication

The AD FS 2.0 backend (farm) supported the following authentication types.

• Integrated Windows Authentication (IWA)
• Username and Password (Forms)
• X509/Client Certificate (including Virtual Smart Card/Smart Card Authentication)
• Basic Authentication

Authentication mechanisms carried over from AD FS 2.0 are now available under the banner of Primary Authentication in R2 and handled through the AD FS Management UI or via PowerShell. As with AD FS 2.0, native authentication assumes the use of an Active Directory-based identity and the built-in AD claims provider for authentication. Support for Basic Authentication, available in AD FS 2.0, has now been deprecated in R2.

Looking at the AD FS Management UI, we see an immediate difference over its predecessor with the inclusion of a new authentication policies pane.

In AD FS 2.0 the base proxy and farm configuration supported Forms and IWA logon types respectively. Any changes beyond that required adjusting the LocalAuthenticationTypes
methods used within web.config
files on proxy and farm nodes. The context-sensitive (proxy v farm) aspects of authentication now move to the UI/PowerShell. There is also support for multiple authentication types for a given authentication context, such as simultaneous support both Forms and X509 Certificate-based authentication on the external context handler.

Within the Management UI we may edit the Global Authentication Policy on the AD FS server to determine what authentication types we wish to support on the Primary authentication space and for internal/external user types.

These settings can also be modified via PowerShell. For example, the following command sets forms-based logon as the authentication type for both Extranet and Intranet logons on Primary Authentication.

Set-AdfsGlobalAuthenticationPolicy -PrimaryExtranetAuthenticationProvider {FormsAuthentication} -PrimaryIntranetAuthenticationProvider {FormsAuthentication}

An additional authentication provider, in the form of Multi-Factor Authentication (MFA), allows support for additional (stronger) authentication types. This auxiliary component represents a significant enhancement for sign-in scenarios under AD FS in Windows Server 2012 R2.

Under the previous release, native support for stronger authentication was limited to domain-joined clients using Smart Cards or Virtual Smart Cards, via the X509/Client certificate authentication handler. Third-party solutions materialised providing support for two-factor/multi-factor authentication in the federation logon process. How these were implemented varied per solution, but they typically fell into one of two basic categories:

1. Agent-based or non-federated solutions (typically) running on, or in front of the AD FS proxy, handling two-factor authentication (2FA) for external access.
2. Claims/Identity Providers trusted by AD FS.

If you’ve followed this blog over time or from own experience, you’ll know these approaches can have their own quirks: be they issues with cross-domain SSO, redirection, home realm discovery, flexibility, user experience etc., they often warranted some attention configuration-wise to get working under AD FS 2.0, where possible.

The R2 makeover overcomes some of these limitations by:

1. Expanding access capability within AD FS, making available more fine-grained “conditional access” decisions;
2. Improving login behaviour and user experience for sign-in scenarios;
3. Improving customization of sign-in pages / error-handling;
4. Including the option of a secondary MFA adapter (SDK) for vendors to integrate with, unifying the logon experience around AD FS itself.

Let’s have a look at more conventional access scenarios, using AD FS 2.0 as a reference point. We begin by seeing how the new authentication changes enhance options during logon. In AD FS 2.0, while we were able to change the preferred authentication type, supporting multiple authentication options was not possible without significant customization. An example is provided here for reference.

Customizing User Agent Behaviour

Under AD FS 2.0 Integration Windows Authentication (IWA) provided transparent SSO to domain-joined Windows clients connecting web resources that supported Windows authentication. However, IWA is not supported by all browsers and under AD FS 2.0 the fall-back authentication was NTLM.

The NTLM challenge/response dialogue often caused confusion for users. With AD FS in Windows Server 2012 R2, we can specify on the internal network which browser clients are allowed to use Integrated Windows Authentication (IWA) for transparent logon. This is done by modifying the supported user agents via the following cmdlet.

Set-ADFSProperties –WIASupportedUserAgents

Internal clients, using Internet Explorer 6.0 and above will default to using their Windows logon token (IWA) when connecting from the Intranet. All other browser agents, Firefox, Chrome etc. will revert to using forms-based authentication (FBA). If the user agent in question is added to a WIASupportedUserAgents list then IWA is attempted. This gives the IT Administrator greater control, whilst promoting a more user-friendly logon experience.

We can customize our own User Agent values to pass to AD FS. I had to dig around to work out how to set this value correctly because it’s not obvious what the settings in AD FS are at first glance. If we type Get-ADFS Properties, we can see some of the current user agent settings, with the remaining values beyond MSIE 8.0, being obscured from view.

The viewing properties are being limited by a setting known as $FormatEnumerationLimit in PowerShell. When we change the value of this to -1 we see the full user agent specification used.

$FormatEnumerationLimit=-1

We can then change the supported user agents by using the Set-ADFSProperties
cmdlet. I actually broke things at this point and my ignorance of PowerShell was to blame. As posters to Technet forums confirmed, the following syntax will not work:

Set-AdfsProperties -WIASupportedUserAgents (“MSIE 6.0”, “MSIE 7.0”, “MSIE 8.0”, “MSIE 9.0”, “MSIE 10.0”, “Trident/7.0”, “MSIPC”, “Windows Rights Management Client”)

It turns out that a string array is required and the user agent items need be in parenthesis and an @ included. Thank you PowerShell Pro. Reverting to the original configuration is possible by setting the following command and you can, of course, customize accordingly.

Set-ADFSProperties -WIASupportedUserAgents @(“MSIE 6.0”, “MSIE 7.0”, “MSIE 8.0”, “MSIE 9.0”, “MSIE 10.0”, “Trident/7.0”, “MSIPC”, “Windows Rights Management Client”)

If you’re propagating your own IE settings, e.g. via GPO, then these can be added to the list. If you’re using other browsers, besides IE, then it’s also worth considering turning off Extended Protection Authentication (EPA) / Channel Binding Token (CBT). This can be done via the following command:

Set-ADFSProperties –ExtendedProtectionTokenCheck None

Note the service restart request. Please note that EPA is intended as a protection mechanism against Man-in-the-Middle (MITM) attacks and as ever it’s a toss-up between usability and security. An overview can be found here.

Authentication Changes

Let’s look at an example of multiple local authentication types enabled. Here, Forms and X509/certificate authentication are enabled on the primary authentication provider for external (Extranet) access at the Web Application Proxy (WAP):

In a logon scenario, with both options enabled, the user is presented with the following logon screen:

The option to “Sign in using an X.509 certificate” is provided underneath the logon form. Logging on with username/password to a test claims aware web application, we see the normal forms logon behaviour as seen with the AD FS 2.0 Proxy, expressed through the use of the PasswordProtectedTransport value in the authnmethodsreferences
claim.

With multiple authentication types enabled, users can logon using the forms logon option or using an X509 mechanism, e.g. a client certificate or virtual smart card/smart card.

I’m using a Virtual Smart Card (VSC) as an example for the X509 access type. Clicking on the X509 hyperlink, using the VSC we see the following prompt.

f

I select the VSC for user mylo.

At the challenge prompt, the user must enter their PIN for that user, whereupon they gain access to the relying party.

Looking at the claims emitted at this point through our test relying party, we can see that AD FS recognizes that stronger authentication has been used (MFA) and via the http://schemas.microsoft.com/claims/authnmethodsreference claim, it issues the value of http://schemas.microsoft.com/claims/multipleauthn. More on this in a moment.

Multi-Factor Authentication (MFA) on the Secondary Provider

The previous example illustrated the use of both username/password and MFA through the Primary Authentication option. When we look at Multi-Factor Authentication (MFA) via an additional authentication policy rule, we can similarly use the native X509/Certificate Authentication provider. This implies the use of the AD username/password first as the primary credential, either via forms or IWA, according to your authentication policy rules, and X509 as the additional MFA credential.

There’s a distinction here also worth noting between AD FS 2.0 and R2 behaviour. With the former we could potentially invoke multi-factor authentication (MFA) through protocol mechanisms, such as via a wauth parameter in WS-Federation, or in the AuthnContextClassRef in SAML 2.0. In doing so we were able to call an upstream identity provider that was MFA capable, or if stronger authentication mechanisms were available on AD FS 2.0, using X509 certificates or smartcard variants. The options here, at this point though were fairly limited and called on extensive customization to support multiple authentication methods.

We can still use the protocol route in AD FS R2. In addition, Multi-factor authentication (MFA) can be triggered through both protocol and policy (new in R2) rules. For example, with WS-Federation the wauth=http://schemas.microsoft.com/claims/multipleauthn protocol parameter stipulates that the relying party requires invocation of MFA in the logon request (assuming this is enabled in the global authentication settings). This is the same claim type mentioned earlier during the smart-card logon process and is associated with the use of MFA.

When we invoke MFA as a policy rule on the AD FS R2 server, we’re in fact calling the additional authentication rules handler and this policy-based behaviour can be configured at both global and relying party levels.

In the UI, we can see the following options:

The use of conditional access rules provide a more controlled demeanour to AD FS in how claims-based authentication is applied. In this example, I’ll disable Certificate Authentication in the primary authentication slot (leaving forms enabled) and enable it instead as an MFA method globally. We can then call on this (secondary) authentication method as we see fit.

The equivalent PowerShell command is:

Set-AdfsGlobalAuthenticationPolicy –AdditionalAuthenticationProvider CertificateAuthentication

For this particular test, I’ll also enabled MFA as a requirement for external clients

When logging on to AD FS R2, we get the standard forms sign-in page. We now using two-step authentication using the primary and the additional (secondary) authentication types.

Logging on with a username and password, we’re then presented with an additional logon screen and a request to provide secondary (X509) MFA credentials.

Again using a Virtual Smart Card( VSC) and our mylo test user, we select the appropriate VSC identity and enter a PIN.

Looking at a test claims-aware Windows Identity Foundation (WIF) application, passing through all claims rules, we see the following detail:

The aggregation of authentication types used during the logon process can be seen through the use of the
http://schema.microsoft.com/claims/authnmethodreferences
claim. The first claims value seen in the screenshot is for urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport, indicating use of forms logon (username/password). The second and third references to tlsclient and x509 show that we’ve used a client certificate (in the form of the virtual smart card) during the logon phase. Finally, the last entry states that multi-factor authentication (MFA) has been used, reflected in the http://schemas\.microsoft\.com/claims/multipleauthn claim value. A similar claim value would also have been emitted if we’d used a third-party authentication provider registered as an R2 MFA provider. We’ll look at this later in the post.

When we log on with a Virtual Smart Card (VSC), we can also see the Enhanced Key Usage (EKU) of a certificate emitted in the claim.

Those of a PKI inclination will appreciate the benefits this may provide. We are able now, for example, to determine, via the EKU, whether a smart card was used in the logon process (1.3.6.1.4.1.311.20.2.2), as opposed to say a vanilla client certificate and we can stipulate that as an access requirement during logon. If your organization is using a custom organizational identifier (OID) then we may also consider moderating access based on different levels of assurance associated with the OID bound to a particular certificate template. This also offers some promising developments with technologies such as Authentication Mechanism Assurance (AMA), which I’ll cover in a future post.

The examples I use with smart cards are typically targeted at managed Windows (domain-joined) clients, who receive their configuration (certificates etc.) over the (local) wire through group policy (GPO) or scripts. Support for non-domain joined clients, however, is now also available to Windows 8.1 clients and enrolment can now be provided via certificate enrolment/policy web services.

For a more granular approach to MFA, desired authentication can also be targeted to specific relying parties. The conditions under which we apply the policy rules (AD group/user, location, device, authentication type) can be refined on per relying party basis, as seen in greater detail in the next section with the MFA Adapter.

The MFA Adapter

This is a new feature in AD FS R2 that allows third-parties to register their authentication provider as an auxiliary authentication mechanism within AD FS, whilst unifying the login/sign-in experience around AD FS.

To see how the MFA adapter works, the example user here is with Windows Azure Multi-Factor Authentication Server, formerly PhoneFactor. A tenant has been setup in Windows Azure, a pre-requisite, with the Azure MFA server plugging into the Azure cloud and the registered tenant. The MFA Server itself connects to AD FS through an installer that provides the necessary bridge between the AD FS MFA adapter/SDK and the Azure MFA Server.

I’ll skim over the details of installing the actual Windows Azure Multi-Factor Authentication server itself and look at integration of the AD FS plug-in.

The Windows Azure MFA server connects to the local organization Active Directory and synchronizes objects with it. Here we’re synchronizing objects under an OU subtree of Accounts/External in the imaginary “Azure Sprout” organization. A single container subtree is being synchronized.

Looking at the User section of the console we see some test users in an organization called “Azure Sprout”.

We’ll enable the training user for phone-call validation.

Within the authentication server console, there’s an AD FS section where the appropriate adapter can be installed.

If the MFA server is joined to the domain and the Active Directory configuration for securing communication between the ADFS Adapter and the Multi-Factor Authentication service is incomplete, the administrator must first complete the Active Directory integration setup, before the adapter can be installed. Once the adapter is installed, the desired multi-factor authentication methods can be then specified.

In the testing example here, the AD FS adapter has been installed on the Federation Server and via the console, the necessary AD FS integration binaries installed. This can also be done manually, such as when the server is installed on a remote machine. The AD FS binaries can be copied through the C:\Program Files\Multi-Factor Authentication Server path and installed via an MSI (MultiFactorAuthenticationAdfsAdapterSetup64.msi). When run the installer sets ups the necessary resource files and connectors allowing AD FS to communicate with the on-premise WZAA MFA instance.

A PowerShell script then needs to be run to register the Windows Azure MFA adapter within the local AD FS instance and make it available as an MFA option.

With the Windows Azure Authentication Server installed and the MFA adapter registered, a new authentication type becomes available, which we can then enable in the Global Authentication Policy for the organization.

The adapter is now available as an MFA authentication method. The Multi-Factor Authentication Server itself is bound to a Multi-Factor Authentication Service setup on my Windows Azure tenant.

Let’s have a look at some test scenarios using MFA.

In the above test setup are two AD FS instances, both on R2, representing two different organizations: “Access Onion” and an Azure-based setup called “Azure Sprout”. The “Access Onion” organization is hosting a couple of on-site SharePoint web applications. Apologies if the setup looks a little bit contrived, but I’m not at the stage yet where I’m prepared to fork out $$$ for moving certain “demo/test” resources such as SharePoint/SQL to the cloud, hence the dual on-premise and cloud combination J

Two SharePoint web applications have been setup as relying parties to test some MFA scenarios:

1. A Teamsite dedicated to “Azure Sprout” users resides in the “Access Onion” organization. For expediency, I’ve connected up the SharePoint Teamsite (teams.azuresprout.net) directly to the AD FS in the “Azure Sprout” organization to test direct trust access scenarios. The SharePoint teamsite (teams.azuresprout.net) in the “Access Onion” organization is setup as a Relying Party on the “Azure Sprout” AD FS instance.

    

2. A Teamsite for users in the “Access Onion” organization that also provides secure access to users from the “Azure Spout” organization. For “Azure Sprout” users accessing the SharePoint Teamsite, they are routed via the “Access Onion” AD FS instance, acting in the role of a Relying Party Security Token Service (RP-STS). A claims provider trust is setup between the trusting (Resource) “Access Onion” organization and the trusted (Account) “Azure Sprout” organization, with the AD FS RP-STS setup as a Relying Party in the “Azure Sprout” organization AD FS instance.

For testing, please note that:

• Users in the “Azure Sprout” have a @azuresprout.net
  domain suffix
• Users in the “Access Onion” have a @accessonion.net
  domain suffix.

We’ll look at various access scenarios that employ new functionality within the R2 release of AD FS and begin with the “Azure Sprout” Teamsite dedicated for that organizations use.

Scenario 1 : Access to the “Azure Sprout” Teamsite

This is a fairly straightforward setup. This Teamsite is only for “Azure Sprout” users and there’s a direct trust between the SharePoint web application, hosted in the “Access Onion” organization and the “Azure Sprout” AD FS organization. This setup is analogous (for this test) to that of a normal Web SSO setup. We wish to use local Windows authentication for “Azure Sprout” internal users and MFA for external users connecting through the “Azure Sprout” Web Application Proxy (WAP).

The AD FS R2 instance for the “Access Onion” organization is omitted from the diagram as its role is secondary, with the Web Application Proxy being used as a reverse proxy for publishing the SharePoint application.

Internal Users

Represented in the diagram by blue numbering, users connected to the “Azure Sprout” Intranet can connect using their Windows credentials.

1. The User accesses the “Azure Sprout” Teamsite within the “Access Onion” organization. This is published by the local Web Application Proxy as a Reverse Proxy rule. The SharePoint Security Token Service (STS) has been configured to use the “Azure Sprout” AD FS as a trusted claims provider.
2. The user is redirected to the “Azure Sprout” AD FS instance. Since the user is connected to the Azure Sprout LAN, this passes the request directly to the farm instance, whereby the user can logon with their Windows credentials. A relying party rule is configured for the SharePoint Teamsite and claims rules (Send LDAP Attributes as Claims Rules) configured to pass the requisite attributes.

   

   c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname”, Issuer == “AD AUTHORITY”] => issue(store = “Active Directory”, types = (“http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn”, “http://schemas.microsoft.com/ws/2008/06/identity/claims/role”, “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress”), query = “;userPrincipalName,tokenGroups,mail;{0}”, param = c.Value);
   

    

3. The user is redirect to SharePoint whereupon (assuming permissions have been granted to the SharePoint site) they gain access.

   

   Here’s the identity provider configuration used for the “Azure Sprout” teamsite.

   $map = New-SPClaimTypeMapping -IncomingClaimType “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress” -IncomingClaimTypeDisplayName “EmailAddress” -SameAsIncoming
   

   $map2 = New-SPClaimTypeMapping -IncomingClaimType “http://schemas.microsoft.com/ws/2008/06/identity/claims/role” -IncomingClaimTypeDisplayName “Role” -SameAsIncoming
   

   $realm = “urn:azuresprout:teams”
   

   $ap = New-SPTrustedIdentityTokenIssuer -Name “Azure Sprout” -Description “Azure Sprout SAML” -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map,$map2 -SignInUrl “https://sts.azuresprout.net/adfs/ls” -IdentifierClaim http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
   

External Users

Represented in the diagram by black numbering, the logon workflow works as follows:

1. The User accesses the “Azure Sprout” Teamsite within the “Access Onion” organization. This is published by the local Web Application Proxy as a Reverse Proxy rule. The SharePoint Security Token Service (STS) has been configured to use the “Azure Sprout” AD FS as a trusted claims (identity) provider.

    

2. The user is redirected to the “Azure Sprout” AD FS instance. Since the logon request is coming from an external user, the request is resolved via external DNS, pointing to the “Azure Sprout” Web Application Proxy. A pre-authentication rule is configured for the SharePoint relying party on the web application proxy.

   Add-WebApplicationProxyApplication -BackendServerUrl ‘https://teams.azuresprout.net/’ -ExternalCertificateThumbprint ‘D9433C468CDEDF6BCD645BC2DE143CD5B4ED108’ -ExternalUrl ‘https://teams.azuresprout.net/’ -Name ‘”Azure Sprout” Teamsites’ -ExternalPreAuthentication ADFS -ADFSRelyingPartyName ‘SharePoint “Azure Sprout” Teamsites’
   

   External Users need to use MFA. We configure this on the “Azure Sprout” AD FS farm by specifying the appropriate location/MFA combination on the authentication policy for the SharePoint Relying Party.

   Within the UI:

   

   Looking at this in PowerShell, this translates to an additional authentication claim rule of:

   c:[Type == “http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork”, Value == “false”]=> issue(Type = “http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod”, Value = “http://schemas.microsoft.com/claims/multipleauthn”);
   

   In other words, if the user is inside the “Azure Sprout” corporate network, then the MFA rule will not apply because the insidecorporatenetwork claim value returns a value of $true). The use of the http://schemas.microsoft.com/claims/multipleauthn claim value is then used to trigger MFA as part of the rule above.

   As discussed earlier the primary authentication type needs to be satisfied first. The user must log on with their “Azure Sprout” AD credentials. From the outside, the forms login handler is initiated for the (primary) initial logon type for external (Extranet) users.

   

3. Once the user has logged on with primary authentication, they must then logon with MFA. This is where the Windows Azure Authentication Server (MFA) provider comes into play. The user authenticates using their configured MFA type.

   

   In the test configuration, the setup is configured to allow the Windows Azure MFA server to ring the users phone to complete authentication. Once they click on the Continue button the call is initiated, based on the number derived from the mobile attribute of the user in the “Azure Sprout’ Active Directory (the AD attribute used can be customized). The user confirms the two-step authentication process by receiving the call and confirming with the hash/pound (#) key on their phone that a successful hook-up has occurred.

4. The user is redirect to SharePoint whereupon (assuming permissions have been granted to the SharePoint site) they gain access.

We may employ authentication fall-back processes where the MFA provider supports it. Windows Azure Authentication Server, for example, offers the use of security questions as such a mechanism during logon.

This sort of flexibility should extend to other MFA providers via the adapter and bring their own capabilities to the fore.

Scenario 2 – Accessing the “Access Onion” Teamsite

This scenario is more complex as we have to take into consideration access requirements from multiple sources, in doing so hitting common challenges for Federated SSO concerning multiple organizations, realm discovery and authentication. Before we go into the obligatory diagram, we’ll recap on Home Realm Discovery (HRD), as it has a particular resonance in this scenario.

There’s no place like Home (Realm Discovery)

In AD FS 2.0, we are able to alter HRD behaviour either at the AD FS Proxy or AD FS Farm by changing the selector options visible to the user, for the claims providers concerned. This was possible by configuring the homerealmdiscovery.aspx.cs
code-behind page to suppress the providers that we didn’t want the user to see.

In AD FS R2, HRD customization options through PowerShell now allow us to determine how the UI is presented to the end-user during logon, based on:

1. target suffix resolution – providing suffix routing on a per claims provider basis
2. limiting the claims providers visible for the relying party concerned

With Option (a) we define the home claim provider of the target user, by binding the UPN domain/suffix of a particular set of users to a given claims provider. For example:

• For users in the “Azure Sprout” organization with a @azuresprout.net
  suffix, we send to the “Azure Sprout” claims provider.
• For users in the “Access Onion” organization with a @accessonion.net
  domain suffix, we send to the “Access Onion” claims provider.

With Option (b) we identify the claims providers we wish to use for that relying party, specifying which ones we wish to make them visible in the HRD list. This is governed on per relying party basis.

While having the flexibility of these options enhances functionality, they don’t eliminate HRD issues completely as we’ll see. Nonetheless, they can greatly simplify the user logon experience. You’ll ultimately need to find the right combination that works for you.

Back to the scenario. Users connecting externally in each organization should use multi-factor authentication (MFA). In addition, external users connecting through the “Access Onion” organization have an existing 3^rd party MFA identity provider and their (external) users must use this provider.

Internal “Access Onion” Users

Represented by the orange numbered items in the diagram, internal user workflow should be as follows:

1. The User accesses the “Access Onion” Teamsite. The SharePoint Security Token Service (STS) has been configured to use the “Access Onion” AD FS as a trusted claims (identity) provider.

    

2. The user is redirected to the local “Access Onion” AD FS instance. Since the logon request is sourced from an internal user, the request is resolved via internal DNS, pointing to the “Access Onion” AD FS farm.
   1. The Home Realm Discovery (HRD) process is invoked because there are three claims providers configured in the “Access Onion” organization:
      1. The local Active Directory claims provider
      2. The “Azure Sprout” claims provider
      3. A third-party claims provider (PointSharp STS) providing MFA.

    

3. Once HRD processing is complete, the logon process continues. Since the user is connected to the Access Onion LAN, the request is processed at the farm, whereby the user is silently logged on with their Windows credentials. A relying party rule is configured for the SharePoint Teamsite and claims rules (Send LDAP Attributes as Claims Rules) configured to pass the requisite attributes.

    

4. The user is redirect to the SharePoint “Access Onion” Teamsite whereupon, assuming permissions have been granted to the SharePoint site, they gain access.

For internal access, we don’t want “Access Onion” users to see the Home Realm Discovery (HRD) selection screens. The AD FS server, therefore, can be configured so that Intranet users can bypass HRD. This is accomplished by issuing the following command on the “Access Onion” AD FS instance.

Set-ADFSProperties –IntranetUseLocalClaimsProvider $True

External “Access Onion” Users

Let’s look at the logon workflow represented by the red numbered items in the diagram:

1. The User accesses the “Access Onion” Teamsite. Since the user is connecting externally, the URL of the SharePoint teamsite resolves to the IP address of the Web Application Proxy. On the proxy the request is intercepted and processed. A pre-authentication rule has been created for the SharePoint teamsite URL.

    

2. Before authentication can continue :
   1. The Home Realm Discovery (HRD) is invoked because there are three claims providers configured in the “Access Onion” organization:
      1. The local Active Directory claims provider
      2. The “Azure Sprout” claims provider
      3. A third-party claims provider (PointSharp STS) providing MFA.

    

3. Once HRD processing is complete, the logon process continues and the user is routed to the 3^rd party claims provider. At the logon page, the user enters their credentials, using whatever authentication methods have been prescribed on the PointSharp Security Token Service (STS): Hard token, soft token, SMS etc. The STS is configured to pass back the appropriate attributes that will satisfy SharePoint Teamsite requirements via the AD FS RP-STS.

    

4. The user is then sent back to the “Access Onion” AD FS R2 instance, acting as an RP-STS. Here additional claims processing and authorization is for the SharePoint “Access Onion” Teamsite relying party.

    

5. The user is redirect to the SharePoint “Access Onion” Teamsite whereupon, assuming permissions have been granted to the SharePoint site, they gain access. The URL termination of this connection is at the Web Application Proxy and connections to SharePoint are reverse proxied through the WAP.

OK, let’s explore this a little further, particularly the realm discovery part. As mentioned in the previous section, the “Access Onion” AD FS R2 instance, beyond the default AD claims provider, has additional claims provider trusts with two claims providers: the “Azure Sprout” AD FS R2 Instance and the existing “Access Onion MFA” provider (PointSharp) running as a Security Token Service – PointSharp Identity Federation.

A user logging on externally to the “Access Onion” organization, by default, would be faced with the following sign-in options.

The blue icon represents the local “Access Onion” Active Directory claims provider.

With R2, we can reduce the number of visible CPs used via the two methods discussed in the HRD section, namely:

• Use of suffix routing
• Naming claims providers on the relying party concerned

For suffix routing, we can bind the suffixes used by each respective organization to target specific claims providers.

Set-AdfsClaimsProviderTrust –TargetName “Access Onion 3rd Party IdP” –OrganizationalAccountSuffix @(“accessonion.net”)

Set-AdfsClaimsProviderTrust –TargetName “Azure Sprout” –OrganizationalAccountSuffix @(“azuresprout.net”)

Users then see the following logon screen

The (PointSharp) 3^rd-party MFA provider is no longer visible, nor is the Azure Sprout organization. Clicking on the Other organization, we can then enter the appropriate suffix for the target claims provider.

The user is then routed to the “home” claims provider. Users with the @accessonion.net suffix, connect from externally, click on “Other Organization”, enter their credentials and are identified on the basis of the suffix entered, and routed to the in-house 3^rd party MFA claims provider; in this case a PointSharp Identity Federation Security Token Service (STS). Because AD FS R2 is acting as a Relying Party Security Token Service (RP-STS), it will route all users with this suffix to the PointSharp (claims provider) STS.

From here we continue the logon process, using whatever multi-factor authentication methods have been configured on the PointSharp provider.

A couple of comments at this point:

1. It would be nice to be able to customize the text for the “Other Organization” dialogue and screens. When I find out how this is possible or someone points me in the right direction, I’ll post an addendum to the article J
2. The base AD claims provider, “Access Onion”, is available in the HRD selection during external logon. While it was possible to suppress the base claims provider on the AD FS 2.0 Proxy, I’ve not worked out to do this under R2 for external clients. (Note: Disabling all the authentication types via the UI doesn’t suppress the AD provider). It’s a relatively minor point and one specific to this scenario, but the fact that it was possible under 2.0 grates a little. There could be a hidden parameter somewhere in the configuration that allows this…

Given the latter constraint, you’d be forgiven for trying Option (b) for HRD in this particular case. We can name preferred claims providers for our particular “Access Onion” Teamsite relying party by specifically limiting those we wish to see during logon for that RP. For example:

Set-AdfsRelyingPartyTrust -TargetName “SharePoint Access Onion Teamsite” -ClaimsProviderName @(“Access Onion MFA”, “Azure Sprout”)

This is a nice option for limiting web applications to given identity provider(s).

In this example, users are faced with the following logon screen when redirected to the “Access Onion” AD FS instance.

Great! No AD claims provider…..no really… I mean no AD claims provider J It prohibits the use of the AD provider in all login scenarios including internal ones, meaning that all users would now need to use MFA. While targeting identity providers is a useful feature, it’s not one applicable in this particular case.

Settings for the RP can be restored to normal by:

Set-AdfsRelyingPartyTrust -TargetName “SharePoint Access Onion Teamsite” -ClaimsProviderName @()

Based on the above behaviour, we’ll settle on using suffix routing for realm discovery scenarios.

Internal / External “Azure Sprout” Users

Let’s have at the logon workflow for “Azure Sprout” for users connecting from within their organization to the remote “Access Onion” SharePoint Teamsite. The logon flow, because MFA is a requirement, means that only the primary authentication mechanism changes, based on whether the user is connecting from inside the “Azure Sprout” organization (blue text) using IWA or outside (black text) using forms.

1. The User enters the “Access Onion” Teamsite URL. Since the user is connecting externally, the URL of the SharePoint teamsite resolves to the IP address of the Web Application Proxy. On the proxy the request is intercepted and processed. A pre-authentication rule is configured for the given URL.

    

2. Before authentication can continue :
   1. The Home Realm Discovery (HRD) is invoked because there are three claims providers configured in the “Access Onion” organization:
      1. The local Active Directory claims provider
      2. The “Azure Sprout” claims provider
      3. A third-party claims provider (PointSharp STS) providing MFA.

    

3. Once HRD processing is complete, the logon process continues and the user is routed to the “Azure Sprout” claims provider. The primary (AD) authentication provider processes the logon request. When the user is connecting to the “Azure Sprout” local area network, the URL of the federation service resolves to the IP address of the internal AD FS farm. Internal users use their local Windows authentication in the primary slot, as can be seen by the Intranet configuration below.

   

   External user logon, resolving to the external DNS of the Web Application Proxy, means that users employ forms-based authentication.

   

4. Having provided their AD credentials, the user must then satisfy additional authentication requirements and use their Windows Azure Authentication (MFA) credentials to continue further logon. This is enforced on the “Access Onion” Relying-Party STS as an MFA rule.

    

5. With logon complete the user is sent back to the “Access Onion” AD FS R2 RP-STS. Here additional claims processing, MFA checks and authorization for the SharePoint “Access Onion” Teamsite relying party take place.

    

6. The user is redirected to the SharePoint “Access Onion” Teamsite whereupon, assuming permissions have been granted to the SharePoint site, they gain access. The URL termination of this connection is at the Web Application Proxy and connections to SharePoint are reverse proxy through the WAP.

On the “Access Onion” SharePoint Teamsite relying party is a rule specifying all external users must use MFA.

This corresponds to the following additional authentication rule:

c:[Type == “http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork”, Value == “false”]=> issue(Type = “http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod”, Value = “http://schemas.microsoft.com/claims/multipleauthn”);

Similarly, in the “Azure Sprout” organization, the “Access Onion” AD FS instance is a relying party and this is where the MFA requirement is enforced. This corresponds to an additional authentication rule for the “Access Onion” AD FS Relying Party of:

“http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork”, Value == “false”] => issue(Type = “http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod”, Value = “http://schemas.microsoft.com/claims/multipleauthn”); c:[Type == “http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork”, Value == “true”] => issue(Type = “http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod”, Value = “http://schemas.microsoft.com/claims/multipleauthn”);

Earlier, on the “Access Onion” side, we hand-waved all logon requests to the “Azure Sprout” organization when setting up Home Realm Discovery (HRD) by using suffix routing.

Set-AdfsClaimsProviderTrust –TargetName “Azure Sprout” –OrganizationalAccountSuffix @ (“azuresprout.net”)

On the “Access Onion” AD FS side of things, we can validate whether MFA has been used during logon and the appropriate MFA claim value emitted by the “Azure Sprout” MFA Provider. On the “Access Onion” AD FS RP-STS, we create the following authorization rule for the “Azure Sprout” claims provider:

c:[Type == “http://schemas.microsoft.com/claims/authnmethodsreferences”, Value =~ “^(?i)http://schemas\.microsoft\.com/claims/multipleauthn$”]=> issue(Type = “http://schemas.microsoft.com/authorization/claims/permit”, Value = “PermitUsersWithClaim”);

On the “Azure Sprout” AD FS instance, we configure MFA as a requirement for the “Access Onion” relying party (RP-STS). All users in that organization then use MFA when accessing the “Access Onion” SharePoint Teamsite.

Logging on with our test user (training@azuresprout.net) using their UPN and password and we’re faced by the Windows Azure MFA Server required authentication.

As before, this second step involves the use of a call-back process and the test user I’m logging with receives a phone call, whereupon the hash/pound key has to be pressed to confirm I’m in possession of the device.

Logging on to a test WIF claims aware web application, we can see that a claim value is issued for use of the Azure MFA via phone confirmation. This illustrates that it is possible for MFA providers to provide custom claims in their (MFA) response to AD FS.

We can then access SharePoint, assuming the appropriate permissions are granted on the site concerned.

Let’s extend the scenario to see how MFA works with the a mobile device, such as an iPad.

MFA and Other Devices

I’ll use the same Workplace Join conventions I described in the first post, this time with MFA as an auxiliary logon mechanism. On the Device Registration Service (DRS) relying party itself, we’ll set a requirement for MFA to be used for unregistered devices.

From the iPad, we the Workplace Join process by entering the URL of the DRS endpoint in Safari. At this point we need to logon with our AD credentials.

Then we hit the MFA logon requirement.

Following a successful logon, we then start the enrolment process for Workplace Join on the iPad. The procedure at this point is the same as the one described in Part I. The user points their browser to an enrolment endpoint, e.g.

https://sts.azuresprout.net/Enrollment Server/otaprofile/

We install a profile.

Once completed and there is a successful join to the workplace, the device is registered within AD and a certificate installed in iOS. Device authentication then becomes available as a qualifier when setting conditional access policies to permit access to the enterprise network.

Let’s look at an example using the “Azure Sprout” AD FS configuration accessing the “Access Onion” SharePoint Teamsites. Redirected to AD FS R2 instance during logon, the certificate is used to assert the identity of the user on this device.

The HRD screens sign-in screens are similar to those we saw earlier on a Windows PC using Internet Explorer.

Click on the Other Organization link and enter training@azuresprout.net
our as user for logon. The use of @azuresprout.net ensures that the user is routed to the “Azure Sprout” organization.

At the “Azure Sprout” AD FS the user must logon with their AD primary authentication credentials.

With MFA enabled on the AD RP-STS rule for the “Access Onion”, the connecting user must satisfy the MFA logon requirement with Azure MFA phone authentication:

A call is made to the user phone to confirm authentication. Logon can continue.

Claims are processed on the claims provider pipeline and then on the SharePoint relying party, and we’re into the SharePoint Teamsite. Having logged on with our user/device pairing, the SSO features of Workplace Join now come into play. The user registered to the device is now issued with an SSO token that is persisted for 7 days (default setting). Subsequent logons by that user will only require validation of the SSL device certificate when accessing AD FS until the token expires.

This persistence behaviour can be adjusted via the Set-ADFSProperties –PersistentSSOLifetime setting (minutes). To disable this, we can use the following command:

Set-AdfsProperties -EnablePersistentSso $False

Don’t forget when testing that the SSO experience is bound to the user and device pairing. Logging on with another user will not exhibit the same behaviour.

MFA with Non-claims Aware Web Applications

All the examples to date have been with claims-aware web applications. R2 also provides support for relying parties that are non-claims aware using the kerberos protocol. This is a great feature and the combination is made possible by creating a non-claims aware RP within AD FS and then making the application available through publishing it via the Web Application Proxy (WAP) using Kerberos Constrained Delegation between the front-end WAP and the back-end web application. This, of course, means that the Web application Proxy must be domain-joined.

In the test below four servers have been used, with all servers member of an Active Directory (a-onion.local):

Access to the IIS application is through a qualified name of web.accessonion.net rather than the actual name of the server. The kerberos web application is reachable internally via DNS using the URL of https://webaccessonion.net. The app itself is a vanilla IIS web page protected using Integrated Windows Auhtentication (IWA).

Here’s an overview:

This was tested using the “Azure Sprout” organization only. There’s no RP-STS, other AD’s etc. to speak of in this configuration

Let’s quickly go throw the configuration steps.

1. On the IIS server enable Integrated Windows Authentication (IWA) on the IIS website. In real life, this is more likely to be a given path rather than the website itself.

   

2. Test access internally by adding the FQDN of the website URL into the Local Intranet Zone of the browser (Internet Explorer). Here we’ve add the https://web.accessonion.net
   URL to that zone security list.

   

   If you continue to be prompted with NTLM Challenge/Response, check that the SPN for the URL of the web application has been registered under the computer account (in a web farm scenario this would be an application pool). For example:

   SETSPN –S http/web.accessonion.net a-onion\server333
   

3. On the domain controller or a client with remote administration tooling installed, run the ADSI Edit snap-in, drill down to the Web Application Proxy computer object, right-click, select properties. Add a Service Principal Name (SPN) for the computername of the Web Application Proxy, together with the fully qualified name.

   

   Using the examples from the diagram, this would translate to:

http/server555.a-onion.local

http/server555

1. In AD Users and Computers (ADUC), on the delegation tab of the WAP computer account (server555.a-onion.local), add the computer account for IIS (server333.a-onion.local) as being trusted for delegation for HTTP (ms-DS-AllowedToDelegateTo)

   

2. Create the non-claims aware relying party within the AD FS UI using the URL and path of the web application as the RP identifier (don’t forget the trailing slash)

   

3. Specify that an MFA rule will apply to this relying party

   

4. External Users are required to use MFA

   

    

5. We’ll use the default authorization rule of Permit All.

   

6. On the Web Application Proxy, create a publishing rule for the non-claims aware relying party.

   

7. On the Web Application Proxy, we configure the rule for https://web.accessonion.net/ together with the SPN of the back-end web server (http/server333.a-onion.local).

External clients should now be challenged for MFA when accessing the IIS Web Application. I’ve used a workplace joined Windows 8.1 device using Chrome to highlight this (NB: IE11 doesn’t challenge for the device certificate).

Logging in with forms-based logon (primary authentication)

The additional authentication rule executes for the MFA provider for logon:

The user gets called back, as per the previously described method. Once they’ve responded, redirection to the non-claims aware IIS web application, our vanilla IIS splash-screen.

So that’s it for now. I’ve glossed over some of the finer details in this post and apologies for any brevity. If you do require more information, please post in comments and I’ll try and answer quickly. Meanwhile, we’ll cover more fine-grained access control decisions in Part III, as well as Work Folders, Server Core installation and (time-permitting) some OAUTH access scenarios.

Until then ….Happy New Year!