Category Archives: AD FS 2.2

First Impressions – AD FS and Window Server 2012 R2 – Part II

January 7, 2014AD FS 2.2, Claims-based Authentication, Home Realm Discovery, MFA, Window Server 2012mylo

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:

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.
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:

Expanding access capability within AD FS, making available more fine-grained “conditional access” decisions;
Improving login behaviour and user experience for sign-in scenarios;
Improving customization of sign-in pages / error-handling;
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.

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:

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.
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.

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.
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);
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:

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.
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.
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.
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:

target suffix resolution – providing suffix routing on a per claims provider basis
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^rdparty 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:

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.
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.
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.
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:

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.
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.
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.
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.
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:

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
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.

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.
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.
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.
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.
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.
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):

Role	Server Name (FQDN)	Web application FQDN (web.accessonion.net)
		Internal (Kerberos)	External (MFA)
R2 Domain Controller	server111.a-onion.local
R2 AD FS Server	server222.a-onion.local
R2 Web Application Proxy	server555.a-onion.local		X
R2 Application Server (IIS)	server333.a-onion.local	X

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.

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.
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
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

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)
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)
Specify that an MFA rule will apply to this relying party
External Users are required to use MFA
We’ll use the default authorization rule of Permit All.
On the Web Application Proxy, create a publishing rule for the non-claims aware relying party.
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!

First Impressions – AD FS and Windows Server 2012 R2 – Part I

September 13, 20132FA, AD FS 2.0, AD FS 2.1, AD FS 2.2, Claims-based Authentication, MFA, Multi-Factor Authentication, Windows Server 2012 R2AD FS, AD FS 2.0, AD FS 2.1, AD FS 2.2, AD FS R2, Claims-based Authentication, MFA, Multi-Factor Authentication, Windows Server 2012 R2, Workplace Joinmylo

In the next few posts, I wanted to take a look at the changes to be found in Windows Server 2012 R2 with respect to Active Directory Federation Services (AD FS). At TechEd Europe, I was fortunate enough to chat with some of the folks from the Active Directory team about the new enhancements and to cover them here in a little more detail. As you may have read, there are a significant number of changes in the R2 version and I’ll spread coverage of this over a number of posts.

Part 1

– Architecture Changes

– Workplace Join / Bring Your Own Device (BYOD)

o Windows 8.1

o iOS Devices

– Web Application Proxy

– Extranet soft account lockout policies

– Lost Device Protection

Part 2

– UI Changes

– Access Scenarios

– Authentication changes

o Multi-Factor Authentication

o Context-based Authentication

o Claims/Non-claims aware applications

o Policy-based Evaluation

Part 3

– OATH2 support

– Work Folders

– Better event handling / reporting

– Server Core

– Other stuff undiscovered J

Architecture Changes

The use of IIS with AD FS in Windows Server 2012 R2 has been eschewed in favour of a move to kernel-mode (HTTP.SYS). The motive, highlighted in discussions at TechEd, is to improve performance, provide greater sign-in customization options and to assuage concerns for co-locating AD FS and AD DS on the same server (IIS on domain controllers has been a long-standing security no-no). As the use of federation services goes more mainstream in everyday use with Windows 8.1, this shift is understandable and an important design consideration. With the new kernel-mode approach, support for running under server core also appears as an option in the new release.

From a basic architecture standpoint and overview, the AD FS proxy has been supplanted by a role known as the Web Application Proxy, servicing connections for external clients. The user interface (UI) through the migration to kernel mode is also significantly changed. Authentication undergoes a radical overhaul with a Multi-Factor Authentication (MFA) Adapter available for plugging into Windows Azure Active Authentication and third-party MFA providers. This is also seen in more nuanced behaviour with respect to authentication within the product, reflected in greater flexibility in access control decisions.

With AD FS now built directly built on top of HTTP.SYS, a lot of changes are abstracted from the user through the new MMC UI and also PowerShell. Nonetheless, it’s worthwhile familiarizing ourselves with kernel mode elements, as they serve a useful role in basic service troubleshooting/configuration . The NETSH HTTP command can be used to query and configure http.sys.

The netsh http show urlacl command can be used to list URL reservations that AD FS makes within http.sys. Here we can see the /adfs/ path reserved for use.

Reserved URL : https://+:443/adfs/

User: NT SERVICEadfssrv

Listen: Yes

Delegate: Yes

SDDL: D:(A;;GA;;;S-1-5-80-2965554544299-213434830-363436364-117610243-975697593)

And there’s this new guy, the Device Enrolment server, whose role becomes more apparent should we wish to make use of new Windows 8.1/iOS client (mobile) integration features.

Reserved URL : https://+:443/EnrollmentServer/

User: NT SERVICEdrs

Listen: Yes

Delegate: Yes

SDDL: D:(A;;GA;;;S-1-5-80-1321940109-3370001082-3650459431-215109509-2472514016)

SSL bindings can be reviewed using the netsh http show sslcert command. The AD FS server in this demo setup I’ve created is sts.adfs2.net.

PS C:Windowssystem32> netsh http show sslcert

SSL Certificate bindings:

————————-

Hostname:port : sts.adfs2.net:443

Certificate Hash : 1f54c1c62b057dscffgb1aec2b2cbd0876e5c559

Application ID : {5d89a20c-beab-4389-9447-324788eb944a}

Certificate Store Name : MY

Verify Client Certificate Revocation : Enabled

Verify Revocation Using Cached Client Certificate Only : Disabled

Usage Check : Enabled

Revocation Freshness Time : 0

URL Retrieval Timeout : 0

Ctl Identifier : (null)

Ctl Store Name : AdfsTrustedDevices

DS Mapper Usage : Disabled

Negotiate Client Certificate : Disabled

Hostname:port : localhost:443

Certificate Hash : 1f52c0d62b0570c6a26c7fec2b2cbd0876e5bc59

Application ID : {5d89a20c-beab-4389-9447-324788eb944a}

Certificate Store Name : MY

Verify Client Certificate Revocation : Enabled

Verify Revocation Using Cached Client Certificate Only : Disabled

Usage Check : Enabled

Revocation Freshness Time : 0

URL Retrieval Timeout : 0

Ctl Identifier : (null)

Ctl Store Name : AdfsTrustedDevices

DS Mapper Usage : Disabled

Negotiate Client Certificate : Disabled

Hostname:port : sts.adfs2.net:49443

Certificate Hash : 2f5c41c62b0570c6a26c7fec21d2d0876e5c559

Application ID : {5d89a20c-beab-4389-9447-324788eb944a}

Certificate Store Name : MY

Verify Client Certificate Revocation : Enabled

Verify Revocation Using Cached Client Certificate Only : Disabled

Usage Check : Enabled

Revocation Freshness Time : 0

URL Retrieval Timeout : 0

Ctl Identifier : (null)

Ctl Store Name : (null)

DS Mapper Usage : Disabled

Negotiate Client Certificate : Enabled

Location-wise, the AD FS application files themselves are no longer held under C:Program FilesActive Directory or C:Program Files (x86). Instead, they’ve moved to C:WindowsADFS. For clarity, this was actually a change instigated first in Windows Server 2012 with the Active Directory Federation Services (AD FS) 2.1 role. In this folder is the Microsoft.IdentityServer.Servicehost.exe.config file, where, as admins, we’ll be spending more time in the future in order to activate debug functions. From this file all trace options for various services and endpoints can be enabled. In the same folder is a configuration file for the new Device Registration service (DRS), responsible for activation and enrolment of controlled devices and represented by a new (Win8/IOS *) schema class in Active Directory Domain Services (AD DS). The file in question is called Microsoft.DeviceRegistration.ServiceHost.exe.config.

Support for the new Device class requires a schema change to Active Directory. For those upgrading an existing Windows setup, the appropriate files can be found on the R2 installation CD under D:SupportADPrep. From what I’ve seen/tested thus far, to support the new release, you’ll need at least one Windows Server 2012 domain controller, preferably two in any serious deployment scenario. This requirement stems from the use of Group Managed Service Accounts (GMSA) that are generated and maintained by the Key Distribution Service (KDS) on 2012 domain controllers. The new version of AD FS makes use of these GMSA accounts, defined during AD FS installation, that are then shared amongst connecting AD FS hosts. I suggest reading the following backgrounder and bear in mind that the AD FS Windows Server 2012 preview labs incorporate a workaround for testing purposes, in activating the root key, that is not recommended for production environments.

Update 29/10 – SamD from the AD product team added that “gMSA is not required to be the service account that ADFS runs on. It is an additional optimization that is available to customers if they have Win2012 domain controllers available.” The traditional service account option is available during installation.

Moving on, let’s take a look at the “broader” access audience that the new version emphasises. This can be immediately seen by viewing the claims descriptions list surfaced on a new AD FS installation.

There are around 40 new claims descriptions available in the AD FS Windows Server 2012 R2 release. As we’ll see, use of these new claims types allow us to make more refined assessments concerning access to web applications and resources.

Workplace Join / Bring Your Own Device (BYOD)

Through the new Workplace Join feature within R2, AD FS becomes a focal point for mobile access in the enterprise and an integral component in the Microsoft Bring Your Own Device (BYOD) vision. Workplace Join allows hitherto unmanaged/untrusted operating systems such as Windows RT/Windows 8 and IOS to be moved into a more controlled access context, by allowing their registration and affiliation with Active Directory. Devices will register with Active Directory through a Device Registration Service (DRS) and subsequently use an X509 certificate bound to the user context(s) on that machine for device authentication. In a default configuration, users will login via AD FS to initiate the join process using their AD credentials. To further secure this process, additional factors can be also used with Windows Azure Active Authentication (PhoneFactor) or a third-party authentication provider exposed through the new AD FS MFA SDK.

Devices that are workplace-joined emit additional claims during the logon process. These include:

Certificate support in claims handling has also been enhanced.

Windows 8.1

In order to provide a comparison between old and new with Workplace Join, I began by looking at what claims (and any new ones) are processed from a vanilla Windows 8.1 Pro domain-joined machine, using a simple WS-Federation relying party to validate claims emitted the client and AD FS components.

Firstly via the internal network and the AD FS farm using Internet Explorer. Here the browser uses Integration Windows Authentication/Negotiate and the user silently accesses to the WIF relying party via Kerberos. The usual configuration caveats apply here: the URL of the AD FS and RP instance are in the Local Intranet Zone of IE.

To demonstrate a new change, I installed Mozilla Firefox and repeated the logon process. Instead of the Integrated Windows Authentication (IWA)/Negotiate process, the user is presented with a forms sign-in page. This represents a departure from the user experience and behaviour in AD FS 2.0. With the latter, authentication would be downgraded to NTLM, because IWA was assumed in the farm configuration and the browser needed to be configured to explicitly support Kerberos for seamless login. Where the latter action was not performed, the user would receive an NTLM challenge/response prompt, often causing confusion. With the new release, support for IWA is now governed through setting registering User Agent types within AD FS that are capable of supporting Negotiate. Out of the box, this is constrained to IE, meaning any other browser will revert to using forms logon when accessing resources from an internally connected client . Here we see the claims output from a Firefox login:

In internal login scenarios (IE/Firefox), we see new claims types emitted concerning location (whether the login request is sourced within the Corporate Network), an Application Identifier (corresponding to the Relying Party Identifier), the Client source IP (or translated) address, an Authentication Method Reference and a Client Request ID.

Then, via an external network through the new Web Application Proxy:

In addition to those claims types mentioned earlier is a new claims type for the client forwarded IP (x-ms-forwarded-client-ip) processed at the Web Application Proxy. The insidecorporatenetwork value is now set to false, as we’re on an outside network.

You may have observed at this point that there are no Device claims. This makes sense if we consider that their use is limited to client types that declare them, i.e. only workplace-joined clients currently make use of the Device class.

Onto the workplace join process itself. To get your test lab up and running, I recommend reading this TechNet article.

If you follow the lab guide carefully, and, in particular, with emphasis on getting the dependent infrastructure working correctly, then with a little patience and time, you’ll be up and running. I tried this with the basic contoso.com lab setup (a good starting point) and then expanded this in new setup using my own test domain. There are a few gotchas worth pointing out, hoping that you’ll avoid my growing pains …

1. Don’t use Cryptography Next Generation (CNG) algorithms when configuring your AD Certificate Services. They won’t work.

2. For simplicity in your CA configuration, I’d opt for use of HTTP Distribution endpoints, particularly if you intend to test “outside” configurations using the Web Application Proxy. Ensure the Certificate Revocation List (CRL) on the Certificate Distribution Point (CDP) and your Authority Information Awareness (AIA) URLs are setup correctly and reachable from the Win 8.1 client. If you’re using Delta CRLs and IIS as the web server for your CDP, don’t forget to allow Double Escaping on IIS in the Request Filtering section.

3. Ensure the Enterprise CA is trusted by the client and the certificate is installed in the Trusted Root Authorities section of the client. Importing the cert via the AIA endpoint is a good way of testing its availability and installing the certificate. Again, the certificate distribution point (CDP) URLs should be visible to the client.

4. Issue the AD FS certificate, complete with SAN for the Device Registration Service (DRS), before you begin your AD FS setup. The common name (CN) on the certificate should be the AD FS URL and two Subject Alternate Names (SAN) entries should contain the AD FS URL and one for the Device Registration Service (DRS) provided. For example, I’ve used an example using the MMC snap-in Certificate Request wizard, based on a copy of the default Web Server template for a common name of sts.mydomain.com for the FQDN URL of the AD FS service and also as the first Subject Alternate Name (SAN) entry. A second SAN entry is used for the DRS endpoint, enterpriseregistration.mydomain.com.

5. As posted on the Technet forums (in the current R2 preview), both the AD FS server and the Windows 8.1 client need to be configured with time-zone of UTC 0:00 or less. My setup is using Pacific Time (UTC -8:00). Don’t ask me, I just blog here J

6. Don’t forget to enable Device Authentication in Global Primary Authentication settings within the UI or via PowerShell.

7. Use the Event Log Microsoft|Workplace Join to troubleshoot!! Here’s a collage of first-hand events to illustrate it’s effectiveness in troubleshooting:

URL (enterpriseregistration.xxxx.yyyy) cannot be resolved or reached.

Can’t reach the CRL CDP of the AD CS endpoint.

Root Authority is not trusted by the client.

This message is stating a number of possible issues (generally bad):

o DRS Configuration and Activation was not completed successfully

o Issues with the SAN on the SSL certificate

o AD FS Device Authentication has not been enabled

Once you start seeing messages like the following, you’re almost there.

Nice.

8. Take particular note of any errors reported when trying to activate Device Registration Service; namely anything along the lines of:

WARNING: UPN values that are not included in the SSL certificate have been found in the enterprise. Users with these UPN suffix values will not be able to register their devices. To enable users with the corresponding UPN suffix to register their devices, provide a new SSL certificate containing the values listed below in the subject or subject alternative name.

enterpriseregistration.upn1.contoso.com
enterpriseregistration.upn2.contoso.com

In the case of (8), I’d made the mistake of not registering the appropriate certificates with Subject Alternate Names (SAN) that included the DeviceRegistration CNAME record. Simply re-issuing the AD FS service certificate afterward, setting Manage Private Keys etc. and re-activating DRS in PowerShell was not sufficient to get the configuration working.

The Workplace Join function can be accessed by first accessing the Change PC Settings option on the Windows 8 UI

In PC Settings, choose the Network option

Then select Network followed by the Workplace option:

If your configuration is working, certificates are trusted, appropriate AD FS and PKI endpoints are reachable, stars are in alignment (just joking), then clicking on the Join button leads to AD FS responding with a challenge:

Enter the Active Directory credentials for the user. In this example I’m using, the device is joining a test domain called adfs2.net. Note the AD FS URL (connecting to my R2 instance sts.adfs2.net) at the top of the page. For the auto-discovery of the AD FS Device Registration Endpoints (DRS) a CNAME (Alias) record in DNS needed to be created for the service called enterpriseregistration.adfs2.net. This record points to the host (A) record of the AD FS federation service internally. This allows the discovery process to find the DRS endpoint and in an external setting this would point to the Web Application Proxy, your own Reverse Proxy or other suitable edge device.

The relying party (RP) for the Device Registration Service is created during the DRS activation process, so there’s nothing additional required on this side.

Connecting Windows 8.1 clients will use the auto-discover function by matching the domain suffix of the user account provided during the join process against the enterprise registration CNAME record for that domain. The join process then attempts a call to the enrollment server web service. Using the adfs2.net domain as an example, the following endpoint is queried:

https://enterpriseregistration.adfs2.net/EnrollmentServer/contract?api-version=1.0

If the service can be reached successfully, the join process is initiated.

The process is now completed and the “join” associated with the Windows 8.1 user profile. I used a Microsoft Live ID account and as can be be seen from the above screenshot, a subsequent AD user called demo with a UPN of demo@adfs2.net,in doing so providing my AD credentials during the Join. Please note that the Active Directory domain I’m using is also called adfs2.net (dc=adfs2,dc=net) for convenience. In a real-world/production scenario, the DNS domain names used for Active Directory and that of the federation service itself may be different.

The user account is then issued with a self-signed X509 certificate with an Extended Key Usage (EKU) of Client Authentication. Jumping into the Certificates|User snap-in we see a certificate issued under the user context.

Back to the WIF 3.5 relying party (RP), logging on to the RP from the outside we get redirected to AD FS for logon. Upon successful logon, the following claims are shown.

With the Win 8.1 device now connected to the AD domain via a Workplace Join, we see additional claims consummated.

· IsRegisteredUser

· OS Version

· OS Type

· Identifier (Subject name of the cert)

· Display Name (corresponding to the Device Name)

· Registration ID (corresponding to an OU served up in the certificate)

The device itself is registered within Active Directory at the following location: CN=<Device ID>,CN=RegisteredDevices,DC=mydomain,DC=com.

Here’s an example with a SAML 2.0 Service Provider (SimpleSAMLphp), with a Workplace Joined Windows 8.1 client connecting to it.

Inside the corporate network, we see the following:

As tempting it is to delve further into authentication, I’ll refrain from doing so and leave this to a follow-up post. My apologies, otherwise this post will reach biblical proportions in length and we’ll be shaking hands with Santa Claus before we know it.

iOS devices

From testing, the auto-discover function using the enterpriseregistration CNAME record in DNS, described in the previous section, is limited to the workplace join process for Windows 8.1. iOS clients must directly connect to AD FS to initiate the join process. The endpoint settings on the DRS Relying Party refer to a URL of:

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

This is the DRS Over-the-Air endpoint for non-Windows devices (currently iOS only).

I used an iPad 3 running iOS 6.1.3 for this exercise. If you plan on using self-signed certificates for this type of testing, you’ll need to use the iPhone Configuration Utility to create a profile which can be then used to install the root certificate from your Certificate Services Issuing CA (and any optional chain).

If you’re testing iOS or Windows 8.1 devices in an external setting, it’s worth mentioning that the Web Application Proxy (WAP), which I’ll cover in a moment, doesn’t provide an HTTP Reverse Proxy function. To ensure that any CRL/AIA distribution points are visible in an “outside” testing context, I elected to install IIS on the WAP, publish the CRL/AIA Certificate Distribution Points (CDP) via a UNC from the CA itself to be made available as an HTTP URL on the Web Application Proxy via IIS, making the distribution points reachable from an external perspective. Clearly, this is not something one would do automatically in a production environment, without a bit of forethought, but it works well in a demo environment. You can probably also do this with a kernel mode only approach, but I didn’t have time to test this (yet).

Once the Apple configuration file (.mobileconfig) file had been deployed onto my iPad (via e-mail), a Profile containing the Root certificate was generated and the certificate installed.

With the root certificate or chain correctly installed, going to the AD FS server URL, we should not receive any SSL errors or warnings in the browser, indicating that the chain and CRL/AIA distribution points are reachable. To test this, you can use the IdP initiated sign-on page in the default setup, e.g. https://YOURFQDN/adfs/ls/idpinitiatedsignon.aspx. From the iPad, here’s the portrait view of the page.

Playing around, I turned the iPad on its side and we get an automatically resized window. This is a nice feature in the new UI in AD FS 2012 R2 that supports dynamic adjustment and positioning of elements through CSS, resizing pages accordingly across various devices and user agents (think mobile client).

In order to kick off the Workplace Join, we point Safari to the endpoint DRS mentioned earlier:

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

This redirects the browser to a sign-in page where we need to logon with the AD account that will be bound to the iOS device for the workplace join.

Logging on with the demo@adfs2.net account I used in the Windows 8.1 example, the Safari page remains open in the background and the foreground switches to the install profile option on the mobile device.

The install profile option and Workplace Join install option appears:

Clicking on the More Details option, we can see that the AD FS Token Signing Certificate (public key) and the Device Enrollment Encrypted Profile Service are referenced during the profile installation.

Clicking on Install Profile

Once the profile is installed we see a Certificate issued to the device, issued with a common name of MS-Organization-Access, as per the Windows 8.1 join process.

Returning to the profile screen we see the completed Workplace Join profile

NB: The Demo Auth360 profile is the imported .mobileconfig containing the root certificate from earlier.

Web Application Proxy

Sitting in front of the AD FS farm is a new optional role, similar to the AD FS Proxy in AD FS 2.0, called the Web Application Proxy. This is a completely redesigned component, built to cater for federation services scenarios as well additional access scenarios beyond those seen in AD FS 2.0.

As with DirectAccess in Windows Server 2012, more roles are being moving into the mainstream product and the Web Application Proxy is a module in the Remote Access role within Windows Server 2012 R2.

Configuration of the proxy itself also moves to the Remote Access Management snap-in.

A configuration wizard is provided to connect the proxy to the back-end AD FS farm and a service account is required to register with the AD FS server(s) during installation. This service needs to be a member of the local administrators group on the AD FS farm.

Once connected to AD FS, a number of simple options are available for configuration.

The UI is at this stage is admittedly basic, but as with DirectAccess in 2012, there’s a greater emphasis on using wizards to get the job done and whatever can be done in the UI can be done (and more) via PowerShell; a PS configuration script is provided as a summary at the end of each publishing wizard rule to demonstrate this point.

As with TMG/UG we can publish/proxy a particular URL or URIs/paths of that URL expressed as separate publishing rules on the proxy , e.g.

www.mydomain.com/ (as one allow all rule) versus

www.mydomain.com/app1/ as Rule#1

www.mydomain.com/app2/ as Rule#2

www.mydomain.com/app3/ as Rule#3

An interesting under-the-covers capability is support for Server Name Indication (SNI). SNI, initially provided in Windows Server 2012, allows for multiple certificates to be bound to a single IP listener. Prior to IIS 8.0/SNI, sharing IP addresses amongst multiple websites was limited to the network endpoint and their IP:Port binding. SNI is a TLS extension that provides the hostname of the server the client is connecting to during handshaking. This allows much greater flexibility when configuring the proxy. With the move to kernel-mode, all the hard lifting is done through the UI or via PowerShell. familiarity with NETSH HTTP will also assist in any troubleshooting or ad-hoc configuration. The majority of browsers support SNI, although Windows XP in any configuration using Internet Explorer does not.

The current preview of the proxy in the R2 release provides for connections as:

1. A reverse web proxy, connecting to back-end servers via HTTPS;

2. A pre-authentication web proxy, connecting to AD FS via HTTPS to validate credentials

a. For claims aware web applications

b. For non-claims aware web applications using Kerberos

When we publish a new AD FS compatible application (pre-authentication), the proxy pulls the RP list/ configuration from the AD FS farm. Polling is done (looking at the event logs) every minute.

Using a Windows Identity Foundation (WIF) test relying party application from another test domain (psid.local), here’s an example of a publishing rule:

Add-WebApplicationProxyApplication -BackendServerUrl ‘https://rp.psid.local/app9/’ -ExternalCertificateThumbprint ’91D8014979B9CDEF9C907171F7CE9AF398E66DC6′ -ExternalUrl ‘https://rp.psid.local/app9/’ -Name ‘WIF Test Application’ -ExternalPreAuthentication ADFS -ADFSRelyingPartyName ‘WIF 3.5 Application’

This is a pre-authentication rule, meaning that AD FS process the login request, UI surfaced and validates access and authentication credentials through the proxy via a back-channel connection before access to the relying party is processed.

To complete this round of testing, I wanted to validate Workplace Join from an “outside” network via the proxy. DRS endpoints are automatically published, meaning no specific additional publishing rules needed to be created.

On the Windows 8.1 client, I removed the client from the Join agreement created earlier in order to re-attempt the join via the proxy from the external network. When we attempt a join again from the “outside” via the Web Application Proxy, clicking on Join generates the following page.

The user ID is automatically populated in the form, carried over from the Join request.

Testing from the “outside” now, when we access our WIF application RP from our Workplace Joined client (via the Web Application Proxy), we’re served up with a sign-in form.

That’s expected as we’re now an Extranet client (using MS terminology). This is confirmed by looking at the base AD FS configuration and the primary authentication provider serving up forms login for external clients.

“Extranet” users are automatically assigned to the forms authentication sign-in process, whereas Intranet users are assigned Windows Authentication, browser considerations notwithstanding. For those familiar with fiddling with Local Authentication Types in web.config on the AD FS proxy/farm in AD FS 2.0, making this available through the UI and Powershell is a boon J

Going back to our relying party application, we can see in the produced claims that the client connection is not through the corporate network and is via Web Application Proxy using the following claims:

http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork

http://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser

The client is outside the corporate network and the user is now registered. As a simple test, if we only want to allow Registered Users access to our RP claims web application, we could do this through an Authorization Rule that states that only Registered Users are permitted access:

c:[Type == “http://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser”, Value =~ “^(?i)true$”] => issue(Type = “http://schemas.microsoft.com/authorization/claims/permit”, Value = “PermitUsersWithClaim”);

Logging on with a non-workplace joined client from outside the corporate network, we are denied access.

Error pages are customizable and that’s something we’ll cover in Part 3.

As I touched on earlier, we can use SSL bridging scenarios incorporating wildcard certificates on the front-end (proxy) and named certificates (on the back-end) in publishing scenarios. The pre-authentication parts allows integration with claims and non-claims aware (Kerberos) applications. Applications such as Exchange, which are not claims-aware or non-SAML kerberos claims SharePoint web applications can be configured via the Web Application Proxy. From testing rich client applications such as ActiveSync and Outlook, which use Basic/NTLM application, these are not currently supported on the Web Application Proxy either in a pre-authentication or pass-through capacity. The proxy defaults to SNI and this is not supported by some mail clients. We’ll cover this and other authentication scenarios in Part 2.

Just to wrap up, here are some observations from testing:

– The proxy can translate host names in URLs but not path names. Make sure that the published path matches that of the application;

– There’s no Edit function in the UI once you’ve created a publishing rule;

– The Web Application Proxy is currently HTTPS only, so no HTTP publishing. Hopefully this will be corrected in the near future as scenarios such as CRL/CDP publishing, which use HTTP are not supported in Reverse Proxy scenarios today. Meanwhile, HTTPS-HTTP bridging, sometimes used in Kerberos Constrained Delegation (KCD) scenarios with TMG/UAG are also not possible as AD FS is HTTPS only.

Extranet Soft Account Lockout

Extranet soft account lockout imposes an option to temporarily lockout “extranet-connected” accounts, via the Web Application Proxy, by not incrementing the AD BadPassword count on the PDC Emulator in AD once the soft lockout threshold is set in AD FS. If the latter is reached, further logon requests are not passed to AD so that AD Password Policy “hard” lockout measures are not immediately triggered. As the name suggests, this is a soft lockout option that is governed by use of an observation/sliding window that determines how often in a given period a user may attempt to logon via the proxy before the soft count is reached. The goal here is to frustrate password guessing attempts via brute force/DoS from the outside by nefarious users.

Update 29/10 – SamD from the AD product team mentioned that the extranet lockout feature was also done with the view that customers with ADDS account lockout policies can prevent DOS attacks on specific user accounts by setting a threshold lower for the ADFS extranet lockout policy. This way the user still has internal access because ADDS has not locked out the user.

Soft Account Lockout can be invoked through the use of PowerShell.

$observationwindow = New-Timespan -Minutes 1

Set-ADFSProperties –ExtranetLockoutThreshold 3 -EnableExtranetLockout $true -ExtranetObservationWindow $observationwindow

Once set, we can see via Get-ADFSProperties, the changes applied:

ExtranetLockoutThreshold : 3

ExtranetLockoutEnabled : True

ExtranetObservationWindow : 00:02:00

Here we’ve set the lockout threshold to three attempts with an observation window of two minutes.

From a testing standpoint, In the demo AD Domain setup, “hard” account lockout is not set via GPO.

Attempting to login at the RP WIF test application, we’re redirected to AD FS for logon. I enter an incorrect password.

The PDC Emulator FSMO role in AD, which monitors the bad password count (badPwdCount) increments by 1, likewise on the second and third bad password attempts.

I entered a bad password five times in successive attempts. Continued attempts to logon with a bad password, once the observation window kicks in fails to increment the count beyond three for the windowed period of two minutes. Once the window has elapsed, the bad password account is again incremented.

One of the nicer aspects of this setting is that it applies to all endpoints, be they passive or active in nature. This is particularly relevant as it also applies to web services (WS-Trust) endpoints for rich clients, e.g. Office 365.

Lost Device Protection

As covered earlier, devices registered via Workplace Join are registered within Active Directory in the container CN=<Device ID>,CN=RegisteredDevices,DC=mydomain,DC=com. Lost devices can be denied access by disabling or deleting the appropriate object within AD (I moved the device objects to another OU to test this). Access through AD FS is immediately revoked for the workplace joined client.

From testing thus far, devices joined, left and re-registered via Workplace Join are not currently cleaned up within the RegisteredDevices container. Some PowerShell scripting is currently required to enforce this and I would imagine some changes by GA or some scripts made available to manage this process.

Summary

A very long post comes to an end. Next up, we’ll look at UI changes and authentication/access in greater detail and there’s LOTS to cover. As ever, please feel free to comment, contribute, correct and I’ll get back to you!

The Access Onion

Access Management and Identity Federation on a plate.

Category Archives: AD FS 2.2

First Impressions – AD FS and Window Server 2012 R2 – Part II

First Impressions – AD FS and Windows Server 2012 R2 – Part I

Architecture Changes

Workplace Join / Bring Your Own Device (BYOD)

Web Application Proxy

Extranet Soft Account Lockout

Lost Device Protection