Azure Sentinel is a great alternative for a cloud-based SIEM hosted in Azure. Either as a detection and response solution for Azure solutions, or for detection and response in a traditional data center. One of the nice things about Sentinel is that it can easily monitor Virtual Machines, Firewalls, or PaaS components like App Services.
The negative with Azure Sentinel is that larger organizations have multiple Azure tenants and multiple Sentinel instances. Managing multiple Sentinel workspaces across multiple tenants can be challenging. And similarly, Managed Service Providers that are supporting multiple Sentinel clients have the same challenges. The other problem is that analysts need accounts in each tenant, this means multiple privileged accounts spread across tenants. This means an increased risk of account abuse or takeover.
Luckily Microsoft has given us a solution that helps simplify these problems and makes managing multiple Sentinel workspaces easier. Azure Lighthouse is a component that allows user principals in one Azure tenant to see and manage multiple Azure Sentinel workspaces in one Portal. In effect, Azure Subscription consolidates multiple subscriptions across Tenants into one single Portal. This makes Sentinel a lot more efficient for Security Operations teams.
In this article I’ll explore the Architecture of Azure Lighthouse, how to deploy Azure Lightouse in a client tenant, and how Azure Sentinel and Azure Security Center can be used with Lighthouse.
Architecture
Azure Lighthouse allows the Azure AD Security Principals in the Primary Tenant to be granted access to Subscriptions and Resources Groups in a secondary Tenant. The resources in the secondary Tenant become available in the Primary Tenant.
An Azure Resource Manager template can be executed in the secondary Tenant to grant access via Lighthouse. Several different Object Ids for resources needed to execute the ARM template. Any service within the secondary Tenant is available in the Primary tenant to be managed.
Lighthouse is benefial from an operational efficiency point of view, but helps improve the Identity and Access Management posture of the secondary Tenant because there are less privileged accounts.
Preparation
In the primary Tenant, create an Azure AD Group that will be used to grant access to the secondary tenant’s. In Azure Active Directory, navigate to Groups and create the new group, add the users that should have access to the secondary tenant.
You need to gather a number of Object Ids from Azure to use in the Template.
| Object | Description | Powershell Command |
|---|---|---|
|
Management Tenant ID |
The tenant ID of the management tenant. |
Get-AzSubscription |
|
Azure AD Group ID |
The Azure AD Group that will contain users who will be granted access to client tenants. | (Get-AzADGroup -DisplayName ‘<YourGroupName>’).id |
|
Role Definition ID |
The Id for Azure RBAC Roles to grant the Groups. | (Get-AzRoleDefinition -Name ‘Contributor’).id (Get-AzRoleDefinition -Name ‘Security Admin’).id |
Download the ARM Template from Github. You can edit the parameters in advance and populate the Object Ids, or you provide the parameters while executing the template.
Deploy the Template
In the secondary Azure portal menu, in the search box, type deploy, and then select Deploy a custom template.
Click Build your own template in the editor.
Click Load file, select the template.json file.
Click Save. Click on Basics to review the parameters.
If you did not already update the parameters in the template file, on the Parameters screen populate the Name and Description. Populate the Tenant Id and Authorizations section using the values populated above. Click Review and Create.
On the next screen review the Terms and click Create.
Once the deployment completes, it takes about 5 – 10 minutes for the Lighthouse values to show up in the Primary and Secondary Portal. Refresh the Azure Portal, and then navigate to Azure Lighthouse Service Providers. Here you can confirm the Client Subscriptions that are delegated via Lighthouse to the Service Provider.
Switch back to the Primary Tenant Portal. If you were previously logged in, refresh the page so the newly delegated Directory/Subscription shows up.
Navigate to Azure Lighthouse, Delegations. You should see the Seconery Subscription listed as Delegated.
Open Azure Sentinel Workspaces, you should see the Sentinel workspace from the Client tenant.
In Security Center you will see multiple Subscriptions that span across clients. You can centrally manage Security Posture across multiple tenants.
We can use Azure Lighthouse to securely consolidate multiple tenants and subscriptions to be managed in a single Tenant. This not only improves Security Operations efficiency, but it allows for more secure access by reducing the number of privileged accounts.
Troubleshooting
Error
{“code”:”DeploymentFailed”,”message”:”At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/DeployOperations for usage details.”,”details”:[{“code”:”InvalidPrincipalId”,”message”:”The principal object identifier ‘ee8f6d35-15f2-4252-b1b8-591358e8a244’ does not exist in the managedByTenant ‘7b816fa6-4ec3-4d24-9288-2d513a396eb7’.”}]}
Fix
Check the Principal Object Id you supplied is correct. Validate it in the Primary Tenant.