Cloud Levels

// Exploring IT one level at a time…

Category: Entra

  • Securing privileged access groups & roles with Entra ID Administrative Units 

    Securing privileged access groups & roles with Entra ID Administrative Units 

    Administrative Units (AUs) in Microsoft Entra ID are often associated with delegated administration and organisational segmentation.  

    In this article we will specifically discuss leveraging Administrative Units to ensure privileged access security groups are kept secure. 

    Essentially, Administrative Units can be used to control who can administer Device, User and Group objects in Entra ID. This means that the groups assigned to the AU can only be managed by users who have been assigned the appropriate role at the appropriate Administrative Unit scope. For example, a senior engineer can be granted the Group Administrator role at the Administrative Unit level, meaning only the senior engineers with the respective PIM role can elevate and then amend these privileged groups. 

    One of the primary reasons for adopting Administrative Units is to help prevent the threat of less senior administrators with broad directory permissions, such as User Administrators or Groups Administrators (at the global tenant level), from being able to elevate their own permissions by simply adding themselves to groups that are used to assign privileged roles, licenses or access rights. 

    The Challenge 

    Many organisations use security groups to assign access to: 

    • Azure subscriptions and resource groups 
    • Enterprise applications 
    • SharePoint sites 
    • Conditional Access exclusions 
    • Microsoft Entra roles through Privileged Identity Management (PIM) 
    • Administrative access to critical infrastructure 

    In a traditional Entra ID deployment, a user assigned the Groups Administrator role can manage most groups within the directory. Whilst this may be operationally convenient, it can also introduce a significant security concern. 

    Consider the following scenario: 

    1. A Groups Administrator has permission to manage all security groups. 
    1. A privileged security group exists which grants Global Administrator eligibility via PIM. 
    1. The Groups Administrator adds themselves as a member. 
    1. They activate the role and obtain elevated privileges. 

    Although auditing and monitoring may identify this activity after the fact, the privilege escalation has already occurred. 

    How Administrative Units Help 

    Administrative Units introduce an additional layer of scoping. 

    Instead of administrative roles applying across the entire directory, they can be assigned at the Administrative Unit level. The result is that administrators only gain management rights over the users, devices, or groups contained within that specific AU. 

    By placing privileged access groups into a dedicated Administrative Unit, organisations can: 

    • Restrict who can manage those groups 
    • Separate operational administration from privileged administration 
    • Reduce opportunities for privilege escalation 
    • Improve compliance and governance controls 
    • Implement stronger segregation of duties 

    The key benefit is that even if an administrator holds a directory-wide role such as User Administrator or Groups Administrator, they can be prevented from modifying sensitive groups that are protected through Administrative Unit scoping. 

    Real world example 

    Imagine an organisation has three groups which are used to assign users with highly privileged Entra ID roles: 

    • Corp-PIM-GlobalAdmins
    • Corp-PIM-ExchangeAdmins 
    • Corp-PIM-SecurityAdmins 

    Rather than allowing standard identity administrators to manage these groups, the organisation creates an Administrative Unit called: Privileged Roles and Groups 

    The three groups are added to the Administrative Unit, and only a small number of senior engineers are assigned the relevant administrative role, which is scoped specifically to that AU. 

    The outcome is simple: 

    Administrator Role / Group Able to manage standard groups Able to manage privileged groups assigned to the AU 
    Groups Administrator Yes No 
    User Administrator Yes No 
    Senior Engineer (assigned to the AU) Yes Yes 

    This creates clear separation between day-to-day administration and privileged access management. 

    Whilst security is often the primary driver, Administrative Units also deliver several governance benefits. 

    Benefits Beyond Security 

    Improved separation: Many regulatory frameworks require a separation between those who manage user accounts and those who approve or grant privileged access. Administrative Units make this easier to implement by providing clear administrative boundaries. 

    Reduces administrative risk: Mistakes happen. Restricting access to these high-impact groups reduces the likelihood of accidental membership changes that could affect production systems or critical services. 

    Better auditing: When privileged groups are isolated within a dedicated Administrative Unit, it becomes significantly easier to identify who has administrative responsibility and who is authorised to make changes. 

    Delegation becomes more scalable: as environments grow, organisations often need to delegate administration without exposing sensitive resources. Administrative Units enable a more scalable model where permissions can be delegated safely without granting excessive directory-wide rights. 

    Final thoughts and considerations 

    Before implementing this approach, there are a few key considerations: 

    • Administrative Units should be part of a wider privileged access strategy rather than a standalone control. 
    • Privileged Identity Management (PIM) should still be used wherever possible for role activation and approval workflows. 
    • Regular Access reviews should be implemented for privileged groups. 
    • Administrative Unit role assignments should be regularly reviewed and monitored. 
    • Breakglass and emergency access accounts should remain appropriately governed. 

    Administrative Units are frequently overlooked when discussing Microsoft Entra ID security controls, yet they can play a critical role in protecting privileged access paths. 

    By placing privileged security groups within dedicated Administrative Units and tightly controlling who can administer them, organisations can significantly reduce the risk of privilege escalation, improve separation of duties, and strengthen their overall identity governance posture. 

    As more organisations move towards role-based access control and Zero Trust principles, Administrative Units provide another valuable mechanism for ensuring that administrative permissions are granted only where they are genuinely required, and nowhere else. 

    Tip: If you’re already using Privileged Identity Management to govern your Entra roles, review the security groups that underpin those assignments. Protecting the groups themselves is just as important as protecting the roles they grant. 

    Hope this helps and thanks for reading!

  • Configuring Microsoft Entra ID tenants in a hybrid identity model with multiple AD DS forests

    Configuring Microsoft Entra ID tenants in a hybrid identity model with multiple AD DS forests

    Overview

    An interesting challenge came my way recently, for a global firm with locations in 15 different countries, who were going through an exciting period of growth and acquisition.

    This article is going to talk about the challenge I faced with regards to the businesses hybrid identity requirements.

    But first I’d like to provide a bit of background to the project.

    The first stage of the project was to merge two separate firms and all of their offices based in the UK from an IT infrastructure perspective. This included on-premises identity, on-premise servers, cloud resources & networking.

    Both firms had different specialities however once merged these two firms would become the global firms UK division.

    The second stage of the project was to bring the UK division into the global businesses Microsoft Azure infrastructure & Microsoft Entra ID tenant. This included converting every user into a hybrid identity so they could authenticate to on-premise and cloud resources with one identity. Provide a zero touch build process for every end-user compute (EUC) device by leveraging Intune (MDM) & Autopilot.

    Due to the nature of the global business, my remit was only in relation to the UK division, divisions located outside of the UK are managed by their own respective IT teams. Therefore, the solution implemented had to only affect the UK division, whilst allowing other divisions to replicate this behaviour and functionality during their onboarding transformation projects in the future.

    The challenge

    How to use a hybrid identity model for a specific on-premises Active Directory Domain Services (AD DS) forest, with a Microsoft Entra ID tenant which in future will require other independent AD DS forests to also implement a hybrid identity model, all whilst not having any trusts or connectivity between these independent AD DS forests.

    Over the years the Entra ID Connect sync service, installed on a Windows Server, has generally been the go to option for hybrid identity sync between AD DS and Entra ID.

    However, Entra ID has a limitation whereby it cannot connect to and use multiple Entra ID Connect servers.

    Which meant this was not a suitable option in this scenario due to the lack of connectivity and trusts between AD DS forests across the globe.

    The solution

    Microsoft Entra ID Connect cloud sync.

    The primary difference between the Entra ID Connect Cloud Sync service and an on-premises Entra ID Connect server is the sync engine is offloaded to the cloud.

    This method suited this scenario perfectly as it supports multiple forests without the need for line of sight connectivity and trusts between the individual ADDS forests.

    To be able to sync to Entra ID with Entra ID Connect cloud sync, a light weight Entra ID Connect Cloud sync agent is required, this needs to be installed onto a domain member server within each forest.

    The Entra ID Connect Cloud sync service is more limited when compared to the traditional Entra ID Connect service.

    Although in my opinion the main features expected are all there and fully functional. For example the Entra ID Connect cloud sync service still allows you to have a two-way sync (AD to Entra ID and Entra ID to AD) which provides you with password writeback functionality. Entra ID Connect cloud sync also provides OU filtering allowing you to control which objects are synced from AD DS.

    For reference, if you require users to be able to change their AD DS passwords from the cloud, each user will require a Microsoft Entra ID P2 license so they are able to change their password via Microsoft’s self-service password reset solution.

    You can find the Entra ID Connect cloud sync agent installer within the Entra ID portal.

    Firstly, login to Entra ID portal (entra.microsoft.com).

    Secondly, open the ‘Entra Connect’ blade:

    Thirdly, open the ‘cloud sync’ blade:

    Fourth, select ‘New configuration’ under the Configurations blade, then select the ‘AD to Microsoft Entra ID sync’ sync direction:

    Finally, select ‘click here’ next to ‘For a list of active agents’, which will open a new menu where you can use the download option to get a copy of the agent installer:

    Further information on how to install an Entra ID Connect Cloud Sync agent is available here: https://learn.microsoft.com/en-us/entra/identity/hybrid/install

    Hope this helps and thanks for reading!

  • How to delete a Microsoft Entra ID tenant & caveats

    How to delete a Microsoft Entra ID tenant & caveats

    Article overview

    Hello and thank you for reading my first post!

    I have put this post together to outline some additional steps that I had to recently complete to successfully delete an Azure / Entra ID tenant. This situation arose following an acquisition which meant the tenant in question was redundant after the existing resources were migrated.

    I personally found that the additional steps required, were not mentioned in Microsoft Learn articles at the time, which under normal circumstances would successfully guide you through the deletion process successfully.

    For reference, one of the resources I am referring to can be found here: https://learn.microsoft.com/en-us/entra/identity/users/directory-delete-howto.

    Microsoft Entra ID tenant deletion prerequisites

    Before being able to proceed to delete an Entra tenant, you will need to complete (as outlined in the above guide) all of the pre-requisites, once complete they should all have a green status as shown in the below screenshot:

    This status page is available in the Entra Admin Centre (entra.microsoft.com).

    To note, for the License-based subscriptions status to pass, it took around 120 days, this was due to the licenses in my tenant being provided by a third-party reseller. Please note, licenses provided by a reseller take longer to move through each stage of decommissioning, before being removed from the tenant. This lengthy license decommissioning process essentially acts as a back stop, allowing plenty of time before any data is purged for the licenses to be re-added if needed, and in turn recovering the licensed features and data in an event of any licenses being removed by mistake.

    The blocker: Legacy Microsoft Partnerships

    However, although the pre-requisites passed as shown above, I still could not delete the tenant in question. I kept receiving the below error suggesting it was due to left-over Enterprise Applications:

    There were no Enterprise Applications left-over, the only ones I could find via Microsoft Graph were ‘Microsoft Internal’ Enterprise Applications, but due to the error message I still ended up spending a chunk of time trying to remove these as per the guidance found here: https://learn.microsoft.com/en-gb/entra/identity/users/directory-delete-howto#remove-enterprise-apps-that-you-cant-delete. However, this did not achieve anything as it turns out deleting ‘Microsoft Internal’ Enterprise Applications has been blocked by Microsoft (naturally).

    In the end I conceded and ended up raising a ticket with Microsoft Azure support.

    To my surprise I was advised that the problem stopping me from deleting the tenant, was simply due to some legacy Microsoft partnership relationships still being registered to the tenant, despite licenses being fully deleted at this stage and the error message above suggesting otherwise.

    So I got in touch with the three Microsoft partners and distributors in question and requested they removed the partner relationship. Once they had been successfully removed, a few days later the Entra tenant was able to be deleted successfully.

    Summary

    So if you’re ever in a similar situation and can’t delete an Entra tenant, I would certainly recommend you check to see if there are any legacy relationships left over, you can check these here: Microsoft 365 Admin Centre -> Settings -> Partner Relationships (https://admin.microsoft.com/#/partners).

    Hope this helps and thanks for reading!