AD FS SAML sign on with Azure AD Enterprise APP: AADSTS20001: The sign-in response message does not contain an issued token.

Question

Hello everyone,

I'm configuring trying to configure an IIS based Web App to accept a SAML authentication flow shaped this way:

An Azure tenant on which some users are provisioned acts as IdP and is federated with AD FS for the SAML authentication flow
On AD FS, the app is a Relying Party that updates itself through the Azure Enterprise App metadata.xml

the users can then input the url of the app (https://example.certificate.com/), go through AD FS immediately to login.microsoftonline.com/app_id , and login with their microsoft account, then be redirected back on the application.

Now, after configuring everything, endless tries and research, I'm stuck at a point where I get

AADSTS20001: The sign-in response message does not contain an issued token.

I suspect my AD FS has some misconfiguration somewhere which doesn't allow it to send a proper token to AAD to finish the SAML cycle. This should be a SP initiated SAML but it's not working.

Can anyone please help with this?

Many thanks

Answer 1

@Luster Mark , The description provided above is little confusing. Let me share my understanding below:

We have an application hosted on IIS, and is added as a Relying Party on ADFS. Also, for this same app, an app registration is being done on Azure AD. Now when you try to access this app using a Microsoft account (like hotmail.com, outlook.com or live.com) it throws the underlying error:
AADSTS20001: The sign-in response message does not contain an issued token.

If this is the scenario, then based on my understanding the error looks legitimate. As mentioned by you, the users being used to login to the apps are all synced users from your on-prem AD environment to your Azure AD tenant and then second thing is that your on-prem domain is added as a Federated Domain in Azure AD. Now when you access your app hosted on IIS, it first redirects the user to ADFS for it to get authenticated, but then ADFS redirects it to AAD. When the user enters the Microsoft account in the username section of AAD, some how AAD is not able to find it and then it redirects it back to the ADFS server again since the domain is federated.

Correct me if I am wrong in my understanding. But if this is the case, then I would suggest you register the application in any one of the IDPs either on Azure AD or on ADFS. If you register the application on Azure AD, then you would be able to login using Microsoft account as well as Work or School account based on the configuration you make while registering
this app in Azure AD. Secondly, if you plan to use ADFS, then only on-Prem users would be able to get authenticated using the UPN that is being used for your on-prem domain.

Hope this helps.

Do let us know if this helps and if there are any more queries around this, please do let us know so that we can help you further. Also, please do not forget to accept the response as Answer; if the above response helped in answering your query.

Answer 2

Hi @soumi-MSFT , thanks for answering. The idea is as follows (and in the past I had implemented it fully, now for some reason it broke and I'm really struggling with bringing it back to the previous state)

Our other instances of the same IIS-hosted webapp:

1) Dns name of the app example.certificatename.com -> ADFS login screen, redirect to adfs.certificatename2.com -> insert credentials -> adfs performs authn/authz -> user is logged in and redirected to example.certificate.com/index

This instance (desired behavior)

1) Dns name of the app example.certificatename.com -> ADFS login screen, realm selection, click on "login.microsoftonline.com" amongst the "tiles" (only possible when I enable login.microsoftonline.com between claim providers on ADFS, other than the normal Active Directory) -> redirected on login.microsoftonline.com/enterprise_app_id -> input credentials matching user in AAD -> login successful -> SAML assertion sent to ADFS consumer (adfsurl/adfs/ls) -> application

Answer 3

Hi @soumi-MSFT , thanks for answering. The idea is as follows (and in the past I had implemented it fully, now for some reason it broke and I'm really struggling with bringing it back to the previous state)

Our other instances of the same IIS-hosted webapp:

1) Dns name of the app example.certificatename.com -> ADFS login screen, redirect to adfs.certificatename2.com -> insert credentials -> adfs performs authn/authz -> user is logged in and redirected to example.certificate.com/index

This instance (desired behavior)

1) Dns name of the app example.certificatename.com -> ADFS login screen, realm selection, click on "login.microsoftonline.com" amongst the "tiles" (only possible when I enable login.microsoftonline.com between claim providers on ADFS, other than the normal Active Directory) -> redirected on login.microsoftonline.com/enterprise_app_id -> input credentials matching user in AAD -> login successful -> SAML assertion sent to ADFS consumer (adfsurl/adfs/ls) -> application

Answer 4

@Luster Mark , I apologize for not able to reply on this earlier as I somehow missed this thread.

Scenario 1, as you described, it working as per expectation., but for the Scenario 2, there are certain points that needs to taken care of. I am listing the scenarios/points below for your reference:

1. Your on-Prem Domain lets say mydomain.com is a federated domain under tenant mytenant.onmicrosoft.com. In this scenario, if you have added the tenant mytenant.onmicrosoft.com as a claims provider with ADFS, then the flow would be something like: App ---> ADFS Signing page to select the IDP ----> AAD is Selected here ----> Gets redirected to AAD for Auth ---> Enters the username with UPN as user@mydomain.com ---> AAD finds its a user from Federated domain ---> Redirects it back to ADFS for auth ---> After auth ADFS redirects back to AAD with token ---> AAD creates a new Token ---> AAD redirects back to App with the new token
2. Your on-Prem Domain lets say mydomain.com is a managed domain under tenant mytenant.onmicrosoft.com with Password hash Sync enabled and users are synced to AAD. In this case, the flow would look something like: App ---> ADFS Signing page to select the IDP ----> AAD is Selected here ----> Gets redirected to AAD for Auth ---> Enters the username with UPN as user@mydomain.com ---> AAD has the password hash of the user and hence authenticates it and prepares a token and sends it to ADFS ---> ADFS prepares the next token and sends it to the user ----> User gets redirected back to the app with the new token from ADFS
3. You are accessing the application using a user who has a Microsoft Account like hotmail.com, outlook.com or live.com. In this scenario the flow would looks something like: App ---> ADFS Signing page to select the IDP ----> AAD is Selected here ----> Gets redirected to AAD for Auth ---> Enters the username with UPN as user@Karima ben .com ---> AAD redirects it to live.com ---> live.com authenticates the user and prepares a token and sends it to AAD ---> AAD validates that token and prepares a new token and sends it to ADFS ---> ADFS again prepares a new token and sends it to user ----> User gets redirected to the App with the new token from ADFS

These are the possible auth flows here.

Hope this helps.

Do let us know if this helps and if there are any more queries around this, please do let us know so that we can help you further. Also, please do not forget to accept the response as Answer; if the above response helped in answering your query.