So, you need to be able to provide an MFA Reset method to you colleagues (service desk, etc.), but don’t fancy buying a Azure AD P2 (or E5) license to provide PIM? And of course you don’t want 20 colleagues to be global administrator… but doing it yourself everytime is somewhat useless? Here’s your way out! Additional this is making sure that the MFA for a Global Admin cannot be changed.

Creating the Azure “Automation” Account

Search the marketplace for “Automation” and create an automation account.

Configure as desired and create.

Configuring the Automation Account

Add Module “MSOnline”:

Open your Automation Account. Click on Modules and Browse gallery.

Search for MSOnline and Import.

Add Global Admin Credential:

Click on Credential, then Add a credential.

Fill in as desired. You need a global adminstror account of your Azure AD Tenant.

Also make sure that this one doesn’t required to satisfy any MFA, as the commands for *-MSOL* can’t handle MFA.

Creating the runbook

Click on Runbooks and Create a runbook.

Fill in as desired.

Edit this runbook:

Enter the code:

Param(
	[Parameter(Mandatory=$true)]
	[string]$UserPrincipalName
)
 
if($UserPrincipalName.Count -eq 1){
	try{
		$creds = Get-AutomationPSCredential -Name "AzureAD-GA" #Name of GlobalAdmin as configured within Credentials part of the Automation Account
		Connect-MsolService -Credential $creds
		
		# Checking if User is a Global Adminsistrator. In this case don't want to allow this.
		# It could otherwise allow the Script users to hijack an Global Administrator account.
		$Role = Get-MsolRole -RoleName "Company Administrator"
		$GAs = Get-MsolRoleMember -RoleObjectId $Role.ObjectId

		# UserPrincipalName not part of Global Administrators?
		if($GAs.EmailAddress -notcontains $UserPrincipalName){
			# Then reset the MFA
			Set-MSOLUser -UserPrincipalName $UserPrincipalName -StrongAuthenticationMethods @()
			Return "MFA for $UserPrincipalName was successfully reset."
		}
		else{
			# No touching the MFA for this account...
			Return "$UserPrincipalName is a Global Administrator. You shall not pass!"
		}
	}
	catch{
		# Something went wrong
		Return "MFA for $UserPrincipalName was not reset."
	}
}
else{
	# User entered a wildcard or something similar. There are too many accounts returned.
	Return "No unique UserPrincipalName was provided."
}

Click Save, then Publish.

You can do a test start. Be sure not to use a productive user, as he/her MFA settings will be reset and the user needs to reconfigure it:

Access Rights

Make sure the users that are supposed to use it have:

Reader Rights on the Resourcegroup

Go to the resourcegroups which hold the automation account and go to Access controlle (IAM).

Add the required group or person as readers.

Automation Job Operator on the Automation Account

Go to the automation account and to Access Control (IAM).

Add the required groups or user as Automation Job Operator.

Clean Up

In my specific case it didn’t fancy letting the app registered by the automation account have contributor rights on my subscription.Therefor I simply removed it from IAM on the subscription level, just to be on the safe side. As this automation account is only used for the specific script and has no interaction with Azure, there will be no issue by doing so.

Give your users the link to the runbook directy. Rather than having them navigate through Azure themselves.

Alternatively, you could create a Flow and have the flow request the UPN of the user and pass it to this runbook. But this would cost you an additional Flow license for each user that is supposed to use this. And as this Runbook is designed for admins, I would assume they can handle this type of “GUI”.