Category Archives: Multi-Factor Authentication

Windows 10 Passwordless – Azure AD Join, Microsoft Intune and Windows Hello for Business

October 12, 2018Azure AD Join, MFA, Microsoft Intune, Multi-Factor Authentication, Password-less, PKI, Route443, Windows 10, Windows Hello for BusinessAADJ, Azure AD Join, Biometric, Intune, Microsoft Intune, Passwordless, Single Sign-On, SSO, WHFB, Windows 10, Windows Hello for Businessmylo

We’re back and it’s been a W H I L E…. let’s jump right back in with some Single Sign-On (SSO) passwordless fun with Windows 10, Azure AD Join, Microsoft Intune and Windows Hello for Business. This article is also uploaded to the Route443 blog here.

In this post we describe one route to incorporating passwordless technology that leverages customer investment in the Microsoft cloud, specifically Enterprise Mobility + Security. We assume the customer is in possession of a hybrid infrastructure, with on-premise pieces (Active Directory Domain Services, Certificate Services etc.). Most customer configurations we come across are those where a Hybrid Azure AD-join configuration has been opted for, with the on-premise identity being the dominant one.

We’ll use Windows Autopilot to kick start a hypothetical migration from hybrid to cloud-only, in doing so using Microsoft Intune as an alternate for SCCM and on-premise GPO, rolling out Windows Hello for Business as part of the process, together with Wireless 802.1X and AlwaysOn VPN profiles. Finally, a single sign-on (SSO) path back to on-premise resources is a must.

Here we take a Windows 10 version 1803 client and join it to the tenant Azure Active Directory. As way of demonstrating the platform capability, we:

Provision the machine using Windows Autopilot and onboard the user using multi-factor authentication (sans password)
Use Windows Hello for Business for Multi-Factor Authentication (MFA) via biometric gestures and PIN for fallback
Use TPM-backed certificate authentication to provide secure access to the end-user both in deployment and access to:
- VPN using Win10 AlwaysOn VPN
- Secure wireless using 802.1X
Use Credential Guard to isolate and protect secrets (e.g., NTLM hashes / Kerberos ticket-granting tickets)
Leverage Single Sign-On (SSO) access to on-premise resources:
- File servers
- Print servers
- Application servers

Machines are built using Windows Autopilot and joined to the Azure Active Directory (AADJ). Since these are AADJ devices, they will not be part of the on-premise Active Directory. User accounts exist in both the cloud and on-premise AD.

Moving on, let’s peek at the configuration

In this use case, we’re going to deploy a Windows 10 machine using Windows Autopilot. In a conventional Windows deployment, Out of the Box exprience (OoBE) requires the user to identify whether the device is personally or organizationally owned, the selected option then triggering a different set of configuration workflow. For an organizational join, the client needs to have visibility to the Internet to process the registration of the device and the user.

Windows AutoPilot simplifies this decision-making process by directly tying the procured hardware to the organization tenant, importing the hardware ID of the device into the Microsoft Store for Business. The Out of Box Experience (OoBE) lands the user on the tenant branded logon screen.

When prompted for credentials, we enter our tenant details (in this example Route443). In a standard Windows configuration, we’d be required to enter a password after entering the username. Since our goal is passwordless, we look to stronger mechanisms for authentication. During OoBE deployment Windows Hello for Business is not available, so an alternative credential is required. FIDO 2.0 would be ideal but is not yet General Availability (GA) in a Windows 10 release. Vendors such as Yubikey have incorporated FIDO 2.0 into their product range and are ready to support the up-coming release of Windows 10 that includes support for FIDO 2.0.

With Multi-Factor Authentication (MFA) enabled in the tenant and phone sign-in configured for the user, the Microsoft Authenticator app can be used to do passwordless sign-in. Like Windows Hello for Business, it uses key-based authentication for the user credential bound to a device (Biometric or PIN). With phone sign-in enabled for the AAD account, the enrolling user will see a number onscreen.

Within the mobile authenticator app, the user must match the number that appears on-screen with that surfaced via the mobile app.

Note that the App itself can be protected either by Touch ID or PIN. Once successfully authenticated, the machine will continue with configuration. Consistent with the organizational Intune policies in this example, the user will be prompted to register a PIN for Windows Hello for Business. This is also used for fallback in case biometric options (facial recognition/fingerprint) are not available.

Click on PIN requirements to see what your organizational policy has decreed.

Once the PIN is set, the user is able to login with their Hello PIN. Should the device have other Hello capabilities, such as facial recognition or fingerprint reader, then these can also be engaged.

In the above example, the device is configured for facial recognition. Changing biometric settings can also be modified under Windows Settings|Accounts|Sign-In Options.

Devices are enrolled for Intune MDM and Azure AD joined. This can be checked via Windows Settings|Accounts|Access Work or School.

With device configuration profiles defined in Microsoft Intune and assigned to devices, the AADJ client will receive the appropriate configuration.

Specific to this configuration, the following profiles are relevant:

Certificate configuration profiles
- Root CA
- Issuing CA
SCEP profile for Windows Hello
SCEP profile for WLAN/VPN
1X WLAN profile
AlwaysOn VPN profile

Certificate Authority Configuration Profiles

If certificates are pushed out via SCEP, then an Enterprise PKI and NDES server, acting as a Registration Authority, is required, together with an Intune connector installed on the server. As announced at Ignite, Intune will support 3rd party CAs in the near future.

A configuration profile is required for each tier of the PKI. In this example, a two-tier PKI exists, with a profile for each CA pushed to the client.

SCEP profile for Secure Wireless / VPN

A SCEP profile is rolled out with a Client Authentication EKU to satisfy the 802.1X and AlwaysOn certificate requirements. This certificate is then used by these services to authenticate the client to the back-end Network Policy Server (NPS) running behind the respective wireless and VPN services.

SCEP Profile for Windows Hello

While Windows Hello for Business prefers hardware-backed credentials, not all computers are in possession of a Trusted Platform Module (TPM). Intune provides options for falling back to a software-based credential, should the need arise.

In Certificate Trust scenarios using Windows Hello for Business, a SCEP profile is required with a Smart Card EKU. This is to satisfy access conditions for Single Sign-On (SSO) for Windows Hello for Business against the on-premise domain.

Secure Wireless LAN profile

The Secure Wireless LAN profile contains the configuration for the on-premise wireless network, EAP type settings, authentication methods etc. Use of certificates ensures that access to the on-premise wireless is seamless when in-range. For a more immersive experience, machine certificates are preferred for use, subject to their availability in Intune.

AlwaysOn VPN profile

The AlwaysOn VPN profile contains the configuration for the on-premise AlwaysOn VPN server (Microsoft replacement for DirectAccess). The more detailed settings are minted from a EAP.XML file generated on a test machine manually and then imported into the Intune blade in Azure Resource Manager (ARM) console.

Dependent on whether the user is on-site at the business location or working from home, connectivity to the network, either via secure wireless (802.1X) or IPsec VPN (IKEv2) gives access to the corporate resources, courtesy of the provisioned certificates. This is carried out transparently. Since these are user certificates, connectivity is established after interactive logon.

This is down to a limitation in the Microsoft Intune SCEP configuration profile that assumes all assigned certificates are to be user-oriented, rather than machine. Thankfully, based on details from Microsoft at Ignite, an upcoming Microsoft Intune release will provide additional support for machine certificates. Once these are available, we’ll follow up with an additional post.

On-Premise Access and Single Sign-On (SSO)

So how are on-premise Active Directory resources accessed in a native Azure AD Join (AADJ) scenario? It may come as a surprise, but AADJ clients can also communicate with on-premise Active Directory resources. This is down to functionality built into recent versions of the Windows 10 client and Azure AD Connect, providing additional details during AAD Sync that can be subsequently used by the Windows client. It’s worth pointing out that this functionality is not specific Windows Hello for Business, but for AADJ clients as a whole that wish to communicate with on-premise resources.

It is assumed there is line-of-sight to a on-premise domain controller from the Windows 10 client. Line-of-sight can mean on-premise wired, wireless (802.1X) or Always On VPN.. For our passwordless scenario, the authenticated user has the aforementioned “Hello” certificate deployed via SCEP.

If on-premise domain controllers are Windows Server 2016 or above, then the certificate trust model for Windows Hello for Business, described here, can be dropped in favour of the key trust model. This simplifies deployment by not requiring SCEP/NDES for the Smart Card.

Using DSREGCMD from the command-line we can derive some useful information concerning the client.

Hello

This is an Azure AD joined device, with TPM-backed private keys for certificates created during the enrollment being stored in TPM. The user also has been enrolled for Windows Hello for Business (NgcSet: YES).

In this article, we illustrated how it is possible to optimise investment in Microsoft cloud services for deploying workspaces across any network, using modern secure authentication, whilst maintaing the ability to seamlessly access on-premise applications. This managed workspace achieves feature parity comparable to that of a classically deployed workspace. By utilising modern secure authentication, together with Azure AD Domain Join, this provides opportunities for customers to take advantage of other identity-as-a-service pieces already available in the Microsoft cloud.

For more information on these interesting topics, please contact us at Route443.

DirectAccess with PointSharp ID

July 27, 20162FA, DirectAccess, Multi-Factor AuthenticationDirectAccess MFA 2FA PointSharpmylo

Just a quick post to let you know there’s a new article on the Route443 blog, on the subject of using strong authentication with DirectAccess. Here is the link. In addition, there’s a webinar on this subject for anyone interested, hosted by PointSharp. You can subscribe to this event here.

Enjoy!

Back to the Home Realm Discovery in 2012 R2

May 20, 20162FA, AD FS R2, Customization, Home Realm Discovery, MFA, Multi-Factor Authentication, PointSharp, Strong Authentication, Windows Server 2012 R2mylo

Hello all. You may recall from older posts on this blog (2012) that we’ve played around in the past with Home Realm Discovery (HRD) in AD FS.

First with IWA and forms logon here and then a little bit more for good measure. Since then it’s been a little quiet on the HRD fence and not a subject delved into much since. That is, until an issue a colleague and I ran into an issue recently… confronted with the following AD FS R2 access conundrum:

“ How can we route (automatically) external logon requests to a third-party claims provider, continue to route internal logon requests to the native AD claims provider (i.e. maintain transparent SSO), eliminating any Home Realm Discovery (HRD) for our users to have to walk through and select?”

Or… to put it more simply. How can one automatically route external route requests to claims provider A, continue to route internal requests to (AD) claims provider B, whilst altogether avoiding Home Realm Discovery (HRD) for all users?

We’ll discuss the exact use case in a moment. This is a RP-initiated work-flow. No IDP-initiated flow or smart links are allowed.

First, a bit of background. Let’s head back to the first look posts on AD FS 2012 R2 in 2013/2014. In there I wrote:

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

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

With the move to kernel-mode in R2, customization previously possible under IIS in AD FS 2.0 was no longer applicable. To redress this issue and to provide greater flexibility, the above customization options were provided. Suffix routing enables AD FS 2012 R2 to select an appropriate claims provider based on the domain suffix credentials provided by that user. Broadly speaking, this is just how O365/Azure AD works in attempting to discover the Federated home realm v Microsoft realm of the connecting user. Similarly, for on-premise AD FS, suffix routing enables us to refine our logon decision-making based on the home realm of the connecting user. Here’s an example:

Users from the Cranky Nuts organization, connecting via AD FS, use a @crankynuts.nl domain suffix. Accordingly, we need to send authentication requests to the Cranky Nuts Identity Provider.
Users from the Wobbly Wheels organization, connecting via AD FS, use a @wobblywheels.be domain suffix. Accordingly, we need to send authentication requests to the Wobbly Wheels Identity Provider.

In AD FS 2012 R2 we can configure this within Powershell:

Set-AdfsClaimsProviderTrust –TargetName “Cranky Nuts IdP” –OrganizationalAccountSuffix @(“crankynuts.nl”)
Set-AdfsClaimsProviderTrust –TargetName “Wobbly Wheels IdP” –OrganizationalAccountSuffix @(“wobblywheels.be”)

Wonderful! Using this approach can be a little hit and miss though. It’s making certain assumptions about the level at which we’re prepared to divert authentication on, i.e. the domain level. That’s not always the case.

We could, alternatively, opt for the other method: targeting claims provider selection at the Relying Party Trust level. Again, this is useful functionality. Here’s an example.

Set-AdfsRelyingPartyTrust -TargetName “BodgeIT Inventory ” -ClaimsProviderName @(“crankynuts.nl”)

This makes the “BodgeIT Inventory” Relying Party/Web Application, available to users of the Cranky Nuts organization, bypassing the local AD claims provider. Should we need to extend access to additional claims providers, such as our local Active Directory, then we can add that issuer to the mix. The downside of this option, is that we’re forced into making a home-realm discovery selection during logon.

The Suffix and RP-specific claims provider options, therefore, do have some limitations. Indeed, for the scenario that we were faced with, neither option fit. In our situation, two claims providers existed for a single organization, with each CP containing the same set of users. The use case? Two-factor authentication. The upstream claims provider (CP) provides two-factor authentication (2FA) for users connecting from the outside , while the incumbent local AD claims provider covers local Windows logon.

Of course, two claims providers means Home Realm Discovery (HRD) and HRD can be confusing. We can remedy this for internal users, ensuring they don’t get the HRD prompt by defaulting to the use of the local AD claims provider via Powershell:

Set-ADFSProperties –IntranetUseLocalClaimsProvider $True

This doesn’t solve the problem for access from the outside. Moreover, we expressly wish to send all connecting users to our 2FA claims provider, rather than to the in-build AD claims provider…. We could use auxiliary authentication provided by the MFA Adapter in AD FS 2012 R2, thereby eliminating the use of the upstream claims provider. However, that might not be feasible as:

Leading with the AD password as the primary authentication credential may not be allowed.
The vendor has an MFA adapter for AD FS 2012 R2.

Even where the latter is available, the (security) policy prerogative might be that use of 1) is not allowed, thereby overriding (2).

<PLUG>To demonstrate issue, cue favorite authentication platform PointSharp (</PLUG>

PointSharp possess both a Security Token Service (STS) that can stip atop AD FS as a 2FA claims provider role and also have an MFA adapter for AD FS 2012 R2 / 2016. Since use of the MFA adapter has been prohibited by the customer according to the rules above (not wanting to lead with AD password as a primary authentication credential), the STS as a Claims Provider was selected instead.

You’ll recall we turned off HRD for internal users by setting the IntranetUseLocalClaimsProvider setting to TRUE. With the PointSharp STS configured as a claims provider, external users will get continue to get the HRD screen as AD FS cannot determine where the user lives without the appropriate “hint”. In AD FS 2.0 it was possible to workaround this by customizing the AD FS 2.0 proxy configuration, modifying the Page_Init section of the homerealmdiscovery.aspx.cs file. We could then remove Active Directory as a claims provider (0)

PassiveIdentityProvidersDropDownList.Items.RemoveAt(0);

Once that was done, default realm selection would fall to our other claims provider (STS)

SelectHomeRealm ( PassiveIdentityProvidersDropDownList.SelectedItem.Value );

As you are no doubt aware, IIS has been supplanted in AD FS 2012 R2 with everything running in kernel-mode. Thankfully, all is not lost though. Some of the functionality previously possible under IIS has moved to Javascript and customization of the onload.js script is covered in a couple of scenarios here..

Variables previously living in .NET code-behind are visible in the View Source of the web page of the HRD screens. Options for both claims providers are visible.

….HRD.selection(‘http://adfs.mydomain.com/adfs/services/trust’);” onclick=”HRD.selection(‘http://adfs.mydomain.com/adfs/services/trust’); …….
….HRD.selection(‘https://sts.mydomain.com/login/’);” onclick=”HRD.selection(‘https://sts.mydomain.com/login/’); …….

HRD.selection is the main feature of interest. There’s an action on clicking the realm manually that specifies the HRD we require. We can automate this by moving the selection to the onload.js script, thereby automating selection of the PointSharp Claims Provider. First, we need to customize our AD FS setup.

We create a new theme called PointSharp based on the default AD FS theme

New-AdfsWebTheme –Name PointSharp –SourceName default

Export the default theme to allow our customization

Export-AdfsWebTheme –Name default –DirectoryPath c:\scripts

Copy the default onload.js to the C:\Scripts folder and edit it. At the end of the script, we simply add the reference to the PointSharp claims provider using the following syntax (replace with your own CP) :

HRD.selection(‘https://sts.mydomain.com/login/’);

We then import the new PointSharp theme including the modified onload.js.

Set-AdfsWebTheme -TargetName PointSharp -AdditionalFileResource @{Uri=’/adfs/portal/script/onload.js’;path=”c:\scripts\onload.js”}

Activate the new theme.

Set-AdfsWebConfig -ActiveThemeName PointSharp

External users will be now routed to the PointSharp claims provider for login, whilst AD logon for internal users is still preserved. Please note that this is a GLOBAL change affecting all users of the AD FS farm and test extensively as it might not be your cup of tea…

Office 365 and MFA in AD FS 2016 (TP4)

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

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

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

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

If we compare that with a normal RP.

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

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

Update-MsolFederatedDomain -SupportMultipleDomain -DomainName mydomain.com

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

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

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

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

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

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

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

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

As ever, play and test at your own peril Smile

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.

MFA with Client Certificates in ADFS 2012 R2

May 27, 2014AD FS R2, Claims-based Authentication, MFA, Multi-Factor Authentication, Relying Party, Strong Authentication, Web Application Proxy, Windows Server 2012 R2AD FS R2, Client Certificates, MFA, Multi-Factor Authentication, Web Application Proxy, Windows Server 2012 R2, Workplace Join, X509mylo

There have been questions on this subject posted recently to comments and also on the TechNet forums, so I just wanted to quickly write up something about use of client certificates in the MFA (secondary) slot in AD FS 2012 R2. You may recall from earlier AD FS R2 posts, that we used virtual smart card and smart card as examples. Let’s broaden that to include “soft” client certificates as an MFA/secondary provider. This functionality is provided “out-of-the box” in AD FS 2012 R2. An Active Directory Certificate Services (AD CS) infrastructure is required to serve up certificates for enabling users for PKI.

In this post, I’ll be using an Active Directory Certificate Services (AD CS) role from Windows Server 2012 R2 as the Certification Authority (CA). I won’t be explaining the CA setup, beyond the templates used, as there’s been plenty of ink expended on this topic already on the Internet. A Windows 2003/2008/2012 CA setup will suffice for the activities concerned here.

Testing was done with client certificates from a Windows 8.1 clients using:

a non domain-joined machine, via Certificate Enrollment (Policy) Web Services and Microsoft Management Console (MMC)
a domain-joined machines, via an auto-enrollment policy User-Context GPO.

In AD Certificate Services (AD CS) a duplicate of the default User certificate template was made (called User V2). Under the Application Policy, the policy is limited to Client Authentication.

For domain-joined clients, we can enable auto-enrollment via the security tab of the template. Here we see a group called GU-SEC-ADCS-Managed, which is given the necessary read, enroll and autoenroll permissions and we can add users to that security group.

To enable auto-enrollment for domain-joined clients we need to activate a policy to accomplish this. Against best practices (boo), but for expediency (mine.. yay!), I enable the policy in the Default Domain Policy GPO. The actual settings can be find under Windows Settings|Security Settings|Public Key Policies. Select the Certificate Services Client – Auto Enrollment object and enable the Configuration model section as seen below.

For the non-domain joined client, read and enroll permissions are given to a group I’ve called GU-SEC-ADCS-Workgroup. The test user, who will be a member of that group, can request the UserV2 certificate template via the Certificates|User MMC plug-in using AD CS Certificate Enrollment Web Services. Again, I won’t be describing how to setup enrollment web services. If you need help, just post in the comments section.

With Certificate Services, we need to make available the template available to both sets of clients, by enabling the template in the Certification Authority MMC plugin – Certificate Templates|New|Certificate Template to Issue.

In a correctly configured setup, domain-joined clients will obtain a certificate on the next GPO refresh cycle for the user (e.g. logon).

As mentioned previously, I’m joining non-domain joined clients via enrollment web services using the MMC snap-in in Windows 8. In the Certificates|User context of the MMC snap-in, we request a new certificate. In this particular test setup, there are three certificate templates visible for enrollment by the client from the CA:

User V2 is the template we just created for use for “soft” client certificates.The certificate services enrollment point in this example is configured for Username/Password authentication. Logon is done with a test AD user account training@azuresprout.net, who is a member of the GU-SEC-ADCS-Workgroup and authorized with the enroll permission.

Once that’s done, a client certificate is installed in the user context.

On the AD FS side of things, let’s assume we now need to apply MFA for users (with client certificates) coming from the Internet. Before we jump into the actual AD FS settings, it’s worth mentioning that any firewalls in front of the Web Application Proxy (WAP) will need to allow port 49443/TCP inbound, as this is the port the AD FS Smartcard Authentication Service listens on.

We see evidence of this requirement in the Windows Firewall snap-in. AD FS creates a firewall rule during the installation allowing 49443/TCP inbound.

In AD FS Global Authentication Policy for MFA, we enable certificate authentication:

Note that at this point, I’m not enforcing the use of MFA globally, rather enabling it for use at a lower level on a relying party rule, for more incremental control. Whether to go for global or granular policies really boils down to a question of fit and the use cases may need to support. .

On a test Windows Identity Foundation (WIF) relying party, MFA is enforced for externally connecting users.

Logging on to the relying party, we hit the primary authentication handler (AD FS forms), enter our username/password.

Connecting from the Internet, with MFA enabled, the secondary (MFA) authentication handler kicks in and we’re presented with a login popup.

In the above graphic, we have an option to login with a virtual smart card (top) and an X509 client certificate (bottom). Click on the certificate and AD FS will authenticate the user using secondary authentication (MFA).

The enrolled certificate is stored by AD CS in the userCertificate attribute of the user object within AD. This attribute contains the DER-encoded X509v3 certificates issued to the user. We can lookup the necessary certificate reference, for example, in the Attribute Editor of AD Users & Computers (ADUC).

This is a multi-valued attribute.

One thing that can be useful, should you be working with multiple certificates for a given user, is being able to cut and paste the hex encoded value into Notepad, save it, then check to see what the certificate value corresponds to using CERTUTIL.

certutil –decodehex mylo.hex mylo.cer

We can then open the .cer file to see what the certificate is.

Returning to the test claims applications (having logged in successfully0, we pass all claims processed via an issuance transform rule of c:[] => issue(claim = c);
We can see the relevant authentication method references processed during primary and secondary logon.

As I mentioned in an earlier post, the nice thing here is that you can use the Enhanced Key Usage (EKU) claim emitted for both client certificates and smart cards / virtual smartcards to moderate access to resources as you see fit.

Looking at a user authenticating with a client certificate, the following EKU is emitted as a claim.

Smart cards also emit the smart card EKU

Access can also be further graded by using custom OIDs to differentiate between levels of access based on the type of MFA being used and the EKU value.

Use of certificates in the MFA slot in R2 (I suspect) are really geared for use in a true two-factor (2FA) authentication capability, i.e. smart cards. While the use of a client certificate does offer value in offering richer access possibilities, this is not 2FA, in that it does not satisfy the mantra of “something I have and something I know”. Instead, this is more akin to 1.5FA.

To finish up, Microsoft recently added support in Windows 7 for domain-joined clients via a hotfix. I’ll attempt to throw out a quick post on this, but in the meantime, I’ll be following up by looking at conditional access policies for MFA.

As always, thanks for reading and if you have any questions, please post a comment and I’ll do my best to answer quickly.

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!

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.

The Access Onion

Access Management and Identity Federation on a plate.

Category Archives: Multi-Factor Authentication

Windows 10 Passwordless – Azure AD Join, Microsoft Intune and Windows Hello for Business

DirectAccess with PointSharp ID

Back to the Home Realm Discovery in 2012 R2

Office 365 and MFA in AD FS 2016 (TP4)

MFA Conditional Access Policies in AD FS 2012 R2

MFA with Client Certificates in ADFS 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

Virtual Smart Cards (VSC) and AD FS 2.0