I have used Azure AD B2C sign-in and sign-up policy for user login and signup process with Multi factor Authentication. Also set password resetting policy.
Everything is working fine with Phone factor (MFA).
Now client wants to add security questions while signing up a user and password resetting.
I have enabled security question and selected 5 questions; however, it's not visible while signing up a user and password resetting.
I am not able to understand what is the exact problem.
Based on the official documentation, Azure AD B2C only supports using a verified email address as a recovery method.
Currently, we only support using a verified email address as a
recovery method. We will add additional recovery methods (verified
phone number, security questions, etc.) in the future.
In addition, Azure AD B2C only supports phone call and text message verification for Multi-Factor Authentication(MFA).
Azure Active Directory (Azure AD) B2C integrates directly with Azure
Multi-Factor Authentication so that you can add a second layer of
security to sign-up and sign-in experiences in your consumer-facing
applications. And you can do this without writing a single line of
code. Currently we support phone call and text message verification.
More information about MFA and password reset for Azure AD B2C, please refer to the following links.
Azure Active Directory B2C: Set up self-service password reset for
your consumers
Azure Active Directory B2C: Enable Multi-Factor
Authentication in your consumer-facing applications
Related
Azure/Intune newbie here.
We are planning to implement Intune in our org, and I have a question regarding user device log-in to Windows devices if Azure AD is Okta federated.
From the log-in/lock screen, do users use their Okta credentials to log in to their devices instantly without taking them to the company okta portal?
We are an Okta shop and wanted to use a single set of credentials for device logins and Okta SSO.
This is not yet implemented, so I am unsure how the device log in works.
If your organization is planning to use Intune for managing Windows devices and you have federated your Azure Active Directory tenant with Okta, it is possible to allow users to sign in to their Windows devices using their Okta credentials.
When users sign in to their Windows device, they will be presented with the Windows sign-in screen, which will prompt them to enter their credentials. If your organization has configured Windows Hello for Business or multi-factor authentication, users will be prompted to provide additional verification.
If you have set up federation between Azure AD and Okta using the Security Assertion Markup Language (SAML) protocol, the Okta sign-in page will not be shown to the user during the Windows sign-in process. Instead, the user's credentials will be validated by Okta behind the scenes, and the user will be signed in to their device directly. Which of course will take more effort to implement SAML (As I have experienced)
To enable this sign-in experience, you need to configure the Windows 10 device to use Azure AD for authentication. You can do this by joining the Windows device to Azure AD during the device setup process or by using the Azure AD join feature to join the device to Azure AD.
Once the device is joined to Azure AD, you can then deploy Intune policies to the device to manage its settings and applications. Additionally, you can also use Azure AD Conditional Access policies to control access to company resources based on factors such as the user's location, device compliance status, and authentication context.
Keep in mind that to use this sign-in experience, your users will need to have their Okta credentials synchronized to Azure AD using Azure AD Connect or another supported method. Additionally, you may need to configure the Azure AD and Okta federation settings to ensure that the authentication flow works correctly.
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
We are using signup/signin builtin user flow and want to combine the "forgot password" part into this flow though sspr https://learn.microsoft.com/en-us/azure/active-directory-b2c/add-password-reset-policy?pivots=b2c-user-flow#self-service-password-reset-recommended
However, the sspr bottun unable to click in user flow property and show a line at the bottom "sspr currently unavailable to support combind local account", am I using the wrong account or APIM needs to do some conf?
I have searched a while and there is no similar case. Has anyone encountered the same problem?
Please check if below are the causes:
Note : In a sign-up and sign-in journey, a user can reset their own
password by using the Forgot your password link. This ability to
reset passwords only apply to local accounts in Azure Active Directory
B2C (Azure AD B2C) i.e; you can only reset your password if you
signed up using an email address or a username with a password for
sign-in .
In case of azure ad, users of SSPR requires one of the following licenses: Azure AD
Premium P1 or P2, Microsoft 365 Business, or Office 365. If you have
a hybrid environment, you also need password writeback into your
on-premises AD. In this case, you’ll need Azure AD Premium P1 or P2
or Microsoft 365 Business.
You may not be able to see password reset menu option if you don't have an Azure
AD license assigned to the administrator performing the operation.
Please check out below references:
Troubleshoot self-service password reset - Azure Active Directory | Microsoft Docs
Frequently asked questions (FAQ) for Azure Active Directory B2C | Microsoft Docs
Azure AD B2C Password Reset - Stack Overflow
At the moment Azure AD B2C are not available in all regions. So , If I create Azure AD B2C in a region where it is available, is it possible me to migrate users later into a new Azure AD B2C, which will be created in my region when the Azure AD B2C available in the region?
p.s. copy of https://social.technet.microsoft.com/Forums/en-US/7e42bb1a-7a04-4a62-9864-5c7392f790cf/migrating-azure-ad-b2c-users-from-region-to-region?forum=paas
Currently there is no information from Microsoft as whether they will provide a native export feature within B2C to allow migration between regions. However you can export users between B2C tenants using GraphAPI as per this guide. One issue with this method for local accounts is that passwords cannot be migrated out of a B2C tenant, so you have two options:
Password Reset - You force every user to perform a password reset whether that be via an email sent to every user, or when a user tries to sign in for the first time.
Validate against old tenant - You modify your sign in policy on the new tenant to verify the users email and password combo against the old tenant via a REST API technical profile. If valid you then write the password to the new tenant.
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.