When using Azure AD B2C (Business to Consumer) you can easily do that with custom policies from the Identity Experience Framework.
The described solution is based on the LocalAccount templates from the Custom Policies Starter Pack GitHub repository.
Beside editing your policy with the steps below, you can download the complete files from my GitHub repository: B2C-custom-policy-with-consent
What it does:
Most organizations have understood the need for securing cloud identities with a second factor of authentication like Azure Multi-Factor Authentication (MFA). Still, a lot are doing it wrong. It is not complicated to do Azure MFA the right way with using Microsoft Intune and conditional access. Spend 20 minutes on this session and see how to protect all cloud apps and identities with a few simple steps.
Watch out that short but informative 18 mins Session from Ignite 2018 on How to get started with Azure MFA the right way:
After I upgraded my MIM 2016 test lab to hotfix build 18.104.22.168 I recognized that the MIM portal sync rules became orphaned (broken) when I let them all recreate by setting the password on the MIMService MA again.
Some users also reported that in the following FIM/MIM TechNet Forum post: https://social.technet.microsoft.com/Forums/en-US/e0e6e2db-46e1-4638-bdfb-4436b8f53ae1/mim-portal-sync-rules-have-become-orphaned?forum=ilm2
I already answered there with some points that I found out while debugging the issue.
Like the guy in the forum I also tried to update to the latest hotfix 22.214.171.124 but that does not solve the issue, and it might be possible that you also run into this issue when only applying 126.96.36.199.
The error is like following:
Continue reading “MIM 2016 sync rules become orphaned (broken) after update to 188.8.131.52”
While Azure MFA has many good capabilities there is currently one thing you cannot do, which in may be important for some customers, and in fact I already heard that from them.
The missing part is to ONLY force the user to register for Azure MFA without enable it on the whole account on any login.
Ok, ok, it’s not 100% true, as you can purchase a Azure AD Premium P2 license and use Identity Protection to force registration only, but for sure, no customer want to buy a P2 only for that particular feature as is might be very expensive depending on the amount of users you have.
But now, or in the near future, to be correctly, there is an new way to do so. And the solution is the new converged experience for Azure MFA and SSPR (Self Service Password Reset) currently in an opt-in public preview.
Here is how I did it:
Continue reading “Force Azure MFA registration without enabling MFA on the user”
One of the security challenges when using Azure MFA in combination with Conditional Access is the fact that the MFA registration will occur when the user accesses the particular application that is protected the first time.
But sometime that might not be the case for days or even month, for example if MFA is only required by conditional access if the users is outside the corporate network or the application is only used very rarely.
In the meantime when the credentials of that users are leaked it is possible for an attacker to do the MFA setup instead of the intended user.
However some companies prefer to pre-enroll or pre-register their users when their account is created in Azure AD. But what not should happen is that we enable Azure MFA for the account of the user we just want to pre-populate one or two authentication methods (mobile phone in fact).
But how can we do that:
Continue reading “(Bulk) pre-register MFA for users without enable MFA on the account”
It is quite easy in these modern times to invite and therefore add B2B guest users into your Azure AD tenant. Not only administrators but also users can simply invite any user of the world that has a valid email address (depending of the settings of your tenant).
While simply invite them, guest users will not have any permissions (beside login) to any resource of your tenant until permissions are assigned to them.
But a good identity management solution does not only care of creating identities but also remove them when no longer needed. Azure AD currently at time of writing this article does not provide any mechanism to get rid of unused guest accounts, it even does not provide a proper way to identity them.
There is no “LastLogin” attribute you can for example use, so you need to find the person who invited that guest and talk to him if it is still needed.
This is where my Azure AD B2B guest user “Housekeeping” solution can maybe help you. It provides a way to set your own “LastLogin” attribute on guest account and even track pending invitations and removes guest accounts after a defined time.
So how does it work:
- Create an extension attribute to store the “LastLogin” as a DateTime
- Import the Azure AD sign-in logs by MIM2016 with a PowerShell MA leveraging MS Graph Reporting API
- Import B2B users by MIM with a PowerShell MA leveraging the AAD PowerShell Module V2 cmdlets
- Aggregate sign-in logs to only get the newest login of a user
- Set the extension attribute of those accounts and export it to AAD
- Delete accounts after some time defined by an XML configuration file
Continue reading “Azure AD B2B Guest User Housekeeping Solution with MIM2016”
As you can see in my previous post on what is new in Azure AD for July 2018 there is an opt-in public preview of an new converged security info management (registration and management) available for Azure AD SSPR (Self Service Password Reset) and MFA (Multi Factor Authentication).
Currently you have to manage each security info in an separate portal which is now combined into one experience.
You can opt-in only a subset of your users (like a pilot group) by using a Azure AD group and activate the new feature only for that group or all users at one.
Once you activate the new experience the old one is no longer available until you disable the user for the public preview.
Once you enable this experience, users who register or confirm their phone number or mobile app through the new experience will have the ability to use them for MFA and SSPR, if those methods are enabled in the MFA and SSPR policies. If you then disable this experience, users who navigate to the previous SSPR registration page at aka.ms/ssprsetup will be required to perform MFA before they can access the page.
Continue reading “Exploring the new converged Azure SSPR and MFA registration experience”