Azure Lighthouse:
“enables cross- and multi-tenant management, allowing for higher automation, scalability, and enhanced governance across resources and tenants.”
In essence, it allows you to manage multiple ‘client’ Azure tenants from a single ‘master’ tenant. There is no cost for Azure Lighthouse and it is simple to enable. However, I would caution you to pay close attention to the permissions you assign the ‘master’ tenant inside the ‘client’ tenants and follow the best practice of least privilege security.
You are going to need a few things before you start configuring Azure Lighthouse.
1. A ‘master’ Azure tenant with a paid subscription
2. ‘Client’ Azure tenants with a paid subscription in each
3. For each ‘client’ Azure tenant you will require a login to that tenant who has the Owner built-in role for the subscription being onboarded. Typically, there is only one subscription in an Azure tenant and the initial administrator has that role. You will use this user, inside each ‘client’ tenant to permit access from the ‘master’ tenant.
4. The Tenant ID of the ‘master’ tenant.
You will find that on the front page of the Azure Active Directory blade in the ‘master’ Azure tenant portal as shown above.
5. The Object ID for the controlling entity (user or group) in the ‘master’ Azure tenant. This is basically the individual user or Azure AD security group who you wish to give access rights to the ‘client’ Azure tenants.
You will find the Object ID on the front page of that item in Azure AD as shown above. The above example show this for a single user.
The above example is for a group.
6. You now need to deicide what permissions you will give this Object ID from the ‘master’ Azure tenant inside the ‘client’ tenants. You can find all the Ids for Azure built-in roles here:
https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles
So, if you want for the ‘master’ tenant Object ID to have effectively full rights inside the ‘client’ Azure tenants use:
Contributor – ID = b24988ac-6180-42a0-ab88-20f7382dd24c
Remember, best practice is to follow least privilege and as such if you just want to view Azure Sentinel information in the ‘client’ Azure tenant use:
Azure Sentinel Reader – ID = 8d289c81-5878-46d4-8554-54e1e3d8b5cb
but as I said, be very, very careful about the rights you assign the ‘master’ Object ID inside the ‘client’ tenants.
Once you have all the above information, you’ll need to login to the ‘client’ Azure tenant with the user account in step 3 above (i.e. an owner of the ‘client’ Azure tenant).
In the same browser session open a new tab and navigate to:
https://github.com/Azure/Azure-Lighthouse-samples/
and select the Auto-deployment button in the first row as shown:
A custom deployment template should launch
and look like the above. Here, select the Subscription and Region appropriate in the ‘client’ Azure tenant. You can put any custom text you wish into the Msp Offer Name and Msp Offer Description field.
Into the Managed by Tenant Id field enter the value you recorded in step 4 above (i.e. the Tenant ID of the ‘master’ Azure subscription).
The Authorizations field needs to be in the format of:
[{“principalId”:”ee8f6d35-15f2-4252-b1b8-591358e8a244″,”roleDefinitionId”:”acdd72a7-3385-48ef-bd42-f606fba81ae7″,”principalIdDisplayName”:”PIM_Group”},{“principalId”:”ee8f6d35-15f2-4252-b1b8-591358e8a244″,”roleDefinitionId”:”91c1777a-f3dc-4fae-b103-61d183457e46″,”principalIdDisplayName”:”PIM_Group”}]
where the principalId field will be the item you obtained in step 5 above (i.e. who in the ‘master’ Azure tenant do you want to have rights to the ‘client’ Azure tenant) and roleDefinitionId will be the information obtained in step 6 above (i.e. what permissions you want to gibe inside the ‘client’ Azure tenant). You can assign the principalIdDisplayName field any meaningful text you wish.
As you can see from the example you can chain multiple permission assignments together. So in this example, let’s say that I want to assign my one user full contributor rights and a security group only Azure reader rights. The entry would then look like:
[{“principalId”:”b75e7296-a058-4000-0000-000000000000″,”roleDefinitionId”:”b24988ac-6180-42a0-ab88-20f7382dd24c”,”principalIdDisplayName”:”User_contributor”},{“principalId”:”8d3a5c5a-0d1e-4639-0000-000000000000″,”roleDefinitionId”:”8d289c81-5878-46d4-8554-54e1e3d8b5cb”,”principalIdDisplayName”:”Group_Sentinel_reader”}]
It is very, very important that you get the formatting of the Authorizations field correct. I suggest you compose it in something like Notepad (with word wrap = off) and paste it in. If you see any errors during deployment, double check you have this field EXACTLY correct!
Once you have entered all the information, select the Review + create button an the bottom of the screen.
Your options will then be validated, and if passed, select the Create button at the bottom of the screen.
You should then see the deployment commence as shown above. The deployment will take a few minutes to complete, after which it take at least another 15 minutes for the Azure Lighthouse configurations to appear in the ‘master’ and ‘client’ tenants, so be patient.
After the 15 minutes, navigate to Azure Lighthouse in the ‘client’ tenant and look at Service Provider offer as seen above. This basically tells you that this ‘client’ tenant has single delegation (i.e connect to a ‘master’ Azure tenant).
Now head over to the ‘master’ Azure tenant and view Azure Lighthouse there, but look at the My customers then Customers option as seen above. Here you should see the ‘client’ Azure tenant just added to the current ‘master’ Azure tenant. Again remember, this takes around 15 minutes to appear once configured.
Congratulation you have successfully used Azure Lighthouse to link a ‘client’ Azure tenant to a ‘master Azure tenant. Look out for upcoming articles on what you can now do once you have enabled Azure Lighthouse.
CIAOPS 