Du willst deinen Kollegen (Service Desk, etc.) also eine Methode für einen MFA Reset zur Verfügung stelle, willst aber keine Azure AD P2 (oder E5) Lizenz für PIM zuweisen? Natürlich sollen keine 20 Kollegen Global Admin werden… aber es jedesmal selbst zu mache ist auch nichts, oder? Hier ist dein Ausweg! Zudem wird sichergestellt, dass die MFA Settings von Global Admin Accounts nicht geändert werden können.
Erstelle einen Azure „Automation“ Account
Suche im Marktplatz nach „Automation“ und erstelle einen automation account.
Konfiguriere ihn nach Bedarf.
Konfigurieren den automation account
Füge das Module „MSOnline“ hinzu.
Öffne den Automation Account. Klicke auf Modules und Browse gallery.
Suche nach MSOnline und importiere es.
Füge die Global Admin Credential hinzu.
Klicke auf Credential, dann Add a credential.
Füge ein was du brauchst. Du brauchst einen global adminstror account des Azure AD Tenants.
Stelle ebenfalls sicher, dass der Account keine MFA befriedigen muss, da die Befehle für *-MSOL* mit MFA nicht klar kommen. Also ggf. den Account in die Ausnahme von Conditional Access nehmen.
Erstelle das Runbook
Klicke auf Runbooks und Create a runbook.
Fülle es aus wie du es brauchst.
Editiere das Runbook.
Füge folgenden Code ein.
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."
}
Klicke dann auf Save, dann Publish.
Jetzt kannst du einen Test machen und auf Start drücken.Stelle sicher, dass du einen Test-Account nimmt, da dessen MFA Einstellungen resettet werden und der User diese Einstellungen wieder eintragen muss.
Rechte
Die User die das Runbook nutzen wollen, brauchen folgende Rechte:
Reader Rechte auf der Resourcegroup
Gehe zur Resourcegroup in der der automation account ist und klicke auf Access controlle (IAM).
Füge die nötige User / Gruppen als Reader hinzu.
Automation Job Operator auf dem Automation Account
Gehe zum automation account und klicke auf Access Control (IAM).
Füge die benütigten User / Gruppen als Automation Job Operator hinzu.
Aufräumen
In meine Fall wollte ich nicht, dass die App die der automation account automatisch registriert Contributor Rechte auf meiner Subscription haben lassen. Also habe ich sie einfach auf Subscription Level im IAM entfernt, um auf Nummer sicher zu sein. Da der automation account nur für dieses eine Skript genutzt wird und sonst keinerlei Interaktion mit Azure hat, wird es hier zu keinen Problemen kommen.
Jetzt noch den Kollegen (Service Desk) den direkten Link zum Runbook geben. Besser, als dass sie selbst durch Azure durchklicken und suchen müssen.
Alternativ könntest du noch einen Flow erstellen, welcher nach dem UPN fragt und diesen dann an das Runbook weitergibt. Aber dafür wäre eine weitere Flow Lizenz für jeden User fällig, der dieses Runbook ausführen will. Und da dieses Runbook ohnehin für Admins ausgelegt ist, gehe ich davon aus, dass diese mit solcher einer „GUI“ zurecht kommen.