Aposentadoria do operador MemberOf de grupos dinâmicos no Entra ID: o que quebra em 3 de novembro

Aposentadoria do Operador MemberOf de Grupos Dinâmicos no Entra ID: o que é

A aposentadoria do operador de regra memberOf de grupos dinâmicos do Entra ID da Microsoft acontece em 3 de novembro de 2026 — depois dessa data, qualquer configuração que ainda o use para de ser atualizada. memberOf é um operador de regra de associação dinâmica, lançado em preview público, que permite que um grupo dinâmico, uma unidade administrativa dinâmica ou uma política de atribuição automática do entitlement management se preencha automaticamente a partir dos membros de outros grupos. Em vez de escrever regras por atributo (departamento, cargo, atributos de extensão), um administrador podia apontar um grupo dinâmico para até 50 grupos de segurança, grupos do Microsoft 365 ou grupos sincronizados do local "de origem" e fazer com que o Entra ID puxasse automaticamente seus membros diretos.

Em 5 de agosto de 2026, a Microsoft publicou a postagem MC1448379 no Message Center, anunciando o fim do preview do memberOf. De acordo com a documentação oficial do Microsoft Learn, após 3 de novembro de 2026, qualquer grupo de associação dinâmica, unidade administrativa dinâmica ou política de atribuição automática do entitlement management que ainda use memberOf para de ser atualizado e congela no último estado conhecido. A Microsoft enquadra isso como uma limitação de escala e confiabilidade, não como uma correção de segurança — mas o impacto operacional atinge as equipes de identidade da mesma forma que um bug atingiria: silenciosamente e com prazo. É o mesmo padrão "calmo na superfície, quebrado por baixo" que já cobrimos quando um certificado de assinatura SAML expirado do Entra derrubou o login federado em todo o tenant: o gatilho é uma mudança do lado da Microsoft, mas o raio de impacto depende inteiramente de você ter rastreado sua própria configuração.

Como funciona — e por que a Microsoft está aposentando o recurso

Uma regra memberOf é escrita na sintaxe de regra avançada de grupo dinâmico do Entra (não é suportada na interface do construtor de regras — apenas no editor de regras bruto):

user.memberof -any (group.objectId -in ['<sourceGroupObjectId>'])

ou, para grupos dinâmicos baseados em dispositivo:

device.memberof -any (group.objectId -in ['<sourceGroupObjectId>'])

Vários grupos de origem podem ser listados na mesma regra (-in ['<groupId1>', '<groupId2>']), e o grupo dinâmico resultante pode ser usado para atribuição de aplicativos, direcionamento de Conditional Access ou licenciamento baseado em grupo — em qualquer lugar em que um grupo normal funcione.

Segundo as próprias limitações de preview da Microsoft, o recurso sempre foi escopado de forma rígida: um limite de 500 grupos dinâmicos usando memberOf por tenant (contado contra a cota geral de 15.000 grupos dinâmicos), um limite de 50 grupos de origem por regra, apenas membros diretos (sem aninhamento transitivo — membros de um grupo aninhado dentro de um grupo de origem não são puxados), sem encadear um grupo dinâmico memberOf dentro de outro, e sem combinar memberOf com qualquer outra cláusula de regra. Era necessário licenciamento Microsoft Entra ID Premium P1 ou P2 e no mínimo a função User Administrator apenas para configurá-lo.

O motivo da aposentadoria, segundo a orientação de migração da Microsoft, é escala: usar memberOf "pode afetar o processamento de associação dinâmica em todo o tenant mesmo que haja apenas um operador de regra memberOf no tenant." Uma única regra podia desacelerar a avaliação de grupos dinâmicos não relacionados em todo o tenant — por isso a Microsoft afirma explicitamente que o operador "não é recomendado para uso em produção", apesar de tenants reais o terem adotado em produção durante o preview.

A Microsoft diz que "continua desenvolvendo uma solução alternativa" com escalabilidade adequada, mas não se comprometeu com um recurso substituto ou data — a orientação de migração atual aponta para operadores de regra existentes ou associação atribuída (estática), não para um substituto direto.

Detecção: encontre toda regra memberOf antes que ela congele

O risco não está na aposentadoria em si — está em não saber quais grupos dinâmicos, unidades administrativas e pacotes de acesso dependem silenciosamente de memberOf hoje. Como o operador era exclusivo do preview e nunca foi exposto na interface do construtor de regras, objetos afetados podem passar despercebidos numa revisão de console de rotina; a forma confiável de encontrá-los é uma consulta direcionada ao Microsoft Graph. Se você ainda não executa uma revisão estruturada da configuração do Entra ID, nosso guia de auditoria de segurança do Microsoft Entra ID cobre o processo de revisão mais amplo no qual essa etapa de detecção se encaixa.

Exemplo em Graph PowerShell, adaptado da orientação de migração resumida pelo office365itpros.com:

Connect-MgGraph -Scopes GroupMember.Read.All

[array]$Groups = Get-MgGroup -Filter "groupTypes/any(c:c eq 'dynamicmembership') and (startsWith(membershipRule,'user.memberOf') or startsWith(membershipRule,'device.memberOf'))" -All

Connect-MgGraph -Scopes AdministrativeUnit.Read.All

[array]$DynamicAdminUnits = Get-MgDirectoryAdministrativeUnit -Filter "membershipType eq 'Dynamic' and (startsWith(membershipRule,'user.memberOf') or startsWith(membershipRule,'device.memberOf'))" -All

$Uri = "https://graph.microsoft.com/v1.0/identityGovernance/entitlementManagement/assignmentPolicies"
$Data = Invoke-MgGraphRequest -Uri $Uri -Method Get -OutputType PsObject | Select-Object -ExpandProperty Value
$Data | Where-Object {$_.automaticRequestSettings}

A última consulta retorna todas as políticas de atribuição automática; cada resultado precisa então de uma verificação manual dos critérios de automaticRequestSettings em busca de lógica baseada em memberOf, já que a API não expõe um filtro direto para isso.

Remediação: migre antes de 3 de novembro de 2026

A própria orientação de migração da Microsoft divide isso em três frentes:

1. Grupos de associação dinâmica — Exporte os grupos dinâmicos identificados acima, substitua memberOf por um operador de regra suportado (regras baseadas em atributos de usuário ou dispositivo) onde a mesma população puder ser expressa dessa forma, ou converta o grupo para associação atribuída (estática). Valide se a associação de grupo resultante corresponde ao esperado antes de remover a regra antiga.
2. Unidades administrativas dinâmicas — Mesmo padrão: substitua a regra baseada em memberOf por lógica suportada, ou converta para associação atribuída. Como unidades administrativas delimitam permissões administrativas delegadas, valide tanto a associação resultante quanto o escopo administrativo — uma unidade administrativa ampliada é um risco de escalonamento de privilégios da mesma família da exposição permanente de Administrador Global que cobrimos em Azure Privileged Access, não apenas um grupo desatualizado.
3. Políticas de atribuição automática do entitlement management — Substitua critérios baseados em memberOf por operadores baseados em atributos suportados onde existir um equivalente. Onde não existir, a orientação da Microsoft é explícita: as equipes precisam planejar um método de atribuição alternativo antes do prazo — não há substituto equivalente garantido.

Para cada objeto que você tocar, valide os efeitos posteriores antes do prazo, não depois: atribuição de licença baseada em grupo, direcionamento de Conditional Access e acesso a Teams/SharePoint via grupos do Microsoft 365 leem todos da mesma associação que congela em 3 de novembro de 2026. Um usuário sem licença ou com licença em excesso, ou uma política de Conditional Access excluindo silenciosamente uma equipe que cresceu após o congelamento, é exatamente o tipo de lacuna que aparece semanas depois numa revisão de acesso — não no primeiro dia.

Como a EtcSec detecta isso

A EtcSec sinaliza grupos dinâmicos com regras de associação excessivamente amplas ou de alto risco por meio da verificação AZ_GROUP_DYNAMIC_RULE_BROAD, que expõe configurações de associação dinâmica — incluindo regras baseadas em memberOf — que valem a pena revisar antes que saiam do escopo ou, como neste caso, parem de ser atualizadas por completo. A EtcSec também verifica a cobertura de licenciamento Entra ID P1/P2 (AZ_NO_P2_LICENSE), já que memberOf e a maioria de seus sucessores suportados exigem licenciamento Premium para configuração e manutenção.