I am having an issue authenticating users for a external, non-cloud ASP.NET application that is going to be secured via our B2C tenant using a simple username (i.e. not email address).
I have imported the usernames to B2C using the Graph API and set the SignInName type to be "userName" on each account. The Azure AD B2C Identity Provider is set to "Username" and I have created a sign-in policy where the identity provider is set to "Local Account SignIn" and tied it to my B2C application. If I click the "Run Now" button on the policy, it takes me to the Azure login screen and I can enter one of the imported usernames/passwords and it authenticates and routes me to the application URL. This is the desired behavior.
HOWEVER, if when I execute my external app I get transferred to the Azure B2C login screen as expected, but it requires me to enter either a valid email address or telephone number. It will not allow the local B2C username. Seems something is disconnected in the sign-in policy for the application.
Can anyone offer a suggestion why the login page will not accept the simple username?
I guees this is a bit late? perhas other are looking for this.
Azure AD B2C can be use email OR localAccount for authentication. You need to set the "identity providers" to localAccounts:
Note: in odrer to create local accounts you need to set "creationType": "LocalAccount" in the JSON to create local account users.
Related
We have an existing Azure subscription where we run our processing infrastructure. We are setting up a new app to run in the same space, but with a Azure Active Directory B2C. We have the setup working and can create new customer users that can sign in.
We have been unable to determine how to have our own users in the existing company subscription sign in to the new app (powered by the AD B2C) with the same user/email/password.
We think the answer lies somewhere between single sign on and proxy user principal names?
We should also point out that when setting up the AD B2C, an administrator user was set up for the person that set it up. Their account has an issuer of ExternalAzureAD and their user principal name is pretty much their email as a suffix on the active directory domain. Although this user is "linked" (?) to the original user in our original AD, it has a different password, etc. So also not quite what we are looking for. Ideally this user would sign into the B2C with their actual email and password (the same one used in the non B2C original AD).
I tried to reproduce the same in my environment like below:
To allow the users to login with Azure AD credentials, make sure to register the Azure AD B2C application by selecting Accounts in any organizational directory (Any Azure AD directory - Multitenant)
To sign-in to the Azure AD B2C application, try using below authorize and token endpoints accordingly:
Note that, organizations endpoint will allow tenant-level login.
I created an Azure AD user like below:
When I tried to login to the Azure AD B2C Application through Azure AD user credentials, I am able to login successfully.
And the decoded access token contains Azure AD user information like below:
I am implementing a passwordless signin experience for local B2C account users with MFA credentials through Azure B2C custom policies. I am using AzureMfaProtocolProvider with a custom attribute stored phone number as an sms MFA option, and OneTimePasswordProtocolProvider with a custom attribute stored email as an email MFA option. When I initiate a login, the first step us username retrieval. The username is used to read the mfa options from AD and then presented to the user as options. Once they select an option, a code is sent and they must successfully validate the code from one of the MFA options to issue a token to the application. This works great, however I noticed that Active Directory does not store and log a "sign in" in the signin logs (https://learn.microsoft.com/en-us/azure/active-directory/reports-monitoring/concept-all-sign-ins). Per the document, MFA challenges should generate a signin log but it seems that MFA challenges with these protocol providers (AzureMfaProtocolProvider/ OneTimePasswordProtocolProvider) are not sufficient.
I am concerned that we will miss inherent Active Directory risk tracking without "sign ins" being generated. I am also operating with a business requirement to see those logs generated for auditing purposes.
As a work around, I am adding a psuedo password to user accounts on creation and then faking a login with the "login-NonInteractive" technical profile, which validates the credentials in AD using OIDC. This successfully generates a signin log but it seems hacky. My question is what is the recommended approach to generate a signin log in Azure AD with a passwordless solution?
what is the recommended approach to generate a signin log in Azure AD with a passwordless solution
For this scenario, you can implement magic link in this web application user can click login button and then user is redirected to identity provider in azure ad b2c.
Now in custom policy page user can select the magic link option to authenticate and user has to provide the email address and continue azure ad b2c will send a request to magic link web application and then this web api responsible to generating the magic link which we sent to the user mailbox.
For more information in detail, please refer below links:
samples/policies/sign-in-with-magic-link at master · azure-ad-b2c/samples · GitHub
https://github.com/azure-ad-b2c/samples#multi-factor-authentication-enhancements
I have Angular 9 client calling Azure Functions. I started off with msal-angular package using "implicit grant flow" for authentication, and that worked fine.
My client app registration in Azure has its Authentication set to "Accounts in this organizational directory only (Default Directory only - Single tenant)". I can't change this setting as the app will only be available to company users.
I'm using my personal Microsoft account with Gmail username (e.g.: user#gmail.com). This account is a "Guest" in Azure AD, so far, so good.
I'm moving away from msal-angular and implementing PKCE authentication flow.
I'm using angular-auth-oidc-client package. My stsServer and authWellknownEndpoint are set to https://login.microsoftonline.com/[tenant-id]/v2.0 (turned out to be the problem, see update at the bottom)
Here are the login scenarios I'm having issues with:
When I use my user#gmail.com, I get "unauthotized_client ..." error right after I enter my username
When I use my UPN (e.g.: user#gmail.com#EXT##our_ad_owner.onmicrosoft.com) I get to the password prompt, but my Microsoft password doesn't work. I understand why it doesn't work (that password has nothing to do with AD), but I can't figure out how to set AD password for that account.
When I try to reset my password in AD, it tells me that "user#gmail.com is a Microsoft account that is managed by the user. Only user#gmail.com can reset their password for this account."
Any help with setting AD password for my UPN would be appreciated. I would also like to know if it's possible to login with my actual email address, and not UPN.
UPDATE: The problem was with angular-auth-oidc-client setup, authWellknownEndpoint was set to https://login.microsoftonline.com/common/v2.0, after I changed it to https://login.microsoftonline.com/[tenant-id]/v2.0 it worked!
You get the first error because you are using https://login.microsoftonline.com/common/v2.0 as the authority. It treats your account as personal account rather than the guest account in your tenant. But your Azure AD app is configured as Accounts in this organizational directory only (Default Directory only - Single tenant), which is not supported for consumers (personal account). See the reference here.
So you should use https://login.microsoftonline.com/{your tenant id}/v2.0 as the authority. Then it will allow your user#gmail.com to sign in.
We have a scenario where we need to integrate Azure B2C with one of our existing system, where the email is not a mandatory user field, we have only the mobile number of the user as a mandatory field. I am looking for ways to integrate azure B2C where i can give a username and an initial password for the first time, instead of email. And all the password reset scenarios will have to go through OTP or email, where it will be a users choice to give email to reset the password.
We are able to create the user through Graph API initially, but
stuck with creating a user-flow where it will ask the username and password instead of email and password.
You can choose Username as local account types when configuring identity providers for Azure AD B2C in the Azure portal. In your Azure AD B2C tenant, select Identity providers, select Local account, and then select Username.
Then you need to select Local Account again in your user flow.
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:
(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:
And we have the login-NonInteractive technical profile configured in TrustFrameworkExtensions.xml:
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:
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.