I did this, so you don’t have to 🙂 I’d read that it wasn’t possible, but had to see what happened out of interest!
IÂ tried to copy the Exchange Administrator role, by taking the existing permissions of that role and squirting them into a POSH script to create a custom role.
The result: many errors like shown stating that the action is not supported on a custom role.
Below is a copy of the script showing all of the permissions that I had to remove (note all the commented permissions lines) before being able to create the role.
On a recent project, I needed a reliable and repeatable method of creating Azure AD service principles for use with Azure DevOps and Azure Sentinel, among other things. I also needed to apply Azure roles to these service principles at different levels of the hierarchy, be that root management group, sub management group or subscription. All examples assume that the az module is already installed.
Create the service principle:
For the SP that I created for the DevOps team, I needed to give it the Owner role at the root level:
Additionally, I discovered that if you delete a SP prior to removing its roles, you end up with orphaned references in the resource level role assignments. Where these were inherited from the root level and I had no GUI visibility of that level, I had to use PowerShell to tidy up. Assuming that you don’t have a record of the ObjectID of the deleted SP, get all role assignments with:
Recently I have been looking into using Azure Service Principle objects to bypass MFA and to allow scripts, that need to connect to Azure or other services, to do so without input. Thus, I can then schedule scripted tasks to generate reports on Azure AD objects or AzureRM items.
Next, once we have the PFX certificate file, we can create the Azure App Registration, using PowerShell:
Then (optionally), if the script that you want to automate will be reading AzureRM objects, run the following script. Note that if the role assignment is to be constrained to a specific resource group, add the -ResourceGroupName switch to New-AzureRMRoleAssignment
Additionally, the RoleDefinitionName can be altered to suit.
Now we have the Service Principle in place, we can connect! But in the case of the Azure AD connection, IÂ need to first allow the application to Read AAD:
Go to the App Registrations blade in Azure AD, pick the application created earlier, then select settings. Select Required Permissions, add Azure AD and add the permissions shown in the following image:
Now lets connect using the certificate thumbprint:
By installing the certificate in the CurrentUser store, only that user can consume the certificate thumbprint for authentication using this method. Lovely.. 🙂
Why is this method secure?
You can only access the application to sign in if you have installed the certificate on the machine that you want to run the script from.
To install the certificate, you must know the password that was set on the private key during PFX creation.
No AAD user object is created
No plain text passwords need to be stored
To sign in using this method, you must know:
The AAD Tenant GUID
The Application GUID of the configured application
The specific thumbprint of the certificate, used to make the connection
The certificate and private key must be installed on the machine on which the connection attempt is being made.
Below is a copy of the script showing all of the permissions that I had to remove (note all the commented permissions lines) before being able to create the role.