Today, Office 365 offers a variety of admin roles that can be used to manage your tenant — 45 to be exact. These roles align with the general recommended practice of providing users and admins alike the least amount of access they require to complete their work. However, with that, there is still a problem of limiting these roles on subsets of users.
Imagine a multinational organization, where each country has their own set of Office 365 admins that are responsible for only the users in their region. John, one of the admins in Canada has been given the Password admin role, which allows him to Resets passwords for all non-admin users and some admin roles. Of course, you can use the Compliance admin logs to see if he changed the password for someone not in his region, but that is less than ideal.
One way to achieve this is with the help of the Power Platform and a little bit of Azure Function assistance. The general premises for this solution are as follows:
- Each admin would belong to one or more organizational AD groups that includes only the users they support.
- Each admin would also belong to an Admins AD group that would represent their role (e.g. Password Admins AD group)
- The admins are not assigned the admin role
The solution is made up a Power App, Power Automate, and Azure Function as depicted below.
The Power App access would be limited to only the Admins AD group. When an admin opens the App, it would automatically know the organizational AD groups that the user belongs to and display only those users in the gallery. The admin would then select the user and create a new password, by auto-generating one or manually setting it.
Once submitting it, the information would be sent to a flow that would simply pass the information on to the Azure Function using an HTTP call.
The Azure Function will then reset the password using the Set-AzureADUserPassword cmdlet. Here’s an example of what the Azure Function would look like.
$requestBody = Get-Content $req -Raw | ConvertFrom-Json$objId = $requestBody.objid$pwd = $requestBody.pwd$AutomationAccount = $env:AutomationAccount$Password = $env:Password$secpasswd = ConvertTo-SecureString $Password -AsPlainText -Force$adminCreds = New-Object System.Management.Automation.PSCredential ($automationAccount, $secpasswd)Import-Module "D:\home\site\wwwroot\ChangePassword2\mymodules\AzureAd.psd1"Connect-AzureAd -Credential $adminCreds$secUserPwd = ConvertTo-SecureString -String $pwd -Force –AsPlainTextSet-AzureADUserPassword -ObjectId $objid -Password $secUserPwdDisconnect-AzureAdOut-File -Encoding Ascii -FilePath $res -inputObject "Changed password for $objid to $pwd"
A similar approach to this could be used to segregate other admin functionality for users within an organization.
NOTE: This is a conceptual approach to solving the problem. There is a lot more rigor that can be built into this solution to make it more resilient. The point of this article is just to introduce the concept.
Originally published in Medium
Haniel Croitoru 