(2019-05-25) Windows Hello For Business (WH4B) Bootstrapping

A few months ago I configured and implemented Windows Hello For Business (WH4B) using the “Hybrid AAD Joined Certificate Trust”. I chose this method over the “Hybrid AAD Joined Key Trust” because we did not have W2K16 DCs yet and we did have an ADFS deployment. This choice was really easy due to the lack of W2K16 DCs, otherwise we most likely would have chosen “Hybrid AAD Joined Key Trust” over “Hybrid AAD Joined Certificate Trust”.

–

Before going all crazy, we decided to start easy and implement it on a very limited scale scoped to specific Windows 10 computers and specific users. We created a small list of users (less than 10) and that list contained users logging on through username and password and users logging on through smartcard and pin.

–

To be able to implement this, we had to satisfy the following prerequisites:

• AAD subscription
• AD

• W2K8R2 DCs or higher (+DFL/FFL)
• W2K16 AD schema
• Configuration to support Hybrid Azure AD Domain Join
• Security group to scope computers and permission computer based GPO
• Security group to scope usersand permission user based GPO

• PKI infrastructure running on W2K12 or higher as trust anchor

• Certificate Template to issue Kerberos AuthN certificate for DCs through auto enrolment (and therefore correct permissioning!)
• Certificate Template to issue Registration Authority certificate for ADFS through auto enrolment (and therefore correct permissioning!)
• Certificate Template to issue WH4B AuthN certificate for clients by ADFS through auto enrolment  (and therefore correct permissioning!)
• DCs need certificate to be trusted by clients
• Users need authentication certificates distributed through ADFS registration authority (RA)
• Certificate Templates need to be configured with at least W2K12 or higher certificate authority support to be able to configure the correct provider and algorithm in the cryptography TAB

• AAD Connect, no DirSync and no AAD Sync

• Configuration to support Hybrid Azure AD Domain Join
• Device writeback

• To writeback the values in "msDS-KeyCredentialLink" on AD user account, RP/WP permissions are needed on that attribute. That can be done in a custom manner like assigning a custom group those permissions whereas that custom group may already have other permissions to read/write, or the AD connector account is added to the "KeyAdmins" group in AD

• ADFS

• Configuration to support Hybrid Azure AD Domain Join
• ADFS 2016 or higher as a registration authority
• Device authentication enabled at global level
• Configured as registration authority with the correct certificate templates for RA and WH4B

• Enrolment through username/password AND some form of MFA (AAD MFA Cloud, ADFS with AAD MFA Cloud/On-prem, ADFS with 3rd party MFA, etc)
• Windows 10 v1703 or higher
• Win10 Devices joined to AD and AAD, a.k.a. Hybrid Azure AD Domain Joined
  

–

While everything was in place, we were good to go!

–

Users logging on with username and password should see the following screen:

Figure 1: Windows Hello For Business Initial Provisioning Screen After Logging On With Username And Password

–

Users logging on with smartcard and pin should also see the same screen right after logging on, but they did not. Damn!

Let the troubleshooting begin!

After provisioning, looking at the PRTs through DSREGCMD /STATUS

Figure 2: SSO State: Azure AD PRT = YES And EnterprisePRT (ADFS PRT) = NO

–

Figure 3: NGC Prerequisite Check: No ADFS Refresh Token

–

OK, it is clear there is no ADFS PRT, which IS a requirement for WH4B, hence why it fails

–

On the client in the “Applications And Services Log\Microsoft\Windows\AAD\Operation” Event Log you may notice the following error or similar with some correlation ID. Save the correlation ID somewhere as you will need that later!

Figure 4: Client Side: Error In The “Applications And Services Log\Microsoft\Windows\AAD\Operation” Event Log

–

Http request status: 401. Method: POST Endpoint Uri: https://fs.iamtec.nl/adfs/oauth2/token/ Correlation ID: A9820E01-5D3A-4138-BCFF-72B454B67F1B

–

On the client in the “Applications And Services Log\Microsoft\Windows\AAD\Operation” Event Log you may notice the following error or similar with no correlation ID and a small hint of where things might be wrong. Nevertheless, still not clear enough!

Figure 5: Client Side: Error In The “Applications And Services Log\Microsoft\Windows\AAD\Operation” Event Log

–

OAuth response error: interaction_required
Error description: MSIS9699: GlobalAuthenticationPolicy on the Server doesn’t allow this OAuth JWT Bearer request. Please contact the administrator to update the GlobalAuthenticationPolicy.
CorrelationID:

–

On the client in the “Applications And Services Log\Microsoft\Windows\AAD\Operation” Event Log you may notice the following error or similar with some correlation ID. If you look carefully, you will see it is the same correlation ID and in figure 4. Save the correlation ID somewhere as you will need that later, if you have not done that already!

Figure 6: Client Side: Error In The “Applications And Services Log\Microsoft\Windows\AAD\Operation” Event Log

–

Enterprise STS Logon failure. Status: 0xC0000250 Correlation ID: A9820E01-5D3A-4138-BCFF-72B454B67F1B

–

In your face, no WH4B for you as authN against ADFS failed for some reason!

Figure 7: Client Side: Error In The “Applications And Services Log\Microsoft\Windows\User Device Registration\Admin” Event Log

–

Windows Hello for Business provisioning will not be launched.
Device is AAD joined ( AADJ or DJ++ ): Yes
User has logged on with AAD credentials: Yes
Windows Hello for Business policy is enabled: Yes
Windows Hello for Business post-logon provisioning is enabled: Yes
Local computer meets Windows hello for business hardware requirements: Yes
User is not connected to the machine via Remote Desktop: Yes
User certificate for on premise auth policy is enabled: Yes
Enterprise user logon certificate enrollment endpoint is ready: Yes
Enterprise user logon certificate template is : Yes
User has successfully authenticated to the enterprise STS: No
Certificate enrollment method: enrollment authority
See https://go.microsoft.com/fwlink/?linkid=832647 for more details.

–

On the ADFS server you will most likely find events similar to the ones below. Look at the event with the same correlation ID. If you have multiple ADFS servers, either check all ADFS servers for events with the same correlation ID, or check some central SIEM solution, or use PowerShell to query all ADFS servers, or configure your client to point to one specific ADFS server by temporarily configuring the HOSTS file.

Figure 8: ADFS Server Side: Errors In The “Applications And Services Log\AD FS\Admin” Event Log

–

And there is the reason! Certificate Authentication is NOT enabled on the intranet for primary authN! What the heck. Did not expect this one. I would expect that Windows Authentication on the intranet as primary authN would be enough for this to work, Apparently it explicitly needs the authN method to be enabled that is being used at logon.

Figure 9: ADFS Server Side: Error In The “Applications And Services Log\AD FS\Admin” Event Log

–

Encountered error during OAuth token request.

Additional Data

Exception details:
Microsoft.IdentityServer.Web.Protocols.OAuth.Exceptions.OAuthInteractionRequiredException: MSIS9462: Interaction is required by the token broker to resolve the issue. Enable CertificateAuthentication in the Global Policy.
   at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthJWTBearerRequestContext.ValidateAuthPolicy()
   at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthJWTBearerRequestContext.ValidateJWTBearer()
   at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthJWTBearerRequestContext.ValidateCore()

–

And there is the reason again! Certificate Authentication is NOT enabled on the intranet for primary authN!

Figure 10: ADFS Server Side: Error In The “Applications And Services Log\AD FS\Admin” Event Log

–

Encountered error during OAuth token request.

Additional Data

Exception details:
Microsoft.IdentityServer.Web.Protocols.OAuth.Exceptions.OAuthInteractionRequiredException: MSIS9462: Interaction is required by the token broker to resolve the issue. Enable CertificateAuthentication in the Global Policy.
   at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthJWTBearerRequestContext.ValidateAuthPolicy()
   at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthJWTBearerRequestContext.ValidateJWTBearer()
   at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthJWTBearerRequestContext.ValidateCore()
   at Microsoft.IdentityServer.Web.Protocols.ProtocolContext.Validate()
   at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthTokenProtocolHandler.ProcessJWTBearerRequest(OAuthJWTBearerRequestContext jwtBearerContext)

–

It will not get more explicit than this! If all error were like this!

In this case when logging on with smartcard and pin and to be able to start WH4B provisioning, Certificate Based Authentication needs to be enabled at the INTRANET level in ADFS.

For that you can use the following PowerShell commands:

Get-AdfsGlobalAuthenticationPolicy
$currentListOfProvidersForPrimaryAuthNForIntranet = (Get-AdfsGlobalAuthenticationPolicy).PrimaryIntranetAuthenticationProvider
If ($currentListOfProvidersForPrimaryAuthNForIntranet -notcontains "CertificateAuthentication") {
    $newListOfProvidersForPrimaryAuthNForIntranet = $currentListOfProvidersForPrimaryAuthNForIntranet + "CertificateAuthentication"
    Set-AdfsGlobalAuthenticationPolicy -PrimaryIntranetAuthenticationProvider $newListOfProvidersForPrimaryAuthNForIntranet
}
Get-AdfsGlobalAuthenticationPolicy

Figure 11: Configuring The ADFS Global Authentication Policy – Providers For Primary Authentication For The Intranet

–

Now logging off and logging back on again, you should see the following screen:

Figure 12: Windows Hello For Business Initial Provisioning Screen After Logging On With Smartcard And PIN

–

PS: Look for differences when a user logs on with username and password!

After provisioning, looking at the PRTs through DSREGCMD /STATUS

Figure 13: SSO State: Azure AD PRT = YES And EnterprisePRT (ADFS PRT) = YES

–

Figure 14: NGC Prerequisite Check: No ADFS Refresh Token

–

At PRT level, everything is looking good now!

–

Enjoy and have fun!,

Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-