The problem
Recently, we helped a client consolidate his on-premises Active Directory and Office 365 tenant through Azure AD Connect. A significant number of accounts existed in both locations but AADC successfully completed the SMTP match and all seemed to be well, with fresh accounts being pushed into Azure AD and a couple dozen other accounts converted from cloud to AD controlled. All as expected.
Those users who were Global Admins remained so, but the admin who does significant work with the VMs (and other Azure services) could no longer see any of those resources in the Azure portal itself. Although getting locked out of everything in Azure sounded like a big problem, it turned out not to be so bad.
How we recovered
As mentioned, though the user account was still a Global Admin, he had no access to Azure. The fix was relatively straightforward, but the post-resolution clean-up was not as simple as just moving the slider bar back to where it started.
To recover access to Azure resources, the admin user logged-on to Azure AD through the Office 365 admin portal and slid the bar on his own account to the YES position (as shown below).
Once the user had the rights to see into the Azure Subscription and reassign the contributor, owner and other permissions throughout Azure, we started the permission clean-up process.
How we cleaned up
We found that simply changing the slider (shown above) back to the NO position did not undo the assignment of the User Access Administrator rights.
As an aside, since we were in the area (so to speak), we took it upon ourselves to update the workstations to put the new Azure management tools on the management workstation we happened to be using.
To do this we had to uninstall AzureRM, as per these instructions.
Once completed, we installed the new Azure Powershell:
https://docs.microsoft.com/en-us/powershell/azure/install-az-ps?view=azps-4.6.1
The command: “Install-Module -Name AZ -AllowClobber -Scope -AllUsers”
“az role assignment delete –assignee [email protected] —role “User Access Administrator” –Scope “/”
The slash at the scope level was required because Azure AD assigned the role to the root level.
That got everything back to the way the environment was configured before Azure AD Connect had done its thing.
Later
Later, we took a look to see if we’d done it all right, only to find that there’s an article that covers the process. But while it was informative, it certainly confused us as we were reviewing the steps we took versus the steps as documented. Another thing we noted was that one user who already had User Access Administrator rights could have simply reassigned the Owner and Contributor rights–had he not been on vacation at the time! For completeness, here’s a link to the article. Finally, if any Azure issues have you stumped, please feel free to reach out to us. We’d love to help you out.
Share on
