Even though I think this feature should be reasonable, but actually it does not work per my test.
I gave the Users Administrator to the service principal at the AU scope, but it cannot reset the user's password in the group belongs to the AU, even cannot reset the direct user's password(the user was directly added in the Users (Preview) in the portal).
But if I test with a work account([email protected]) with the same Users Administrator at the AU scope, it can reset the direct user's password, but still cannot reset the user's password in the group, looks the permission cannot be inherited.
So in conclusion, if you want to reset the password of the users in the groups belongs to the AU, you need to add these users directly to the Users (Preview), then use a user account e.g. work account with the Users Administrator role to do that.
To do this in runbook, you can store your user name and password in the Credentials of the automation account, then use the code in the runbook to login your account and get group members and reset passwords.
$myCred = Get-AutomationPSCredential -Name '<credential-name>' $userName = $myCred.UserName $securePassword = $myCred.Password $myPsCred = New-Object System.Management.Automation.PSCredential($userName,$securePassword) Connect-AzureAD -Credential $myPsCred Get-AzureADGroupMember $password = ConvertTo-SecureString "xxxxx" -AsPlainText -Force Set-AzureADUserPassword -ObjectId xxxx -Password $password
Service Accounthere you mean the service principal?