I am moving from an Asp.Net identity management to Azure AD B2C. I added the existing user through Graph API and gave the user some random password as of now in stage. Is it possible to use the old password of the user (I cannot get the existing password from my database). I remember in one of the talks of Azure AD B2C, they get the password by back tracking the request though I am not clear about it.
What is the best strategy to move to Azure AD B2C with minimum password friction?
I used the approach described here (Just-In-Time migration source code)
pre-migrate users with auto-generated password
create an API to check user credentials from the old user store (Microsoft Docs)
add the API call to the Technical Profile in the SignIn Policy so every time a user tries to sign in, the credentials will be checked against the old user store (Microsoft Docs)
add the API the privilege to change the password if the old credentials are verified (see my response to this post) or impersonate the user (if you safely stored the auto-generated passwords in somewhere secure place)
you user credentials were updated 'just-in-time' so your user will not notice this change on the fly
I don't think you can get the password out from ASP.NET identity management, since the password is hashed.
As a migration strategy, you could create the Azure B2C users, from your existing authentication logic backend in ASP.NET identity management, upon successful login, since users are sending their usernames and passwords for authentication. Once all the users are moved, you can shift to Azure B2C login.
Related
In short: how to set up Azure B2C to pre-create users and invite them to set their initial password (rather than reset it).
We have public facing website that an organisation can pay for and it gives them access to their own area. We add one or more user's email addresses to our database to grant them a login. Privileged users at the organisation can invite other users to grant them access to their organisation's area.
We wish to move our authentication, session and password management from a home grown solution to Azure AD B2C.
A new user currently receives a friendly invitation email with a hyperlink that contains a token that gives them permission to set their password.
We could create a custom policy to handle this but I really don't want to go down that route due to their complexity and shelf life.
The only way that I've found "out of the box" is to create the user in Azure AD (not problem with that), set a temporary password and email them an invite asking them to "reset" their password. The reset part is very unclean as they are not resetting their password, they are setting their initial password and this will be confusing.
Also note that we do not want the user to be able to change their email to something like a hotmail account, as the admin must be in charge of this to ensure they use their work email.
All help appreciated.
Andy
• In your scenario, I would suggest you configure an application registration in Azure AD B2C and configure user flows in it for resetting the password for every user logging in it. Also, while registering an application in Azure AD B2C, you can select the option for ‘Accounts in this organizational directory only (Default Directory only - Single tenant)’ and integrate it with your website in the frontend API such that the user flow to reset the password after verifying the email address comes up for every user.
For the above said configuration, kindly refer to the below documentation link for more details as it describes the configuration for registering users of a single tenant/organization: -
https://learn.microsoft.com/en-us/azure/active-directory-b2c/identity-provider-azure-ad-single-tenant?pivots=b2c-user-flow
Also, refer to the below documentation link for resetting the initial temporary password using the user flow section as setting up a user flow is a very simple process as described below: -
https://learn.microsoft.com/en-us/azure/active-directory-b2c/add-password-reset-policy?pivots=b2c-user-flow
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
My scenario is a public website, with authenticated access that is managed by AzureAdB2C, and the authentication is not embedded but on a subdomain style. In the authentication form I see that there's the option for password reset (for someone who forgets it) but my question is when the user is already authenticated and so outside Azure context, how can he ask for a password change?
Is there any endpoint or so (that would receive the email linked to the account)?
Thank you
Still not clear because you mention "fire the change/reset password flow?". Which is it or is it both?
If reset, you can use a custom policy. Just put the link to the policy on your page.
There are a number of password reset flows that may be of interest.
For change password, see here. Again, just put the policy link on the page.
Unsure if you would have to login again.
You can Configure password change using custom policies in Azure Active Directory B2C.
In Azure Active Directory B2C (Azure AD B2C), you can enable users who are signed in with a local account to change their password without having to prove their identity through email verification. The password change flow involves following steps:
The user signs in to their local account. If the session is still active, Azure AD B2C authorizes the user and skips to the next step.
The user verifies the Old password, and then creates and confirms the New password.
If the question is to reset the password because the user forgot it but is still logged in, I can imagine logging out the user and redirecting them to the login page where they can choose the reset password option.
EDIT:
The Azure AD B2C article Set up self-service password reset for your customers states that
This article applies to self-service password reset used in the context of the standard Sign in user flow, which uses Local Account SignIn as the identity provider. If you need fully customizable password reset user flows invoked from your app, see this article.
Somehow resetting your password with a password reset flow / custom policy while you're logged in and don't 'need' your current password feels weird.
I have the following scenario:
On-prem SQL SSO database exists that manages usernames and password (salted and hashed).
Azure AD B2C in the cloud for local accounts (usernames and passwords).
I would like to have both systems stay in sync. So, when a user requests a password reset from the on-prem SSO database, it will salt and hash the password, and then transmit that password to Azure AD B2C. Similarly, if the user requests a password reset from Azure AD B2C it will salt and hash that password back down to the on-prem database as well, if possible; I can imagine a scenario where this simply isn't possible in which case it would be OK if the hash value of the password is stored and we can assign a secondary column for "authentication_method" which will allow other client apps to still authenticate. If a new user signs-up on either side, then the appropriate record is created in both systems for local accounts only.
How can I go about implementing such a flow? What kind of documentation would be helpful here from the AD B2C side? Are there other synchronization tools available for this scenario?
I can imagine something like Apache Kafka or some script to sync data back and forth, but I am not sure about the specifics on the B2C side of how to get the password. I'm sure I've seen some documentation on how to update the user's password for the first scenario of on-prem to cloud, but lack information on how to go from cloud to on-prem.
The purpose of this is to support a newer application to leverage B2C, but still allow older apps to work without having to update them to B2C.
Password HashSync to Azure AD B2C is not supported. There are a couple of moving parts in your scenario that needs to be addressed.
The Azure AD B2C to SSO Database: You can use REST-API that Azure B2C custom policy calls from its custom policy, which acts as a broker to authenticate (username, password). Since you are using local accounts with Azure AD B2C this should work as long as your backend can authenticate the user using username/password. There is no sync needed but until the SSO database goes away you need to keep using the REST-API. Essentially, you want to use a single source of truth. This approach is similar to the pattern describe here.
On the Azure AD B2C side, you can update the password for a local user account using Microsoft Graph API. This opens up the door to update the password from your on-prem system to Azure AD B2C as needed. Of course, Azure AD B2C hash the password itself but you don't have access to it.
Either way, you need to evaluate the pros and cons.
one of our existing projects is running with a traditional authentication logic (having a user table in database). How the plan is to move the identity to AzureB2C with social IDPs integrated. But there are still some ares where we would need the reference of the existing user table. I need to find a way to map the logged in user from Azure B2C with the user table in database. I can read the email property from claims and try to map, but the challenge is user might have a different email for his social accounts. I know this actually defeats the purpose of the openId/oAuth to look back again in the user table after login. But this is a strange situation in running into. Any ideas how best this can be done ?
Copying response from: https://social.msdn.microsoft.com/Forums/en-US/221fce11-28ff-4236-a300-d6160ffc9379/azure-ad-b2c-how-to-map-the-user-logged-in-from-social-idp-to-a-local-user-table-?forum=WindowsAzureAD
Some facts are missing from your question so I will make assumptions which you can correct.
Assume that:
You do not use social IDPs today. So no existing connection between the social account and the local DB account.
This point is crucial because it is usually the user's prerogative (due to privacy) to make this link explicitly.
Assume that you will tell the user explicitly what you are doing as part of the transition.
To achieve this with b2c built-in policies you could:
1. Your app logs in the user the old fashioned way.(existing lookup DB)
2. Your app then invites users to register (in fact re-register) using a b2c signup policy which offers them social idp choices.
3. At the end of the b2c registration process, the user's email which was provided and proofed during the b2c signup and Object ID (newly created) is sent back to the App
4. The app uses the object ID and Graph to write the users existing id (old DB email or other unique user id you used today) to the new user's object in Azure AD B2C.
5. The app should note on the old DB that this user has been migrated so in the future the app does not present the option to re-register.
6. The app has to manage users in 2 different states.
Other alternative is to use custom policies and Account Linking
Here you could
1. Migrate all users into b2c using their old passwords. (assume you can get them from old DB in the clear) using Graph.
2. Point your app to b2c - users can login
3. Offer you users the option to link their b2c account to a social account. this requires custom policy and a policy path that is not public but its a simple sample we can provide.