Are you keen on automating tasks in Azure AD but concerned about the security risks associated with storing passwords in your script files? Fret not! You have the power to craft PowerShell scripts with delegated permissions to Azure AD, eliminating the need to store sensitive service account passwords within the file. Let’s delve into the world of secure automation and enhance your Azure AD experience.
This article from Microsoft describes creating an Enterprise Application with PowerShell and a Self Signed certificate for authentication. I will show you how to recreate this application within the Entra Portal.
For the purpose of this turtorial the terms “Enterprise Application”, “Application” and “Service Principal” are interchangable.
Register an Application
Firstly head over to Entra ID App Registrations page, click on “+ New registration” or “Register an application”
Give the application a name, in my case “PowerShell”, and choose which users should be able to access the application, then click “Register”
You will be presented with the App Registration page for your newly created Application. Take note of the Application (Client) ID and Directory (Tenant) ID. Then click on “Certificates & secrets”.
This page allows us to upload a public key to our application, which then allows us to authenticate with the corresponding certificate. You can generate the certificate in any way but it should be a Base64 encoded public key, the private key should not be uploaded.
Upload a Public Key
One way of generating the certificate is to use the ‘New-SelfSignedCertificate’ cmdlet to generate a Self Signed certificate, instructions for this are on the Microsoft site linked above, but the code is below too.
|
1 2 3 4 5 |
$pwd = "<password>" $notAfter = (Get-Date).AddMonths(6) # Valid for 6 months $thumb = (New-SelfSignedCertificate -DnsName "your.dns.name" -CertStoreLocation "cert:\LocalMachine\My" -KeyExportPolicy Exportable -Provider "Microsoft Enhanced RSA and AES Cryptographic Provider" -NotAfter $notAfter).Thumbprint $pwd = ConvertTo-SecureString -String $pwd -Force -AsPlainText Export-PfxCertificate -cert "cert:\localmachine\my\$thumb" -FilePath c:\temp\examplecert.pfx -Password $pwd |
After you create the certificate you will need to split out the public key into its own file, you can do this by using Openssl.exe, if you have git installed openssl exists in the bin folder, located “C:\Program Files\Git\usr\bin\openssl.exe” and the command to split out the public key is:
|
1 |
openssl pkcs12 -in "C:\temp\examplecert.pfx" -nokeys -out "public.pem" |
After you have split the public key you can then upload this to Azure/Entra by clicking the certificates menu item, and then “upload certificate”.
The certificate will be installed on your local machine now, you can check certlm.msc to find it. And then we can connect to Azure AD using the installed certificate thumbprint with the following code:
|
1 2 3 4 5 6 |
$TenantID = "The Tenant ID you noted earlier" $ApplicationID = "The application ID you noted earlier" $ThumbPrint = (Get-ChildItem Cert:\LocalMachine\My | ? {$_.Subject -eq "CN=your.dns.name"}).Thumbprint Connect-AzureAD -ApplicationId $ApplicationID -TenantId $TenantID -CertificateThumbprint $ThumbPrint |
Assign Roles
At this point you will have connected to Azure AD/Entra but your application wont have any permissions on the directory. You will need to add the application to a role to grant it permission in the directory. For example if we want the application to have read access to our entire tenancy we could assign it the “Global Reader” role. To do this head to Entra > Roles and administrators > find the role you are after and open it then click “+ Add assignments”, search for the name of your application, select it, and click “Add”
After you’ve added the role you can then successfully run a cmdlet (yes i only have one user in my tenancy, yes I only set it up for this tutorial!)
Additional Considerations
So thats the basics, there are a few things to note regarding this procedure though. The certificate is installed as exportable, you should consider deleting the certificate from the local store, re-importing it and marking it as non-exportable as seen in the screenshot below. You should keep the original certificate with the private key somewhere very safe.
You should also consider using a certificate signed by a trusted CA rather than a self signed cert.
Be restrictive with your role delegation, grant the service principal access to only what is required to do the task, dont just whack it in Global Admins, more info on roles here.
The Azure AD module is being deprecated and will be replaced by the MgGraph module, however the steps to connect to MgGraph are the same as detailed above.
Happy Coding!