Administrative Units no Entra ID: Delegação Fina e Restricted Mgmt

Num AD on-premises, delegar a quem só mexe nos utilizadores da sua região resolve-se com OUs e delegação de controlo. No Entra ID, o plano de dados é flat — todos os administradores com papéis tenant-scope veem tudo — e é aqui que as Administrative Units (AUs) entram: um container que restringe o alcance de um papel a um subconjunto de utilizadores, grupos ou dispositivos.

Uma AU comporta utilizadores, grupos ou dispositivos — incluindo Microsoft 365 groups, mail-enabled security e distribution groups — e pode ter membros estáticos ou membros dinâmicos por regra (ex.: user.country -eq 'United States'). Atribuir um papel dentro de uma AU é o equivalente cloud a “Helpdesk que só gere o norte”: o ângulo PME mais comum é dar reset de passwords ao helpdesk sem lhe abrir a porta a todo o tenant.

O que uma AU resolve — e o que não resolve

Sem AU, o papel é tenant inteiro: um User Administrator vê e gere cada utilizador do domínio. Com AU, o papel com scope fica confinado aos membros do container:

• Delegar Helpdesk Administrator aos especialistas regionais, que só tocam nos utilizadores da sua região.
• Separar a administração por divisões (universidade com escolas autónomas, grupos empresariais) sem replicar tenants.
• Membros dinâmicos: a AU povoa-se sozinha pela regra, e os papéis atribuídos acompanham.

O que não faz: uma AU não é uma OU — não aplica GPOs nem filtra políticas. É scope de gestão: corta as permissões de escrita, não a visibilidade — um administrador com scope de AU continua a listar utilizadores fora da AU no Entra admin center e no PowerShell (só o centro de administração do Microsoft 365 filtra os utilizadores fora do scope). Grupos adicionados a uma AU trazem o grupo para dentro do scope, não os seus membros: um User Administrator consegue gerir o nome e a membership do grupo, mas reset password a um membro individual do grupo não — o utilizador teria de estar na AU por si.

Restrições de estrutura: AUs não se aninham, os membros podem estar em múltiplas AUs em simultâneo, e a gestão destas unidades ainda não está disponível na aplicação Entra ID Governance do portal — os papéis com scope de AU atribuem-se no Entra admin center.

⚠️ Atenção: licenciamento. Membros e administradores de AUs com membership dinâmica requerem Microsoft Entra ID P1 ou P2. A criação e gestão exige a role Privileged Role Administrator.

Membros dinâmicos

A regra dinâmica evita a gestão manual da lista de membros — a AU segue o atributo e actualiza-se sozinha:

Connect-MgGraph -Scopes "AdministrativeUnit.ReadWrite.All"

$params = @{
    displayName = "AU Portugal"
    description = "Utilizadores do país Portugal"
    membershipType = "Dynamic"
    membershipRule = "(user.country -eq 'Portugal')"
    membershipRuleProcessingState = "On"
}
New-MgDirectoryAdministrativeUnit -BodyParameter $params

MembershipRuleProcessingState controla o motor: On processa a regra, Paused congela. As regras usam a mesma sintaxe das dynamic membership groups. AUs dinâmicas para grupos não estão suportadas — o dinâmico cobre utilizadores ou dispositivos — users ou devices, nunca os dois na mesma AU — e não suporta grupos (e é nos utilizadores que a delegação interessa).

Restricted Management Administrative Units

A AU clássica dá permissões a um subconjunto. A Restricted Management Administrative Unit (RMU) faz o contrário: bloqueia todos os administradores com papéis tenant-scope de tocar nos objectos dentro dela — incluindo Global Administrators — salvo quem tem um papel atribuído explicitamente com scope na RMU.

O caso de uso canónico é protecção de executivos: as contas C-level entram numa RMU e só os dois admins de confiança, com papéis scoped a essa RMU, fazem reset de passwords ou leem chaves BitLocker. Um Helpdesk Administrator tenant-wide deixa de conseguir nem sequer tocar no objecto. E um Global Administrator que queira mexer tem de atribuir-se explicitamente um papel com scope na RMU — acção que fica nos audit logs.

O que fica bloqueado

Para quem não tem atribuição explícita na RMU:

A leitura continua livre, e operações em serviços adjacentes (Exchange, Intune, SharePoint) não são bloqueadas — a RMU protege as propriedades de objecto do Entra, não todas as superfícies do M365.

O que pode ser membro

Utilizadores, dispositivos e security groups podem. Microsoft 365 groups, mail-enabled security e distribution groups não — o mecanismo só cobre os tipos de objecto geridos nos papéis com scope de AU.

Limites e efeitos secundários

• A marca de restricted aplica-se na criação e é irreversível — uma AU normal não “promove-se” a RMU: recria-se.
• Máximo de 100 RMUs por tenant. Ao apagar uma RMU, as protecções dos ex-membros podem demorar até 30 minutos a cair.
• Grupos e utilizadores dentro de uma RMU deixam de ser geríveis por PIM, Entitlement management, Lifecycle Workflows e Access Reviews — um efeito colateral que apanha quem já usa a Governance suite (os workflows de offboarding não conseguem apagar uma conta que esteja numa RMU).
• Group owners perdem a gestão dos seus grupos na RMU — em role-assignable groups a membership só pode ser alterada por Global ou Privileged Role Administrators.
• Apps (permissões de aplicação do Graph) também ficam bloqueadas por omissão — para automatizar contra objectos numa RMU, a app precisa de um papel Entra atribuído com scope na RMU.
• A RMU exige Entra ID P1 para cada administrador da unidade e Entra ID Free para os membros.

Delegar o helpdesk: receita PME

O cenário prometido no início — reset de passwords só para o helpdesk, sem papéis transversais:

1. Criar uma AU com os utilizadores que o helpdesk gere (membershipType = Dynamic por departamento ou país).
2. Entra ID > Roles & admins > Admin units → escolher a AU → Roles and administrators no menu lateral → papel Helpdesk Administrator → Add assignments → os membros do helpdesk.
3. Os resets de password dos utilizadores fora da AU deixam de estar ao alcance do helpdesk — o scope corta o resto do tenant.
4. Para blindar contas sensíveis (ex.: os executivos da empresa), criar uma RMU separada com esses utilizadores e atribuir lá, com scope, a quem de confiança gere.

⚠️ Atenção: uma RMU sobre uma conta Global Administrator pode deixá-la sem ninguém que lhe faça reset de password — não há papel com scope de AU que reset passwords de um GA. Se ficar bloqueada, só outro Global Administrator ou Privileged Role Administrator resolve o impasse, removendo-a primeiro da RMU.

O rasto de auditoria cobre a gestão da própria RMU: criação (IsMemberManagementRestricted = true), adicionar/remover membros e atribuir/remover papéis com scope sobre a RMU ficam nos audit logs do Entra — e a mensagem que os admins não autorizados levam ao tocar num objecto protegido é explícita: “Management rights are limited to administrators scoped on that administrative unit”.

Artigos Relacionados

• Dia 2: Entra ID — Identidade, Utilizadores e Grupos
• Identity Governance e Risk Management no Entra ID: Boas Práticas Microsoft para PME em 2026

Fontes oficiais

• Restricted management administrative units in Microsoft Entra ID — Microsoft Learn
• Administrative units in Microsoft Entra ID — Microsoft Learn
• Add or create an administrative unit with rules for dynamic membership groups — Microsoft Learn