4

We have a Web App secured with Azure AD B2C using custom Identity Experience Framework policies to allow users to register and sign in with social identities (Microsoft, Google, Facebook), or with an identity from another federated Azure AD instance, or with 'local' Email / Password accounts.

All the social accounts and the Federated AD work correctly. Sign up and sign in with Email/Password was working correctly, but we are now experiencing an error. We haven't knowingly made any changes to our Email/Password configuration since this was last known to be working, so we're not sure how this has happened.

The issue is: Sign Up with a new Email Address works correctly, and after the process completes, the user is correctly logged-in, and their account appears in the directory. If the user signs out, however, then any attempt to sign back in again fails:enter image description here

(Email address shown is not the actual one. Error has been repeated by multiple users with new and old email/password combinations.)

Digging into the portal, the underlying error is revealed as:

70001 The application named X was not found in the tenant named Y. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You might have sent your authentication request to the wrong tenant.

This error appears sometimes to be related to a failure to grant permissions to an application in the portal. We have tried removing and reinstating all permissions, and re-granting permissions. This has not solved the issue.

Does anyone know what could be causing this issue, and in particular why sign up / sign in works correctly, but returning sign in does not?

UPDATE:

Just to confirm that we have the IEF and Proxy IEF apps configured in the AD directory: enter image description here

And we have the login-NonInteractive technical profile configured in TrustFrameworkExtensions.xml: enter image description here

Having wired up Application Insights (following these instructions https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-troubleshoot-custom), we're able to get to this more detailed error:

AADSTS70001: Application with identifier 'ProxyIdentityExperienceFrameworkAppID' was not found in the directory weapageengine.onmicrosoft.com

The only place 'ProxyIdentityExperienceFrameworkAppID' appears in any of our custom policies is shown in the XML snipped above, but this seems correct as per the documentation here: https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack/blob/3b4898fec3bf0014b320beffa6eb52ad68eb6111/SocialAndLocalAccounts/TrustFrameworkExtensions.xml#L38 - unless we are meant to update those 'DefaultValue' attributes as well?

Resolution: As per the answer below, it is necessary to update both the Metadata and the default values with the relevant app ids. Worth noting that in the GitHub sample https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack/blob/3b4898fec3bf0014b320beffa6eb52ad68eb6111/SocialAndLocalAccounts/TrustFrameworkExtensions.xml#L38 the boilerplate values are differently cased, leading to our missing one in a replace-all:

enter image description here

Jude Fisher
  • 11,138
  • 7
  • 48
  • 91

1 Answers1

3

The local account sign-in authenticates the end user against the Azure AD B2C directory and then reads the user object from it.

The local account sign-up and the social account sign-in do not authenticate the end user against the Azure AD B2C directory. The local account sign-up writes the user object to it. The social account sign-in delegates authentication to the social identity provider and then either writes the user object to the Azure AD B2C directory if the user object does not exist or reads the user object from the Azure AD B2C directory if the user object does exist.

To enable authentication of the end user by the local account sign-in against the Azure AD B2C directory, you must add the Identity Experience Framework applications to the Azure AD B2C directory and then configure these IEF applications with the login-NonInteractive technical profile.

The local account sign-up and the social account sign-in do not require these applications.

Chris Padgett
  • 14,186
  • 1
  • 15
  • 28
  • Thanks, Chris. See update above: we do have both of those steps complete, and they appear correctly configured. What I don't understand is how sign up -> sign in can work correctly, but sign in alone can then fail? – Jude Fisher Apr 09 '18 at 08:03
  • Hi @JcFx Thank you for the additional info. You must also change the `DefaultValue` values for the `client_id` and `resource_id` input claim types to the application identifiers of the "ProxyIdentityExperienceFramework" and "IdentityExperienceFramework" applications. – Chris Padgett Apr 11 '18 at 10:45
  • Thanks, Chris. Got it, and it's working now. Small pedantic note, in the sample, the default values and the boilerplate in the Metadata are capitalised differently ('AppId' vs 'AppID') - hence confusion over whether to replace them both. See pic above in amended question. – Jude Fisher Apr 11 '18 at 14:35