Encountered error during oauth token request

Hi, 

We have encountered this error and cannot find any information on how to overcome this. 

Error Message:

Encountered error during OAuth token request.

Additional Data

Exception details:
Microsoft.IdentityServer.Web.Protocols.OAuth.Exceptions.OAuthAccessTokenInvalidAuthorizationCodeException: MSIS9252: The authorization code received is invalid. No artifact found for the specified authorization
code: ‘(code removed)’. The cause may be that artifact has timed out, or the authorization code was replayed, or the authorization code is invalid.

   at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthTokenProtocolHandler.RedeemAccessToken(OAuthAccessTokenRequestContext tokenContext)

Settings: 

RedirectUri : {beta.housingmaintenancesolutions.org/backend/lmh/ssologin/OauthLogin/} (DEV
SERVER)
Name        : HmsWebsiteBetaClient

Description :

ClientId    : hms-beta-website

BuiltIn     : False

Enabled     : True

ClientType  : Public

RedirectUri : {lmh00432/octtheme/backend/lmh/ssologin/OauthLogin/} (LOCALHOST)
Name        : HmsWebsiteDevClient

Description :

ClientId    : hms-dev-website

BuiltIn     : False

Enabled     : True

ClientType  : Public

This has been tested and works perfectly on Localhost, but not on the development server. 

Thanks for your assistance. 

Encountered error during oauth token request

Вопрос

We have encountered this error and cannot find any information on how to overcome this.

Error Message:

Encountered error during OAuth token request.

Exception details:
Microsoft.IdentityServer.Web.Protocols.OAuth.Exceptions.OAuthAccessTokenInvalidAuthorizationCodeException: MSIS9252: The authorization code received is invalid. No artifact found for the specified authorization code: ‘(code removed)’. The cause may be that artifact has timed out, or the authorization code was replayed, or the authorization code is invalid.

at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthTokenProtocolHandler.RedeemAccessToken(OAuthAccessTokenRequestContext tokenContext)

Settings:

RedirectUri : < beta.housingmaintenancesolutions.org/backend/lmh/ssologin/OauthLogin/ >(DEV SERVER)
Name : HmsWebsiteBetaClient
Description :
ClientId : hms-beta-website
BuiltIn : False
Enabled : True
ClientType : Public

RedirectUri : < lmh00432/octtheme/backend/lmh/ssologin/OauthLogin/ >(LOCALHOST)
Name : HmsWebsiteDevClient
Description :
ClientId : hms-dev-website
BuiltIn : False
Enabled : True
ClientType : Public

This has been tested and works perfectly on Localhost, but not on the development server.

Thanks for your assistance.

Все ответы

What version of ADFS are you using?

What OAuth flow? — it looks like authorisation code grant.

In which case you should have a parameter like «code = xxx».

If you do, then the error is normally as per the message i.e. time out / you have already used this code / this code was not issued by ADFS etc.

Thanks for your reply.

We are currently using ADFS version 3.0;

We are successfully getting an authorization code after logging in to ADFS but for some reason it doesn’t seem to recognise this code once it is passed back to the application.

As I’ve mentioned in my initial message; it is working perfectly on locahost, which uses these settings;

RedirectUri : (LOCALHOST)
Name : HmsWebsiteDevClient
Description :
ClientId : hms-dev-website
BuiltIn : False
Enabled : True
ClientType : Public

But the very same code and application doesn’t work on the development server;

RedirectUri : (DEV SERVER)
Name : HmsWebsiteBetaClient
Description :
ClientId : hms-beta-website
BuiltIn : False
Enabled : True
ClientType : Public

As you can see from the above, the only difference is the ClientId and the Redirect URI. So what do you think could be the issue?

Is there anything in the ADFS event log?

I’m sure you’ve done this but just checking that when you say «very same code and application», the web.config is different to reflect the different ClientID etc.?

If you use Fiddler or similar, is there anything different in the two requests / responses? (other than expected differences).

Does clearing cookies help?

If you are authenticating with two different users, are there any differences between them?

In the event log there’s an error complaining about the authorization code received being invalid:

Microsoft.IdentityServer.Web.Protocols.OAuth.Exceptions.OAuthAccessTokenInvalidAuthorizationCodeException: MSIS9252: The authorization code received is invalid. No artifact found for the specified authorization code: (code removed)’. The cause may be that artifact has timed out, or the authorization code was replayed, or the authorization code is invalid.

at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthTokenProtocolHandler.RedeemAccessToken(OAuthAccessTokenRequestContext tokenContext)

An earlier post shows our configuration of the two different client IDs and their redirect URIs that have been set up in ADFS, these correspond to the two client IDs and URIs provided by the two different instances of the application when calling the /oauth2/token endpoint.

The development environment uses the hms-dev-website client ID and works fine. The test environment uses the hms-beta-website client ID, that I’ve confirmed with a debugger and watched it call the /oauth2/authorise endpoint with the correct client id as a query parameters (“client” and “resource”).

The authorisation codes received are different each time, and I’ve confirmed it’s only ever sending the code it gets back from ADFS immediately after receiving it.

The only thing I can think that might be confusing the situation is that while there are two client-ids set up, I’ve only set up one Relying Party Trust in ADFS but with both of the client IDs as “Relying party identifiers”.

Another thing to note is that we have 2 ADFS servers fronted by a web application proxy that load-balances between them.

We have tested different authenticated users but we get the same result.

Источник

Encountered error during oauth token request

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Asked by:

Question

We have encountered this error and cannot find any information on how to overcome this.

Error Message:

Encountered error during OAuth token request.

Exception details:
Microsoft.IdentityServer.Web.Protocols.OAuth.Exceptions.OAuthAccessTokenInvalidAuthorizationCodeException: MSIS9252: The authorization code received is invalid. No artifact found for the specified authorization code: ‘(code removed)’. The cause may be that artifact has timed out, or the authorization code was replayed, or the authorization code is invalid.

at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthTokenProtocolHandler.RedeemAccessToken(OAuthAccessTokenRequestContext tokenContext)

Settings:

RedirectUri : < beta.housingmaintenancesolutions.org/backend/lmh/ssologin/OauthLogin/ >(DEV SERVER)
Name : HmsWebsiteBetaClient
Description :
ClientId : hms-beta-website
BuiltIn : False
Enabled : True
ClientType : Public

RedirectUri : < lmh00432/octtheme/backend/lmh/ssologin/OauthLogin/ >(LOCALHOST)
Name : HmsWebsiteDevClient
Description :
ClientId : hms-dev-website
BuiltIn : False
Enabled : True
ClientType : Public

This has been tested and works perfectly on Localhost, but not on the development server.

Thanks for your assistance.

What version of ADFS are you using?

What OAuth flow? — it looks like authorisation code grant.

In which case you should have a parameter like «code = xxx».

If you do, then the error is normally as per the message i.e. time out / you have already used this code / this code was not issued by ADFS etc.

Thanks for your reply.

We are currently using ADFS version 3.0;

We are successfully getting an authorization code after logging in to ADFS but for some reason it doesn’t seem to recognise this code once it is passed back to the application.

As I’ve mentioned in my initial message; it is working perfectly on locahost, which uses these settings;

RedirectUri : (LOCALHOST)
Name : HmsWebsiteDevClient
Description :
ClientId : hms-dev-website
BuiltIn : False
Enabled : True
ClientType : Public

But the very same code and application doesn’t work on the development server;

RedirectUri : (DEV SERVER)
Name : HmsWebsiteBetaClient
Description :
ClientId : hms-beta-website
BuiltIn : False
Enabled : True
ClientType : Public

As you can see from the above, the only difference is the ClientId and the Redirect URI. So what do you think could be the issue?

Is there anything in the ADFS event log?

I’m sure you’ve done this but just checking that when you say «very same code and application», the web.config is different to reflect the different ClientID etc.?

If you use Fiddler or similar, is there anything different in the two requests / responses? (other than expected differences).

Does clearing cookies help?

If you are authenticating with two different users, are there any differences between them?

In the event log there’s an error complaining about the authorization code received being invalid:

Microsoft.IdentityServer.Web.Protocols.OAuth.Exceptions.OAuthAccessTokenInvalidAuthorizationCodeException: MSIS9252: The authorization code received is invalid. No artifact found for the specified authorization code: (code removed)’. The cause may be that artifact has timed out, or the authorization code was replayed, or the authorization code is invalid.

at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthTokenProtocolHandler.RedeemAccessToken(OAuthAccessTokenRequestContext tokenContext)

An earlier post shows our configuration of the two different client IDs and their redirect URIs that have been set up in ADFS, these correspond to the two client IDs and URIs provided by the two different instances of the application when calling the /oauth2/token endpoint.

The development environment uses the hms-dev-website client ID and works fine. The test environment uses the hms-beta-website client ID, that I’ve confirmed with a debugger and watched it call the /oauth2/authorise endpoint with the correct client id as a query parameters (“client” and “resource”).

The authorisation codes received are different each time, and I’ve confirmed it’s only ever sending the code it gets back from ADFS immediately after receiving it.

The only thing I can think that might be confusing the situation is that while there are two client-ids set up, I’ve only set up one Relying Party Trust in ADFS but with both of the client IDs as “Relying party identifiers”.

Another thing to note is that we have 2 ADFS servers fronted by a web application proxy that load-balances between them.

We have tested different authenticated users but we get the same result.

Источник

Encountered error during oauth token request

Вопрос

We have encountered this error and cannot find any information on how to overcome this.

Error Message:

Encountered error during OAuth token request.

Exception details:
Microsoft.IdentityServer.Web.Protocols.OAuth.Exceptions.OAuthAccessTokenInvalidAuthorizationCodeException: MSIS9252: The authorization code received is invalid. No artifact found for the specified authorization code: ‘(code removed)’. The cause may be that artifact has timed out, or the authorization code was replayed, or the authorization code is invalid.

at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthTokenProtocolHandler.RedeemAccessToken(OAuthAccessTokenRequestContext tokenContext)

Settings:

RedirectUri : < beta.housingmaintenancesolutions.org/backend/lmh/ssologin/OauthLogin/ >(DEV SERVER)
Name : HmsWebsiteBetaClient
Description :
ClientId : hms-beta-website
BuiltIn : False
Enabled : True
ClientType : Public

RedirectUri : < lmh00432/octtheme/backend/lmh/ssologin/OauthLogin/ >(LOCALHOST)
Name : HmsWebsiteDevClient
Description :
ClientId : hms-dev-website
BuiltIn : False
Enabled : True
ClientType : Public

This has been tested and works perfectly on Localhost, but not on the development server.

Thanks for your assistance.

Все ответы

What version of ADFS are you using?

What OAuth flow? — it looks like authorisation code grant.

In which case you should have a parameter like «code = xxx».

If you do, then the error is normally as per the message i.e. time out / you have already used this code / this code was not issued by ADFS etc.

Thanks for your reply.

We are currently using ADFS version 3.0;

We are successfully getting an authorization code after logging in to ADFS but for some reason it doesn’t seem to recognise this code once it is passed back to the application.

As I’ve mentioned in my initial message; it is working perfectly on locahost, which uses these settings;

RedirectUri : (LOCALHOST)
Name : HmsWebsiteDevClient
Description :
ClientId : hms-dev-website
BuiltIn : False
Enabled : True
ClientType : Public

But the very same code and application doesn’t work on the development server;

RedirectUri : (DEV SERVER)
Name : HmsWebsiteBetaClient
Description :
ClientId : hms-beta-website
BuiltIn : False
Enabled : True
ClientType : Public

As you can see from the above, the only difference is the ClientId and the Redirect URI. So what do you think could be the issue?

Is there anything in the ADFS event log?

I’m sure you’ve done this but just checking that when you say «very same code and application», the web.config is different to reflect the different ClientID etc.?

If you use Fiddler or similar, is there anything different in the two requests / responses? (other than expected differences).

Does clearing cookies help?

If you are authenticating with two different users, are there any differences between them?

In the event log there’s an error complaining about the authorization code received being invalid:

Microsoft.IdentityServer.Web.Protocols.OAuth.Exceptions.OAuthAccessTokenInvalidAuthorizationCodeException: MSIS9252: The authorization code received is invalid. No artifact found for the specified authorization code: (code removed)’. The cause may be that artifact has timed out, or the authorization code was replayed, or the authorization code is invalid.

at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthTokenProtocolHandler.RedeemAccessToken(OAuthAccessTokenRequestContext tokenContext)

An earlier post shows our configuration of the two different client IDs and their redirect URIs that have been set up in ADFS, these correspond to the two client IDs and URIs provided by the two different instances of the application when calling the /oauth2/token endpoint.

The development environment uses the hms-dev-website client ID and works fine. The test environment uses the hms-beta-website client ID, that I’ve confirmed with a debugger and watched it call the /oauth2/authorise endpoint with the correct client id as a query parameters (“client” and “resource”).

The authorisation codes received are different each time, and I’ve confirmed it’s only ever sending the code it gets back from ADFS immediately after receiving it.

The only thing I can think that might be confusing the situation is that while there are two client-ids set up, I’ve only set up one Relying Party Trust in ADFS but with both of the client IDs as “Relying party identifiers”.

Another thing to note is that we have 2 ADFS servers fronted by a web application proxy that load-balances between them.

We have tested different authenticated users but we get the same result.

Источник

Not sure if this is a bug or configuration issue.

Which Version of MSAL are you using ?
MSAL 4.8.2

Platform
net45

What authentication flow has the issue?

• Desktop / Mobile
  • Interactive
  • Integrated Windows Auth
  • Username Password
  • Device code flow (browserless)
• Web App
  • Authorization code
  • OBO
• Web API
  • [X ] OBO

Other? — please describe;

Is this a new or existing app?
This is a new app to understand and document the pattern in our environment.

Repro
I have a Web Api (.Net 4.5) calling a Web Api (.Net 4.5). I’m getting the following exception when executing the following:

AuthenticationResult result = await app.AcquireTokenOnBehalfOf(scopes, userAssertion)
.ExecuteAsync().ConfigureAwait(false);

Here is the full function:

            var authContext = ConfidentialClientApplicationBuilder.Create(mServiceCredentialOptions.ClientId)
                .WithAdfsAuthority(mAuthorityOptions.Authority)
                .WithClientSecret(mServiceCredentialOptions.ClientSecret)
                .Build();

            var bootstrapContext = (string)principal.Identities.First().BootstrapContext;
            var userAssertion = new UserAssertion(bootstrapContext, "urn:ietf:params:oauth:grant-type:jwt-bearer");
            AuthenticationResult result = await app.AcquireTokenOnBehalfOf(scopes, userAssertion)
                .ExecuteAsync().ConfigureAwait(false);

Expected behavior
I’m expecting an access token for the endpoint that I’m calling.

Actual behavior
Full exception:

«ExceptionMessage»: «MSIS9601: The ‘resource’ parameter is missing in the request. Send the ‘resource’ parameter that contains the resource identifier’s value.»,
«ExceptionType»: «Microsoft.Identity.Client.MsalServiceException»

Additional context/ Logs / Screenshots
I’m finding this entry in ADFS eventlog:

Encountered error during OAuth token request.

Additional Data

Exception details:
Microsoft.IdentityServer.Web.Protocols.OAuth.Exceptions.OAuthAuthorizationMissingResourceException: MSIS9226: Received invalid OAuth request. The ‘resource’ parameter is missing or found empty. The ‘resource’ parameter must be provided specifying the relying party identifier for which the access is requested.
at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthOnBehalfOfContextBase.ValidateCore()

The scopes passed into the function is:
@»urn:Enterprise:PolicyInformation//openid», @»urn:Enterprise:PolicyInformation//user_impersonation»

I have tried some many combinations (single forward slash, using the Client Id, etc.)

Captured the network trace and saw this:
client_id=b5342232-4b42-4206-8cd0-5972e8420d42&client_info=1&client_secret=Removed&scope=offline_access+openid+profile+urn%3AEnterprise%3APolicyInformation%2Fopenid+urn%3AEnterprise%3APolicyInformation%2Fuser_impersonation&grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer&assertion=Removed

Noticed that the scope included additional scopes that I didn’t ask for. Is this correct?

Hi mates. Today we’re going to work on the error MSIS9605: The client is not allowed to access the requested resource. on AD FS when a hybrid device tries to get an Enterprise PRT.

To reproduce the issue, let’s consider the scenario below:

AD FS: 2019
Device Registration Service: Enabled
Client: Windows 10
Join type: Hybrid Join
Issue: Hybrid device not able to receive Enterprise PRT

Enterprise PRT

The Enterprise PRT can be used for device authentication on-premises when you have policies evaluating the device status. For hybrid Azure AD joined devices, the device could have PRT from both Azure AD and on-premises AD simultaneously. On-premises joined devices will only have an Enterprise PRT.

Troubleshooting

To identify if the device is not able to acquire the PRT, let’s run the command dsregcmd /status on the affected machine. We might get the output similar to this below:

+———————————————————————-+
| SSO State |
+———————————————————————-+

            AzureAdPrt : YES
  AzureAdPrtUpdateTime : 2021-05-31 15:35:27.000 UTC
  AzureAdPrtExpiryTime : 2021-06-14 15:35:26.000 UTC
   AzureAdPrtAuthority : https://login.microsoftonline.com/TenantID
         EnterprisePrt : NO
EnterprisePrtAuthority : https://adfs2019.ulyneves.com:443/adfs

On the client’s event viewer:
You might see we see events 1025, 1118 and 1081 on event viewer looking for path Microsoft-Windows-AAD/Operational as below:

Http request status: 400. Method: POST Endpoint Uri: https://fs.contoso.com/adfs/oauth2/token/ Correlation ID: 225BEAC5-37F8-4A2E-8D2C-BA2A819FE2F3

OAuth response error: unauthorized_client
Error description: MSIS9605: The client is not allowed to access the requested resource.

Enterprise STS Logon failure. Status: 0xC000006D Correlation ID: 225BEAC5-37F8-4A2E-8D2C-BA2A819FE2F3

On AD FS server:
If AD FS Tracing logs are enabled, you might see we see events with ID 178 on event viewer looking for path AD FS Tracing/Debug as below:

An OAuth Access Token could not be issued for next generation credentials grant: to client ’38aa3b87-a06d-4817-b275-7a316988d93b’ for resource ‘http://schemas.microsoft.com/ws/2009/12/identityserver/selfscope’.
The client IP is ‘X.X.X.X’
. The Exception encountered: ‘Microsoft.IdentityServer.Web.Protocols.OAuth.Exceptions.OAuthUnauthorizedClientException: MSIS9368: Received invalid OAuth request. The client ’38aa3b87-a06d-4817-b275-7a316988d93b’ is forbidden to access the resource ‘http://schemas.microsoft.com/ws/2009/12/identityserver/selfscope’ with scope ‘ugs’.
at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthProtocolContext.ValidateScopes(String scopeParameter, String clientId, String relyingPartyId)
at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthJWTBearerRequestContext.ValidateCore()
at Microsoft.IdentityServer.Web.Protocols.ProtocolContext.Validate()
at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthTokenProtocolHandler.PreAuthenticationProcess(ProtocolContext context)’

On AD FS Admin logs, you might see error message below:

The input parameters in the received OAuth JWT bearer Request are found to be invalid
Encountered error during OAuth token request.
Additional Data
Exception details:
Microsoft.IdentityServer.Web.Protocols.OAuth.Exceptions.OAuthUnauthorizedClientException: MSIS9368: Received invalid OAuth request. The client ’38aa3b87-a06d-4817-b275-7a316988d93b’ is forbidden to access the resource ‘http://schemas.microsoft.com/ws/2009/12/identityserver/selfscope’ with scope ‘ugs’.
at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthProtocolContext.ValidateScopes(String scopeParameter, String clientId, String relyingPartyId)
at Microsoft.IdentityServer.Web.Protocols.OAuth.OAuthToken.OAuthJWTBearerRequestContext.ValidateCore()

Run the command below on the primary AD FS server using PowerShell:

Add-AdfsScopeDescription -Name ugs 
$app = (Get-AdfsApplicationPermission -ServerRoleIdentifiers "http://schemas.microsoft.com/ws/2009/12/identityserver/selfscope" | ?{ $_.ClientRoleIdentifier -eq "38aa3b87-a06d-4817-b275-7a316988d93b" }).ObjectIdentifier 
Set-AdfsApplicationPermission -TargetIdentifier $app -AddScope 'ugs'
Restart-Service ADFSSRV

Validating the Enterprise PRT

With the scope created on AD FS, we do a fresh sign in and confirm the EnterprisePRT is issued by AD FS running command dsregcmd /status as below:

+———————————————————————-+
| SSO State |
+———————————————————————-+

            AzureAdPrt : YES
  AzureAdPrtUpdateTime : 2021-05-31 16:07:03.000 UTC
  AzureAdPrtExpiryTime : 2021-06-14 16:07:02.000 UTC
   AzureAdPrtAuthority : https://login.microsoftonline.com/tenantID
         EnterprisePrt : YES
EnterprisePrtUpdateTime : 2021-05-31 16:07:04.000 UTC
EnterprisePrtExpiryTime : 2021-06-14 16:07:04.000 UTC
EnterprisePrtAuthority : https://fs.contoso.com:443/adfs

On AD FS server, checking the AD FS tracing logs, we see event ID 34 with messages below that confirms the client being able to retrieve the details on scope below:

Successfully retrieved scope details for scope http://schemas.microsoft.com/ws/2009/12/identityserver/selfscope

Successfully retrieved scope details for scope urn:federation:MicrosoftOnline

Summary

In this article, we covered how to workaround the AD FS error MSIS9605: The client is not allowed to access the requested resource. when a hybrid device tries to get an Enterprise PRT.

I hope you have enjoyed reading this article and it helps you manage your AD FS environment.

Enjoyed the article? Like and share. 🙂

Note: I do not represent the organization I work for, all the opinions expressed here, are my own. This post is provided AS IS with no warranties or guarantees and confers no rights.

In case you have any suggestion or feedback, please leave a comment.

[ ]’s
Ulysses Neves

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 LogMicrosoftWindowsAADOperation” 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 LogMicrosoftWindowsAADOperation” 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 LogMicrosoftWindowsAADOperation” 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 LogMicrosoftWindowsAADOperation” 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 LogMicrosoftWindowsAADOperation” 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 LogMicrosoftWindowsAADOperation” 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 LogMicrosoftWindowsUser Device RegistrationAdmin” 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 LogAD FSAdmin” 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 LogAD FSAdmin” 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 LogAD FSAdmin” 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/ ###################
————————————————————————————————————————————————————-