Tag Archives: Claims-based Authentication

MFA Conditional Access Policies in AD FS 2012 R2

October 23, 2014AD FS R2, Claims-based Authentication, Multi-Factor Authentication, Web Application Proxy, Windows Server 2012 R2AD FS R2, Claims-based Authentication, MFA, Multi-Factor Authentication, Windows Server 2012 R2mylo

Hello again. The previous Multi-Factor Authentication (MFA) post on User Certificates provided an opportunity to expand and look at some of the more interesting scenarios for MFA conditional access. This “interest”, if I may call it that, stemmed from playing around with MFA over the last few months and looking at the role of conditional access polices therein.

Ramiro Calderon wrote a great article on MFA policy here and it comes highly recommended. As he mentions in his post, the AD FS claims engine computes MFA authentication requests (defined via the AD Management UI) in a logical OR fashion. This can be initially a little confusing and we’ll take a look at some more creative use of MFA policies, to handle more flexible access scenarios in R2.

MFA Primer

To make use of MFA, an MFA provider is required. In a vanilla AD FS R2 setup, this is limited to certificate authentication using client certificates (see previous post). For other MFA options, check with your favorite 2FA vendor to see if they’ve written an MFA adapter for AD FS R2.

In the global authentication policy, the MFA provider needs to be enabled.

Let’s have a look at what happens when MFA is enabled through the AD FS Management UI. MFA policies can be triggered either globally (applicable to all relying parties), or on the relying party itself.

In the example below, MFA is required for securing access to applications outside of the organization, what Microsoft call Extranet use.

Users connecting from outside the corporate network will be prompted after successful AD username/password authentication by the MFA handler.

When the MFA policy is set globally, this can be seen in PowerShell via the Get-AdfsAdditionalAuthenticationRule

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://schema s.microsoft.com/claims/multipleauthn");

If a global authentication policy is not specified, but the policy is enabled in a relying party rule, then an additional authentication rule, defined on the RP, is evaluated. This allows for a more refined use of policy and I’ll show examples of this, by way of scenarios, later in the post.

The AD FS Management UI is sufficient for applying the use of MFA in most single “context” access scenarios. By this I mean, we are able to enforce the requirement of MFA to satisfy policies, that stipulate additional authentication is required by use of one of either user/group, device or location. For example, if we determine that a MFA policy needs to be used by location only, e.g. Extranet, we simply select the Extranet location checkbox. All users connecting from outside of the corporate network must then use MFA. Conversely, if we want to enforce MFA for a specific subset of users/groups, irrespective of their location (Extranet/Intranet), by adding them via the users/groups option in the UI, this can be also be set. Finally, we can also specify that unregistered or registered devices (a la Workplace Join) need to use MFA, via the devices checkboxes. The fact that these policies may also be applied independently on a per relying party basis, often satisfy basic access policy needs.

The challenge arises when dealing with a combination of policy, for example, when stating an MFA requirement by device and by location.

AD FS will now trigger MFA when an unregistered device (non-workplace joined) connects to AD FS AND also when users are connecting from the Internet The policies are evaluated independently and we may unwittingly be enforcing MFA for a registered device in a Workplace Join scenario, when the desired outcome was actually to ensure that a single authentication factor (the device certificate paired with the user concerned) was sufficient for access from the outside. This is the logical OR behavior that Ramiro refers to in his post.

Similar behavior can be observed if the following settings are made.

Here we have a specific user/group requiring MFA and also the location (Extranet) checkbox is checked. Users who are members of the GU-SEC-ADFS-MFA group must always use MFA, irrespective of their location AND other users, connecting from outside of the corporate network, will be challenged by the MFA handler. Again, if the intention was to enforce MFA for a combination of outcomes; namely, by group and location outside, then this is not the outcome.

Rules are evaluated independently when set via the UI. Given that requirements via the UI operate this way, if there is a requirement to enforce MFA via policy where:

it’s an unregistered device AND
connecting from the Internet

OR in the second example where:

user is member of group X AND
connecting from the Internet

The AD FS Management UI doesn’t support this arrangement. Instead, more refined policies can be handled with PowerShell, using combinations of authentication rules. As with the UI, this can be expressed either as a global authentication policy applicable to all relying parties (Set-AdfsAdditionalAuthenticationRule) or MFA policies defined on a per relying party basis (Set-AdfsRelyingPartyTrust). I’ll use the latter to drum up examples of setting finer-grained access rules in the scenarios that follow. More work for us admins, but greater flexibility to boot…

Scenario A: Externally connecting workplace joined device (registered user)

Requirement: Registered users on Workplace Join devices connecting from outside the corporate Internet may authenticate using the device authentication certificate. All other users/devices must use MFA.

$rp = Get-AdfsRelyingPartyTrust –Name "WIF Test Application"
Set-AdfsRelyingPartyTrust –TargetRelyingParty $rp –AdditionalAuthenticationRules ‘c: [Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] && [Type == "http://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser", Value == "false"] => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn");’

Scenario B: MFA for External Access by Security Group

Requirement: Users who are members of Group X, when connecting from outside the corporate network, must use MFA.

$rp = Get-AdfsRelyingPartyTrust –Name "WIF Test Application"
Set-AdfsRelyingPartyTrust –TargetRelyingParty $rp –AdditionalAuthenticationRules ‘c: [Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "S-1-5-21-Insert your Group SID here"] && [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");’

Scenario C: MFA Security Group Exception for External Access

Requirement: Users who are members of Group X are exempt from a general policy stipulating use of MFA when connecting from the outside of the network. All other users must use MFA. Note: We flip the behavior with the Group SID claim use in Scenario B by using the NOT EXISTS evaluation.

$rp = Get-AdfsRelyingPartyTrust –Name "WIF Test Application"
Set-AdfsRelyingPartyTrust –TargetRelyingParty $rp –AdditionalAuthenticationRules ‘exists([Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"]) && NOT EXISTS ([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "S-1-5-21-Insert your Group SID here"]) => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn");’

Scenario D: MFA using a custom evaluation rule

Requirement: The Azure Sprout organization is using “vanity” UPNs to enforce MFA for non-standard UPN suffixes. Corporate users with an @azuresprout.com UPN suffix may use single factor (forms) authentication from the outside. All other UPN suffixes in the “organization” must use MFA.

$rp = Get-AdfsRelyingPartyTrust –Name "WIF Test Application"
Set-AdfsRelyingPartyTrust –TargetRelyingParty $rp –AdditionalAuthenticationRules ‘NOT EXISTS([Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn", Value =~ "^.*@azuresprout\.net$"]) => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn");’

Scenario E: MFA based on custom claims extrapolated from an attribute store

Requirement: An SQL attribute store is used to augment claims when accessing a business application. Values extracted from the store are to be used as triggers for MFA.

On the relying party, we connect to an attribute store and populate an sqlrole claim, based on running a stored procedure to find the user and the appropriate access information for user on application FOO.

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"%5D => add(store = "SQL Attribute Store", types = ("http://schemas.microsoft.com/ws/2008/06/identity/claims/sqlrole"), query = "EXEC dbo.GET_ACCESSTOKEN @UserID={0},@AppCode=’FOO’", param = c.Value);

Next, on the RP pipeline, we define the MFA requirement based on value returned in the sqlrole claim .

$rp = Get-AdfsRelyingPartyTrust –Name "WIF Test Application"
Set-AdfsRelyingPartyTrust –TargetRelyingParty $rp –AdditionalAuthenticationRules ‘c:[Type == http://schemas.microsoft.com/ws/2008/06/identity/claims/sqlrole”, Value =~ "<Whatever the response we’re expecting for MFA trigger>"]) => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn");’

The latter scenario is a little more unusual, but I’ve used it to highlight what is possible (as with Scenario D) outside of the normal conventions provided by the UI.

As a sneak peek into the new Window Server “10” release, it appears that Microsoft have expanded authentication support and making the nuances of policy-based access control more accessible to the end user, through the use of a new policy template editor, made available to the AD FS administrator.. more on this and another ADFS “stuff” to come…

Here’s a snippet of the new rules editor from the pre-release.

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!

Step-up Authentication Scenarios with AD FS 2.0 Part II

July 30, 20132FA, AD FS 2.0, Certificates, Claims-based Authentication, MFA, SAML 2.0, Windows Server 2012 R2, WS-FederationAD FS 2.0, Claims-based Authentication, MFA, Multi-Factor Authentication, SAML 2.0, Windows Server 2012 R2, WS-Federationmylo

With the R2 preview of AD FS in Windows Server 2012 out and the large number of changes that are taking place in the new release, I’m going to be bring this post to a quick end; more an abridged version than was originally intended.

In Part I we looked at weaker authentication schemes for step-up scenarios. In Part II, we move onto two-factor/multi-factor authentication (2FA/MFA) use cases.

There’s no real guided approach for doing this in AD FS 2.0, with solutions invariably becoming customized ones, according to the desired use case. Whether AD FS is the authentication provider or occupying a hybrid/broker role, the use of authentication contexts, types and URIs provided by the supported SAML and WS-Federation protocols, become triggers for step-up. Where a context is stipulated, in protocol terms, each is interpreted differently.

SAML supported authentication methods

Authentication Method	Authentication Context Class URI
Username/Password	urn:oasis:names:tc:SAML:2.0:ac:classes:Password
Password Protected Transport	urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
Transport Layer Security (TLS) Client	urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient
X.509 Certificate	urn:oasis:names:tc:SAML:2.0:ac:classes:X509
Integrated Windows Authentication	urn:federation:authentication:windows
Kerberos	urn:oasis:names:tc:SAML:2.0:classes:Kerberos

As we saw in the previous post, forcing authentication in SAML logon scenarios provides support for step-up, but at the expense of single sign-on. In passive federation scenarios, if we don’t specify an authentication method in the request, AD FS will apply authentication according to its own supported methods, attempting to match those against the local authentication types section of the web.config on the AD FS node.

AD FS handles the SAML authentication in order of strength, lowest to highest, from top to bottom as seen in the table: in the default configuration Kerberos is seen as the strongest method. The precedence of the authentication method can be adjusted using the Set-ADFSProperties –AuthenticationContextOrder command to ensure the order meets the requirement we need. The SAML comparison attribute can be used to also influence the authentication method chosen. with AD FS defaulting to a comparison=exact attribute.. As stated in the MSDN article Authentication Handler Overview, if the comparison attribute is set to “better”, “minimum”, or “maximum”, the method of authentication must be stronger than, at least as strong as, or no stronger than one of the specified authentication classes. This gives us some latitude for using it to invoke the desired authentication method through customization of the sign-in process. With SAML the authentication reference is encoded in the SAML request, and to access and to use the information therein, in order to relay the authentication request to our third-party IdP, we need to customize our sign-in process so that the incoming SAML (AuthnContextClassRef) request is decoded. The information we then need needs to be extrapolated so that we can then make the correct routing decision, sending the client to the correct provider. Examples provided on Codeplex hint at how this can be done, by assigning a authentication methods to a relying party using FBA and IWA.

On the other side, let’s look at an example using a WS-Federation based setup.

WS-Federation Passive Profile supported authentication methods

Authentication Method	Authentication Context (wauth) URI
Username/Password	urn:oasis:tc:SAML:1.0:am:password
Transport Layer Security (TLS) Client	urn:ietf:rfc:2246
Integrated Windows Authentication	urn:federation:authentication:windows

With the WS-Federation passive requester profile, the authentication type (wauth) parameter is specified in the query string of the browser or can be specified from the relying party application itself. The whr parameter is used to indicate the claims provide to use for logon.

MFA Step-Up Scenario

Let’s look at a step-up scenario using WS-Federation with an MFA provider.

In the above graphic, we have a third-party MFA provider handling the authentication requests for internal access.. I’ve not included the AD FS Proxy for external access, but should we wish to do so, we could adopt our AD FS proxy configuration and:

– remove the local authentication handlers from the <localAuthenticationTypes> section of web.config to ensure that MFA is always used in external access scenarios;

– follow the same methods used for internal authentication described below;

Internal access step-up scenarios imply the use of the default Integrated Windows Authentication (IWA) handler and the step-up mechanism. With a third-party multi-factor authentication provider, the (MFA) solution is configured within AD FS 2.0 as a claims provider. I’ll use the example of the WIF-based STS from PointSharp which I mentioned in previous posts.

In a step-up context, the STS needs to be able to process the required authentication request and pass this back to AD FS and the RP. With WS-Federation we can do this via the browser as a query string, or, from the web application make use of the wauth and whr parameters to set the authentication method.

Step-Up at the Relying Party Application

Using the WIF 3.5 SDK samples for our relying party, we modify the web.config to specify the desired authentication type. I’ve chosen the X509 certificate handler. For our WIF application this corresponds to an authentication method value of urn:ietf:rfc:2246

The homeRealm value is used to specify the claims provider we want to call for step-up, otherwise AD FS itself will attempt to handle the logon, treating as an authentication request for an x509 certificate.

On AD FS we configure the IP-STS as a claims provider.

On the IP-STS, we configure AD FS as a relying party

For convenience, both the STS and AD FS are sharing the same identity store (AD) and I’ve created a test user called demo in Active Directory and a security group called OTP, whom our user is a member of. We’ll use membership of that group on the PointSharp STS as a means of emitting an authentication method claim that corresponds to the expected authentication type. The claims value, urn:ietf:rfc:2246, is returned when a user logs on using MFA (e.g. OTP+password).

The user demo points their browser to the RP URL and with the web.config modifications, the access request is redirected to AD FS and then to the PointSharp STS as the Windows home realm (whr).

On the PointSharp STS during logon, the back-end PointSharp ID services handles the MFA logon request. At the initial prompt, the user enters their user ID and AD password:

They’re challenged to enter an OTP response (hardware/software token or SMS)

Once authenticated, the STS then processes the matching claims rules.

Above, demo is a member of the group OTP, as seen in the claims rule pattern, so a claims type of http://schemas/microsoft.com/ws/2008/06/identity/claims/authenticationmethod is generated. This is used to match the expected reply of the RP with a value urn:ietf:rfc:2246. and this claims is then passed back to AD FS.

In our test web app we see the appropriate authentication method and values being returned. No claims rules on the claims provider or relying parties (at this point) have been done.

Our MFA provider may also support multiple authentication types (AD password, SMS, tokens etc), so the fact that we logon at the STS is not necessarily indicative of a sufficient logon.With AD FS as the RP-STS, we can also block requests that don’t emit the correct authentication method at the STS on the relying party claims pipeline.

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value =~ "^(?i)http://schemas\.microsoft\.com/ws/2008/06/identity/authenticationmethod/tlsclient$"]
=> issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "PermitUsersWithClaim");

With the authorization rule in place, another user, demo2, that is not a member of the OTP group, when accessing the RP, logs on at the PointSharp STS, but gets the following error at AD FS:

This translates in the event log to an access denied message:

The Federation Service could not authorize token issuance for caller ”. The caller is not authorized to request a token for the relying party ‘https://rp……..’. Please see event 501 with the same instance id for caller identity.

While we can block in this fashion, it makes more sense to enforce and evaluate a more fine-grained access at the application itself. If the app is intended as an internal-only application though, we can also block access from the AD FS proxy via an access rule.

exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy”]) => issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”);

Step-Up within the Application

The previous steps described step-up at the web application (relying party), rather than within the application itself. The WIF 3.5/4.0 SDK provides samples for step-up authentication using an example of a low-value and a high-value resource within a given application. Here we’re leveraging step-up against a particular resource within an application.

Low-value resources are protected using normal Windows logon credentials (IWA), whereas high-level resources trigger step-up through the use of the certificate handler.

This allows us to add in step-up authentication within the application itself, according to the value of the resource.

A note on Virtual Smart Cards

I mentioned in the last post about virtual smart cards (or VSCs). As an authentication provider, they are available during Windows logon as a credential provider. Given that we wish to expressly enforce step-up at the application, then some sort of adjustment is equired. It may be possible to suppress the use of the VSC as a credential provider and make it available post-logon for application-only access, something that I’ve not tried, but one could argue that this is a case of the tail wagging the dog. We could also use an alternate account as described in Part I or disable single sign-on in the web.config on the AD FS farm to enforce logon between relying parties. The fact that we’re using IWA for normal logon masks somewhat the behaviour of revisiting the AD FS server when switching between IWA-based relying parties.

As ever, please extensively test before considering doing this sort of thing in a production environment.

Alternatives

What’s been discussed so far relates to solutions that are on the “direct” authentication path from an identity federation standpoint. There are also MFA solutions that involve indirect authentication using multi-factor authentication. When I refer to Indirect MFA, Í mean some other component outside of the federation logon process that handles the strong authentication aspects of logon. Diagrams always help to illustrate the cause Smile …

1. Via a non-federation capable proxy or gateway component. This component does not integrate with AD FS, but can provide an MFA capability. All connections to the RP are through the proxy. Post-logon, the proxy does some form of credential delegation to the back-end AD FS service. Here’s an example of a logon scenario with Forefront UAG 2010 on a non-federated trunk. While UAG does support federated trunks (as a relying party), MFA on a federated trunk is not (to my knowledge) possible unless we use an upstream claims provider.

2. Via an MFA web agent running on the ADFS proxy as an ISAPI filter or module. This follows the traditional web access management approach of logon via a web agent, with the filter intercepting the call. The user must logon using the stronger form of authentication before the web application, in this case the AD FS proxy pages are exposed. While functionally “integrated”, the two operate technologically independent of one another.

3. Via customization of the AD FS sign-in pages, allowing authentication to a MFA provider through web services. Of the three, this is (in my mind) is the most technically plausible, but handling step-up in such cases would also be complex and I’ll refer to that in a moment.

None of the above mechanisms are particularly well suited to step-up because the MFA logon process wraps around normal AD FS logon process, rather than integrating with it. While they may be valid in other access scenarios, i.e. the logon request is intercepted by a handler that doesn’t understand federated logon.

Option 3 is interesting as, via a slight modification, it supports illustrating where MFA is going in the next release of AD FS in Windows Server 2012 R2.

Windows Server 2012 R2

In AD FS R2, Microsoft are making available an MFA API for vendors to plug-in to and integrate with the federation service directly, allowing for a more rich logon experience. This also extends the concept of using multi-factor authentication not only at a protocol and application level, but at a policy level too, whereby policy per relying party for authentication is achievable. It also suggests that the redirect method via claims providers is being eschewed by Microsoft in favour of a more AD FS centric approach. I suspect the aim here is to provide a more level playing field for integrating external authentication providers with AD FS rather than placing the burden on the vendor and heavy use of customization to support scenarios described..

What this means for step-up scenarios we shall see. I’ll be looking at this raft of new features with AD FS R2 in future posts.

Virtual Smart Cards (VSC) and AD FS 2.0

July 6, 2013AD FS 2.0, Certificates, Claims-based Authentication, Multi-Factor Authentication, PKI, Window Server 2012, Windows 8AD FS 2.0, Certificate Services, Claims-based Authentication, MFA, Multi-Factor Authentication, PKI, Virtual Smartcard, VSC, Windows 8, Windows Server 2012mylo

Before I finish the second article on Step-Up Authentication, I thought I’d write something quick about Virtual Smart Cards (VSC), as they also feature in the next post.

While Windows 8 has been taking lots of flak for various UI changes, there are a number of nice new features that have snuck in rather quietly. One of these is support for Virtual Smart Cards (VSC). VSC’s provide an alternate strong authentication mechanism that removes the need for a physical smart card reader. They emulate the use of a physical card reader via the use of the Trusted Platform Module (TPM) found in most modern business-grade computers. The TPM module stores the private key of the virtual smart card. While, it’s not two-factor authentication per se, (the virtual smart card is stored on the same device as the crypto module), it is nonetheless an improvement strength-wise over username/password and software-based digital certificates. We’ll give it the official 1.5x times authentication moniker (1.5FA) Smile .

Private keys are stored in the crypto functionality of the Trusted Platform Module (TPM) of the laptop. The private key is device centric, with the virtual smartcard stored on the same computer. The TPM module needs to be enable on the computer. This can be done manually (woo-hoo!) or via some form of script, or in conjunction with vendor client instrumentation software.

VSCs provide a number of nice features, but they add a little more added complexity in the setup stakes. Given that we’re emulating physical smart card behaviour, we’re going to need a certificate and that means Certificate Services and an enterprise Public Key Infrastructure (PKI).

I’ve used a Windows 2008 R2 CA in this example. On the enterprise certification authority (CA) we can duplicate the built-in Smartcard Logon template found in certificate services using the V2 Windows Server 2003 compatible template.

With our new template, entitled Virtual Smart Card, on the Request Handling tab set the certificate purpose to Signature and Smart Card Logon and the minimum key size to 2048. On the Cryptography tab set the cryptographic provider to the Microsoft Base Smart Card Crypto Provider.

Give (authenticated) users Enrol permissions on the Security tab of the template and then issue the new certificate template.

We can use the built-in tool TPM Virtual Smart Card Manager (tpmvscmgr) to provision the smart card.

tpmvscmgr.exe create /name Auth360Test /adminkey random /generate

The generate command formats the TPM virtual smart card so it can be then used to enrol for certificates.

From a LAN or DirectAccess connected PC we can enrol via use the MMC Certificate Users snap-in, using the Request New Certificate option

Select the Virtual Smart Card template.

During enrolment a PIN needs to be set.

With the VSC enrolled. we can now logout and the virtual smart card should be available for logon.

Click on our enrolled user and then logon with our PIN.

I thought I’d give this a whirl with AD FS. For the purposes of this exercise, to support VSC smart logon, I changed my AD FS proxy configuration to support client certificate authentication, modifying the local authentication types parameter in the web.config on the AD FS proxy. We’ll cover other logon scenarios using VSCs in the next Step-Up authentication post.

Meanwhile, TLSClient (SSL Client Certificate) is elevated to the top of the list and switched with the default Forms authentication.

Users accessing the AD FS proxy with a VSC now get a prompt to select their certificate

Having highlighted and click my user, I now enter the PIN.

Users not possessing a ~~smart card~~ user certificate will get a 403 error.

The problem with this approach is that it’s a little generic. We’ve simply configured AD FS to authenticate users based on the presence of an X509 certificate.

We could always add our VSC users to a security group and reflect this in an authorization claim in AD FS, Even better we could configure authentication mechanism assurance and add an issuance policy to our virtual smart card template and then link that policy to a security group. Microsoft provide a couple of Powershell scripts to allow this, The Object Identifier (OID) of the certificate authenticating at AD FS needs to correspond to the linked claims rule to the OID in our “Virtual Smart Card Authentication” security group. We’ll look at this in a future post about Bring Your Own Device (BYOD), Workplace Join and Work Folders, new features in Windows 8.1.

Claims-based access with AD FS 2.0 and PointSharp Identity Federation

April 18, 2013AD FS 2.0, Claims-based Authentication, PointSharp, Strong AuthenticationAD FS 2.0, Claims-based Authentication, PointSharp, Strong Authenticationmylo

In previous articles we’ve looked at inter-op scenarios with AD FS using gateway solutions such as Juniper SA, Microsoft Forefront UAG 2010 and access management platforms such as OpenAM. In this post, we’ll look at using AD FS 2.x with a Windows Identity Federation (WIF)-based Security Token Service (STS) from PointSharp (www.pointsharp.com). This provides us with a broader authentication platform than AD FS from which to make access control decisions.

In a default configuration, AD FS 2.0 makes use of the local Active Directory as an authentication service. As administrators, we may also wish to further extend authentication options available to AD FS. A number of mechanisms are available, allowing us to hook into third-party authentication services.

via plug-ins/agents exposed through IIS, either on the AD FS Proxy/Farm to connect to other authentication providers;
customization/ coding sign-in pages to connect directly to authentication providers via web services or other custom methods;
through a federation trust to another provider, e.g. an IP-STS/IdP.

Option 1 is the traditional access management method, using non-federated agents/filters to wrap around IIS. This approach is often independent of AD FS. Option 2 involves customizing the logon process within AD FS, e.g. customizing forms-sign-in pages to hook into back-end web services APIs that the third-party authentication service may provide. Option 3 is the claims provider route using the federation trust model. PointSharp cater for all three solutions. However, I’ll concentrate on Option 3, using their Security Token service (STS) as a strong/two-factor authentication provider .

To highlight a working scenario, let’s set out some basic requirements:

External users, including corporate users, must connect through the third-party STS using various authentication types, according to the desired requirements:
- Two-factor authentication (hardware token, soft token or SMS)
- An alternate password credential store (non-AD)
- Credentials from the Corporate directory (e.g. AD)
Internal users, connected to the corporate LAN, should be able to connect to relying parties using their Windows logon credentials (Kerberos/NTLM).
Applications must support SAML or WS-Federation in an external facing scenario and IWA (Kerberos/NTLM) for internal users.
The solution should support claims-based access control to the federated web application according to the desired authentication method

The PointSharp Identity Federation component (STS) is a .NET / Windows Identity Federation (WIF) application. It services authentication requests by connecting to a core-access management application via web services.

In logon flow terms, an abridged view of the process is:

The external User connects to Relying Party Web Application
Browser redirect to AD FS Proxy. AD FS local authentication types are disabled. A claims provider is defined and the authentication request is passed to this.
Browser redirect to PointSharp Identity Federation STS. User logs on. Policy-based access control and claims processing is performed. SAML token is issued.
Browser redirect to AD FS (RP-STS). Perform claims processing on Claims Provider and Relying Party.
Browser redirect to Relying Party for authorization and access to application.

Users connect to the PointSharp Identity Federation claims provider (configured) via AD FS, to provide two-factor authentication for external access scenarios. In order to bypass the (in-built) AD claims provider for AD FS external access, whilst continuing to provide a Windows SSO experience to corporate users, we make a couple of configuration changes in AD FS proxy and farm nodes:

Disable all local authentication types on the AD FS Proxy to pass authentication requests to the PointSharp STS. This is done to bypass home realm discovery (HRD) mechanisms and remove the proxy as an authentication layer. We do this by removing the forms, basic and X509 authentication types within the web.config of the AD FS Proxy in the microsoft.identityServer.web section:

On the local AD FS farm we adjust settings to ensure that the default Active Directory claims provider, not the PointSharp claims provider, is used for authentication of users connecting via the internal/corporate network. We do so by customizing the homerealmdiscovery.aspx.cs on the AD FS farm to ensure that the AD claims provider is used for Windows logon. Refer to this blog article on how to accomplish this.

With the above changes, all logon requests via the AD FS proxy will now be handled by the PointSharp STS.

Before continuing further, let’s look at how the PointSharp Identity Federation component (STS) and the backend PointSharp authentication services work to support desired authentication types. To accomplish this, we’ll need to dig a little deeper into how identities are stored/used within the configuration.

Configuration Storage

As with the majority of Access Management (AM) solutions out there, it’s worthwhile pointing out the distinction between a store used for identity (read-only) lookup purposes, such as a user repository, versus the store the AM solution uses for holding (writing) configuration options concerning user/profile/preferences. Typically, configuration or data storage is represented in a single aggregate store where information about access identities is written. Conversely, user storage(s), may consist of multiple repositories, which we read user information from. PointSharp uses an LDAP store, e.g. AD LDS, AD or other LDAP v3 compliant servers for configuration/data storage. The store retains information concerning the users profile, the authentication methods used/supported, additional secrets etc. Sensitive information within the store is encrypted or (optionally) the entire storage container itself.

User Storage

In PointSharp lexicon, user storage is used to define an entry point within a repository for basing scoped searches/extractions from. We can then subsequently target items extracted for authentication/authorization processing. User storage may be one or many directories (AD/LDAP) or specific containers (organizational units) within one or many directories. Optionally, we may then target a desired authentication method against defined user storage types.

With a given user storage, via scoping options and the use of an LDAP filter , we define objects of “interest” in the storage and, at an attribute level, define various attributes, e.g. logon ID, to be used. This could be a security principal such as sAMAccountName, userPrincipalName or uid, subject to the object class. In the above screenshot, a User Storage called “inetOrgPerson” has been created, and within this store (AD), searches have been limited to include object classes of the inetOrgPerson type from given OUs. The (LDAP) search filter in the chosen user storage is:

(&({usernameAttribute}={username})(objectClass=inetOrgPerson)(objectCategory=person))

There’s some latitude here on what we may wish to include/exclude as objects of interest, for logon purposes, abstracted from the logon process normally associated to the native directory. For example, disabled accounts, which might sound bizarre, can also be exposed via user storage. Attributes such as UserAccountControl are available to expose/include in a scoped search within user storage, thereby allowing subsets of users for remote access, not normally available in a local authentication context to be used. We may wish to make these available purely for external access. In practical terms, imagine that we have a subset of users that we don’t want to be able to interactively logon to AD, from a domain-joined PC, yet should be able to logon externally (only) via our Identity Federation STS. Here’s an example of an LDAP scope that targets disabled users to be defined at a storage level.

(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=2))

User storages are processed iteratively. We can include a number of user storage types according to access needs and once we’ve defined them, identify the types of authentication we wish to use directly (via the storage) or indirectly through access policy.

Authentication Services

PointSharp, through back-end authentication services, provide authentication types available directly through listeners via web services or RADIUS, according to the access scenario. Since we’re dealing with identity federation here, this equates to web services. At this point, we can make available a given authentication type to be used in the identity federation process (e.g. SMS) or elect to use a more fine-grained policy-based authentication process. Smart Authentication (SmartAuth) refers to a policy-based / attribute-based access workflow executed during logon. Through these policies the authentication type to use for a connecting user is determined. This allows for more granular authentication flows to meet requirements. Moreover, this can also be further refined at the (front-end) Identity Federation component (STS) via claims-based access control.

Using the user storage concepts, let’s have a look at two identity federation scenarios. The first is a “basic” approach using the default Active Directory, available as a user store for moderating external access.

Basic Scenario (Single Storage)

In the above setup, we’re “scoping” our storage based around using various OU’s within AD. The first storage uses sAMAccountName for internal users using their Windows logon ID, the second uses userPrincipalName (UPN) for external users. In this example, sAMAccountName is analogous to EmployeeID and userPrincipalName to the emailaddress of the external user. Each respective set of identities live within their own OU’s within Active Directory.

Complex Scenario (Multiple Storage)

Similar to the basic setup, we’re also scoping our user storage at OUs within a given store. In this case we’re also adding additional repositories, such as a Partner/Affiliates store (e.g. Extranet), to pull in their identities for usage in logon scenarios ….

With the user storages defined, we then define individual authentication types within the back-end PointSharp authentication service and expose these as individual listeners, invoked directly by the caller. In our case, this is the PointSharp Identity Federatrion component calling a smart authentication rule. to adopt more fine grained authentication decisions at logon.

In the above policy, I’ve elected to use membership of a Windows group (in user stores) to target required authentication types. This involves static management of a group, so it may be less desirable than using something like a UPN or Email address, matched against a particular suffix to offer a more dynamic evaluation.

For example, a dynamic evaluation can be used, as in the above example, to attach an authentication method to users with an @auth360.net UPN suffix to use an OATH token. I’ll cover dynamic evaluation using directed authentication types and responses in a later post.

With PointSharp Identity Federation, we specify the use of a smart authentication rule as the authentication method

Users logging on from a relying party externally are redirected to the PointSharp STS. (Note: I’ve already setup the PointSharp STS up as a claims provider within AD FS).

Within the PointSharp authentication service, if you recall from the earlier MemberOf smart rule graphic, we’ve identified four authentication types: OATH, SMS, PointSharp Password and AD Password. OATH tokens are event or time-based OTP schemes using hardware, software and SMS-based logon mechanisms. Both support (optional) challenge/response password/OTP combinations from the user repositories and the login process adapts to this according to the rules defined with the PointSharp authentication service. In addition, the PointSharp Password is an alternate login credential that can be called upon and is used in cases where customers do not wish to employ two-factor authentication, nor expose the AD password to external access. Instead, they wish to use a separate password source, independent of AD, with separate password/lockout policies, that can be used to provide claims-based access via the PointSharp STS to their web applications. Should we also we wish to make AD password-access available as a possible authentication type, this is also included in the example. Remote lockout conventions can also be applied to AD users, independent of the AD password policy, to ensure that remote access lockout does not necessarily incur a AD password lockout, and to prevent Denial of Service (DoS) lockout on a given user.

Within the PointSharp authentication service admin UI, in a storage called AUTH360, four users have been created for testing:

oathman is a user using an OATH token (hardware token / soft token)
smsboy is a user using an SMS authentication method
psidgal is a user using a PointSharp password
adkid is a user using an AD password

From within PointSharp Identity Federation (STS ) we can define claims-based access rules to be passed onto AD FS. To accomplish this, we create custom claims rules on the STS that conform to the authentication type we desire. This is then injected in the SAML token and consumed as a claim by AD FS, as the RP-STS, for further processing, and passed on to the RP. For example, the four authentication types defined within the SmartAuth rule are now processed at the STS :

These are passed back via the custom claims definition:

http://schemas.auth360.net/ws/2008/06/identity/claims/access

On AD FS, we create a claims description that conforms to the above description

On the PointSharp Identity Federation claims provider, we pass the above claims as well as any additional claims that we also elect to emit. On the claims provider pipeline in AD FS, we configure Acceptance Transform rules to pass the Access Type claims and any other rules that the Claims Provider STS has made available:

On the relying party application we define our issuance transform rules.

I’m using SimpleSAMLphp, a SAML 2.0 Service Provider, as my Relying Party. AD FS, as a broker, provides the necessary bridging between the WS-Federation passive STS of PointSharp and, in this case our SAML 2.0 RP. In the “groups” claim we pass an inbound custom customs claims definition that transforms the authentication method http://schemas.auth360.net/ws/2008/06/identity/claims/access and emit this as a SAML attribute that SimpleSAMLphp can then consume:

c:[Type == http://schemas.auth360.net/ws/2008/06/identity/claims/access] => issue(Type = “groups”, Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

I’ve setup up a basic “Hello World” PHP application, which calls the SimpleSAMLphp libraries and then display the processed attributes in the web page. In our example, the access type (and authentication type) is expressed via the groups SAML assertion in array [0] –LOA4-AD. This is a user logging on who is a member of group LOA4-AD (using AD credentials).

Array
(
    [groups] => Array
        (
            [0] => LOA4-AD
            [1] => users
            [2] => members
        )

    [http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn] => Array
        (
            [0] => adkid@auth360.net
        )

)

At the relying party, we’re now at liberty to make authorization decisions based on the incoming claim, according to the strength of the authentication type. I’m using SimpleSAMLphp here as an example, but the same conventions can be applied to other WIF-based RPs/STS such as SharePoint.

In a future post, I’ll look at more refined policy assessments using access based on dynamic evaluation and SAML authentication contexts such as SAML AuthNContextClassRef and WS-Fed AuthenticationMethod in RP/SP initiated-sign-on scenarios. Meanwhile, I hope you enjoyed the post.

SAML 2.0 IdP-Initiated Sign-On with RelayState in ADFS 2.0

December 16, 2012AD FS 2.0, SAML 2.0ADFS, Claims-based Authentication, SAML 2.0mylo

Ýet another riveting title Smile Dispensing with WS-Federation, we’ll move onto looking at SAML 2.0 integration with AD FS, in particular IdP-Initiated sign-on. In the last few posts we’ve looked at how AD FS 2.0 admins can manipulate the use of the whr function to assist in the realm discovery process as part of sign-in to AD FS using WS-Federation. With AD FS 2.0 and SAML 2.0, a long-awaited feature has been support for SAML 2.0 RelayState. With Rollup 2, the AD FS team have come up with the goods. Like whr on the WS-Federation side, the use of RelayState allows us to support IdP-Initiated login from a SAML 2.0 identity provider (IdP).

Before we look at some examples, here’s a few useful tools to aid building and debugging the use of RelayState.

1. The excellent SAML Tracer plugin for Firefox (https://addons.mozilla.org/en-US/firefox/addon/saml-tracer/)

2. A relay state generator for AD FS 2.0 to aid us in building the necessary call-back to AD FS. (https://adfsrelaystate.codeplex.com/)

3. A URL Encoder/Decoder to validate the syntax used for constructing the Relaystate query string. I used this one.. http://meyerweb.com/eric/tools/dencoder/

To get started, there’s a nice article on the Directory Services blog at Microsoft, as a backgrounder to understanding what’s going on via Rollup 2 and RelayState. http://blogs.technet.com/b/askds/archive/2012/09/27/ad-fs-2-0-relaystate.aspx.

Let’s have a look at how these scenarios may pan out. Putting my rudimentary skills in Visio 2013 to the test, here are three examples:

EXAMPLE 1: Remote SAML 2.0 Identity Provider

In the above example, our user needs to connect, via the Internet, to a remote web application that is configured as a SAML 2.0 Service Provider. This service provider is engaged in a federation trust with AD FS. AD FS as a Relying Party Security Token Service (RP-STS) has the SAML 2.0 Identity Provider (IdP), in the home realm of the user, configured as a claims provider (CP).

EXAMPLE 2 : Remote SAML 2.0 Identity Provider and Service Provider

In the above scenario, both the service provider (SP) and the identity provider (IdP) are remote to the organization. This could be a cloud / SaaS application that the RP-STS organization provides access to to both its users and the remote identity provider organization.

EXAMPLE 3 : Remote SAML 2.0 Service Provider

In the above example, the Identity Provider (IdP) and AD FS are part of the same organization. The IdP could be an Access Management platform such as OpenAM, a remote access gateway such as a Juniper SA, or an Extranet ADFS instance with the AD FS RP-STS acting as a broker.

Access Scenario

Let’s look at some of the pre-requisites on the AD FS side:

1. Install AD FS 2.0 Rollup 2 on all instances where AD FS is involved: proxies, farm members and also third-party organizations if AD FS is installed there.

2. Add the following change to <microsoft.identityServer.web> section of the IIS web.config of all participating AD FS instances, under the /adfs/ls path.

<microsoft.identityServer.web>
<useRelayStateForIdpInitiatedSignOn enabled=”true” />
</microsoft.identityServer.web>

In this example we’ll evaluate ADFS in a SAML 2.0 Identity Provider (IdP) role within a third party Organization, called Fie, and also as a Relying Party Security Token Service (RP-STS) within the resource organization (Foo). Fie Users may click on a hyperlink or a bookmark that kicks off the logon process with their IdP, and through the use of RelayState, via the parameterized Relying Party Identifiers provided to the IdP and RP-STS ADFS instances, the user is sent to the service provider application.

For our web application and SAML 2.0 SP, I’m going to use cloud provider OneLogin. This will act as an application portal. Once logged on via the IdP, the user is sent to the OneLogin portal thru the RP-STS of Foo. Referring to the diagrams above, this access scenario probably best fits Figure 2. Since the web application belongs to Foo, we’re using an indirect trust involving the Foo ADFS instance as an RP-STS. Fie is a claims provider (CP) to the Foo organization ADFS and the web application is a SAML 2.0 Service Provider (SP) that trusts the ADFS instance as an Identity Provider (IdP).

Here are the service endpoints and relying party identifiers that we need to use to build the appropriate link.

IdP (ADFS) = sts.fie.com
RP-STS (ADFS) = sts.foo.com
SAML 2.0 SP = app.onelogin.com
Foo STS Relying Party Identifer (RPID) = http://sts.foo.com/adfs/services/trust
SAML 2.0 Relying Party Identifier (RPID) = https://app.onelogin.com/sessions/saml

Using the new notation provided in Rollup 2, two relying party identifiers (RPID) are required in order for the relay to the web application to work correctly. The RPID in ADFS terms is the identifier. For a SAML 2.0 SP, this is the Entity ID of the web application. In some scenarios the entity ID may not be sufficient and additional parameters required. Refer to the Microsoft article mentioned earlier on how this may be further encapsulated into the RelayState. I’ve included the URL encoded and decoded syntax below to give you an idea the syntax we’re forming.

Here’s the URL Decoded link, broken into three parts:

https://sts.fie.com/adfs/ls/idpinitiatedsignon.aspx
&RelayState=RPID=http://sts.foo.com/adfs/services/trust
&RelayState=RPID=https://app.onelogin.com/sessions/saml

Part 1 is the URL of the Identity Provider, Part 2 the query string and RelayState for the RP-STS, and Part 3 state for the SAML 2.0 SP.

Users logon on at Fie IdP, either through the AD FS proxy using forms-logon, when connecting externally or with their Windows logon ID thru the ADFS farm. Once we’ve encoded the link, it looks like this:

https://sts.fie.com/adfs/ls/idpinitiatedsignon.aspx?RelayState=RPID%3Dhttp%3A%2F%2Fsts.foo.com%2Fadfs%2Fservices%2Ftrust%26RelayState%3DRPID%3Dhttps%3A%2F%2Fapp.onelogin.com%2Fsessions%2Fsaml

And we hit the OneLogin portal:

I began the post with a smiley, so I’ll end with one.. nice feature Smile ..

Federated SSO Logon with AD FS 2.0 in an Extranet with UAG

June 25, 2011AD FS 2.0, Claims-based Authentication, Forefront UAG, Sharepoint 2010AD FS 2.0, Claims-based Authentication, Forefront UAGmylo

This is one of those “what if?” scenarios with AD FS 2.0 which arose at a customer recently: they wanted to provide secure logon to users in an Extranet Active Directory to web resources in their corporate Active Directory (e.g. Sharepoint). In a pure AD setup, with no third-party SSO products involved, this sort of thing has often been accomplished in the past through the use of a forest trust between extranet and corporate forests. This approach, however, tends to make network and security departments unhappy; with all sorts of firewall ports needing to be opened, making swiss cheese of interior firewalls. With Windows 2008 R2, we can also do this sort of thing by configuring an Extranet AD FS 2.0 instance(s) in the DMZ (limiting firewall traffic to HTTPS only) and then establishing a federation (claims provider) trust between the corporate AD FS and the Extranet. This is similar to the partner or federated SSO scenarios that Microsoft describe in their documentation. In this scenario, the Extranet AD FS instance is analogous to the Account Federation Partner and the corporate AD FS instance to the Resource Federation Partner.

To make this process more interesting (life is never dull), it was suggested we put a UAG in the Extranet (in place of the AD FS Proxy) to support strong/two-factor authentication requirements. This meant that some form of jiggery-pokery with Kerberos Constrained Delegation would be required between the Extranet UAG instance and the Extranet AD FS farm, to ensure that groovy Web SSO experience was maintained all the way to the target web application.

Components

Forefront UAG 2010 SP1 (extranet.mydomain.com)
Extranet AD FS (extranet.mydomain.com)
Forefront TMG 2010 SP1 (sts.mydomain.com)
Corporate AD FS Proxy (sts.mydomain.com)
Corporate AD FS Farm (sts.mydomain.com)
Sharepoint 2010 Farm (sharepoint.mydomain.com

So we have two zones bridged by an AD FS federation trust: an Extranet Zone and a Corporate Zone.

The above is how I configured the sandpit for testing. Our example web application (Sharepoint), is configured as a claims-aware application and the client has bookmarked it as a favourite. He/she is able to link to the Sharepoint site (sharepoint.mydomain.com) directly and this is where the authentication process kicks in. Walking through the process.

1. The client accesses the Sharepoint URL (https://sharepoint.mydomain.com). (reverse proxied through TMG). The Sharepoint web application is configured as a claims-aware web application with the Corporate AD FS 2.0 farm configured as its SP_TrustedIdentityTokenIssuer using e-mail address as the primary claim.

2. The Sharepoint 2010 security token service (STS), a relying party of the corporate AD FS 2.0 instance, redirects the client to the corporate AD FS 2.0 farm. The client is connecting from the Internet, meaning that the fully qualified domain name sts.mydomain.com (for AD FS) on the Internet resolves to a public IP address, namely that of the AD FS Proxy. The client is redirected to the proxy.

3. The corporate AD FS, with the proxy as arbiter for the AD FS farm, possesses two claims providers: the default corporate Active Directory and a claims provider trust setup to point to the Extranet AD FS instance (Partners and Affiliates in the graphic). AD FS itself cannot determine which realm the client belongs to, so when the client connects he/she home realm discovery (HRD) is performed and the client must choose between selecting the corporate or Extranet realm (this process can be automated… we’ll cover this in a later post). As a result of Home Realm Discovery, the client is thereby redirected to the services endpoint for the Extranet AD FS. In this scenario, this translates to the public IP address of the UAG trunk.

4. With the client redirected to the UAG for logon, the UAG server(s) processes the logon request. In this example, UAG is configured to use RADIUS for authentication. This is because we’ve opted for strong authentication (using tokens). RADIUS is being used to bridge the connection between UAG (as a RADIUS client), and the strong authentication provider. The token is submitted via an application running on a smartphone and the client enters the One-Time-Password (OTP) and PIN via the UAG form (4a). The credentials are forwarded by UAG to the RADIUS server (4b) running on the OTP provider. In this example, the user repository for the one-time password is also the Extranet AD (4c), accessed via LDAP. The UAG server(s) are also domain members within the Extranet AD. Once the OTP logon process is complete, we can chain the logon process to perform federated back-end authentication to the Extranet AD FS instance(s), obtain a kerberos ticket from the Token Service using Kerberos Constrained Delegation (KCD). This is possible because the UAG server(s) is trusted for delegation by the AD FS server(s). This process is described in a previous blog post (Federated Identities with UAG 2010 SP1 and Office 365). On the Extranet AD FS, the Corporate AD FS instance is configured as a relying party. We extract the e-mail address from the AD (Send LDAP Attributes as Claims), providing this information to the relying party in a pass-thru rule (issuance transform rules) .

5. When authentication is complete at the Extranet AD FS, an HTTP POST by the client is submitted to the corporate AD FS Passive Federation Endpoint. The Corporate AD FS, acting now as an FP STS, processes the claim according to acceptance transform rules configured (pass thru e-mail), before handing over to the relying party where the issue transform rules are then processed (pass thru e-mail address).

6. The client is then redirected the Sharepoint web application, the e-mail address claim is processed by the Sharepoint STS, and they gain access to the Sharepoint site.

Extranet UAG Configuration

To make this configuration work on the Extranet UAG side, we have to ensure that the federated logon process is not interrupted or interfered with. At the same time we still have to deal with the strong authentication requirement. As stipulated in previous posts, with non-federated trunk authentication we can satisfy both strong authentication requirements and federated logon to the local (Extranet) AD FS instance. This time, however, the resource lives in the corporate realm. UAG is not directly responsible for proxying connections to the Sharepoint web application. Nonetheless, there are some unusual requirements.

On the Extranet UAG, there are three authentication providers configured:

RADIUS/OTP Server
Extranet Active Directory Domain Controller (can be used for Authorization by the RADIUS server)
Extranet Active Directory Federation Services (AD FS)

The AD server is optional should you wish to use AD-based authorization groups with the RADIUs authentication server. The AD FS 2.0 server is required for the Extranet federated logon piece.

Surprisingly, there are also two web application templates that need defining:

A Sharepoint 2010 web application using the Sharepoint 2010 template with the URL of https://sharepoint.mydomain.com
An AD FS 2.0 web application using the AD FS 2.0 template with the URL of the Corporate AD FS instance of https://sts.mydomain.com

Each of these web applications are configured to use the Extranet AD FS server as their authentication server. Without these web applications being defined, the login process fails at the UAG with a “request was unable to reply to an HTTP 401 request from application AD FS” being logged within the UAG Web Monitor. This one had be stumped for a while as UAG is not responsible for proxying traffic to the corporate AD FS proxy or the Sharepoint web application. I can only surmise at the moment this is done to the fact that UAG assumes the web application is behind it and therefore a corresponding application must exist.

I’ve mapped the logon process out in Visio.

If I have the time, I’ll deep-dive the entire setup in a later post. If this would be of interest to anyone, please let me know.

Mylo

UPDATE 28/06: Microsoft have updated their documentation describing partner access using federated claims to Sharepoint 2010.
http://technet.microsoft.com/en-us/library/hh285675.aspx

The Access Onion

Access Management and Identity Federation on a plate.

Tag Archives: Claims-based Authentication

MFA Conditional Access Policies in AD FS 2012 R2

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

Step-up Authentication Scenarios with AD FS 2.0 Part II

Virtual Smart Cards (VSC) and AD FS 2.0

Claims-based access with AD FS 2.0 and PointSharp Identity Federation

SAML 2.0 IdP-Initiated Sign-On with RelayState in ADFS 2.0

Federated SSO Logon with AD FS 2.0 in an Extranet with UAG