Fundamentação Teórica: Create users and groups
1. Intuição Inicial
Imagine uma empresa com centenas de funcionários. Cada pessoa precisa acessar sistemas diferentes: alguns precisam ler relatórios, outros precisam criar máquinas virtuais, outros precisam apenas visualizar faturas. Sem uma forma organizada de controlar quem é quem e o que cada um pode fazer, a segurança e a operação se tornam inviáveis.
No Microsoft Azure, o Microsoft Entra ID (anteriormente chamado de Azure Active Directory, ou Azure AD) é o serviço que resolve exatamente esse problema. Ele é o diretório de identidades da nuvem Microsoft: o lugar onde você registra quem são as pessoas, as organiza em grupos e define o que cada uma pode acessar.
Um usuário no Entra ID representa uma identidade individual. Pode ser uma pessoa real (um funcionário), mas também pode ser uma conta de serviço usada por uma aplicação. Um grupo é uma coleção de usuários (e potencialmente outros grupos) tratada como uma unidade, o que permite atribuir permissões e políticas de forma coletiva em vez de individualmente.
A lógica central é simples: em vez de dizer "o João pode acessar a VM-Producao", você diz "o grupo Desenvolvedores pode acessar a VM-Producao" e então adiciona o João ao grupo. Quando um desenvolvedor novo entra na empresa, basta adicioná-lo ao grupo. Quando sai, basta removê-lo. As permissões não precisam mudar.
2. Contexto
O Entra ID ocupa uma posição central no ecossistema Azure. Praticamente todo recurso, serviço e política depende dele para saber quem está agindo e o que essa entidade tem permissão de fazer.
O Entra ID é o provedor de identidade para:
- O portal do Azure e todos os serviços Azure
- Microsoft 365 (Teams, Exchange, SharePoint)
- Aplicações SaaS externas via SSO (Single Sign-On)
- Aplicações próprias da sua organização
Isso significa que aprender a criar e gerenciar usuários e grupos no Entra ID não é apenas sobre o AZ-104: é sobre controlar o acesso a praticamente tudo no ecossistema Microsoft.
3. Construção dos Conceitos
3.1 O Tenant
Antes de falar em usuários e grupos, é preciso entender o tenant (locatário). Quando uma organização assina o Azure ou o Microsoft 365, o Azure cria automaticamente um tenant dedicado a ela. O tenant é uma instância isolada do Entra ID que pertence exclusivamente àquela organização.
Cada tenant tem um nome de domínio padrão no formato nomeorganizacao.onmicrosoft.com. É possível adicionar domínios personalizados, como contoso.com, para que os usuários tenham endereços mais amigáveis.
O tenant é o contêiner de tudo: todos os usuários, grupos, aplicações e configurações de segurança vivem dentro de um tenant específico.
3.2 Tipos de Usuários
Nem todos os usuários no Entra ID são iguais. Existem três categorias principais:
| Tipo | Descrição | Exemplo de uso |
|---|---|---|
| Membro (Member) | Usuário criado diretamente no tenant. Tem acesso padrão ao diretório. | Funcionário da empresa |
| Convidado (Guest) | Usuário de fora do tenant, convidado para colaborar. Acesso ao diretório é restrito por padrão. | Parceiro externo, consultor |
| Sincronizado | Usuário originado do Active Directory on-premises, sincronizado via Azure AD Connect / Entra Connect. Não é criado diretamente no Azure. | Funcionário em ambiente híbrido |
A diferença entre membro e convidado vai além do nome. Usuários membros, por padrão, podem ler informações de outros usuários e grupos no diretório. Usuários convidados têm permissões de leitura muito mais restritas, o que é uma medida de segurança para parceiros externos.
3.3 Propriedades Essenciais de um Usuário
Ao criar um usuário, as propriedades mais importantes são:
- User Principal Name (UPN): o identificador único do usuário no formato
usuario@dominio.com. Funciona como o "login" principal. Exemplo:joao.silva@contoso.com. - Display Name: o nome que aparece na interface. Exemplo: "João Silva".
- Password: definida no momento da criação. Pode ser gerada automaticamente ou definida manualmente. O usuário pode ser obrigado a alterá-la no primeiro acesso.
- Usage Location: o país de localização do usuário. Este campo é obrigatório para atribuir licenças do Microsoft 365, pois alguns serviços não estão disponíveis em todos os países.
- Job Title, Department, Manager: metadados organizacionais. Não controlam acesso, mas são usados para organização, filtros e relatórios.
3.4 Tipos de Grupos
Existem dois tipos de grupo no Entra ID, e a distinção é fundamental:
| Tipo | Para que serve | Onde é usado |
|---|---|---|
| Security Group | Controlar acesso a recursos, atribuir permissões, aplicar políticas | RBAC no Azure, políticas de acesso condicional, acesso a aplicações |
| Microsoft 365 Group | Colaboração entre pessoas | Exchange (caixa de e-mail compartilhada), SharePoint, Teams, Planner |
Para o AZ-104 e para o controle de acesso a recursos Azure, o tipo relevante é o Security Group. O Microsoft 365 Group é mais relevante para cenários de produtividade e colaboração.
3.5 Tipos de Associação a Grupos
Esta é uma das distinções mais importantes para o exame e para a operação do dia a dia:
| Tipo de Associação | Como funciona | Licença necessária |
|---|---|---|
| Assigned (Atribuído) | O administrador adiciona e remove manualmente cada membro | Gratuito (Entra ID Free) |
| Dynamic User (Dinâmico - Usuário) | Membros são adicionados/removidos automaticamente com base em atributos do usuário | Entra ID P1 ou P2 |
| Dynamic Device (Dinâmico - Dispositivo) | Membros são dispositivos, adicionados automaticamente com base em atributos do dispositivo | Entra ID P1 ou P2 |
O grupo dinâmico é extremamente poderoso. Você define uma regra de associação (membership rule) como:
user.department -eq "Engenharia"
A partir desse momento, qualquer usuário cujo atributo department seja "Engenharia" entra automaticamente no grupo. Quando alguém muda de departamento, sai automaticamente. O administrador não precisa fazer nada manualmente.
Outro exemplo de regra:
user.jobTitle -contains "Desenvolvedor" -and user.accountEnabled -eq true
Esta regra adiciona ao grupo apenas usuários com "Desenvolvedor" no título do cargo e com a conta ativa.
3.6 Grupos Aninhados (Nested Groups)
O Entra ID permite que um grupo seja membro de outro grupo. Isso se chama nested groups ou grupos aninhados.
Ponto de atenção: a herança de permissões via grupos aninhados funciona para RBAC no Azure, mas não funciona para todas as funcionalidades. Por exemplo, ao atribuir licenças do Microsoft 365 baseadas em grupo, grupos aninhados não são suportados; somente membros diretos recebem a licença.
4. Visão Estrutural
O fluxo geral de acesso funciona assim:
- Um usuário é criado ou sincronizado no Entra ID
- O usuário é adicionado a um ou mais grupos
- Os grupos recebem papéis RBAC (como "Contributor" ou "Reader") sobre recursos Azure
- O usuário herda as permissões dos grupos dos quais faz parte
5. Funcionamento na Prática
Ciclo de vida de um usuário
Ponto crítico: quando um usuário é excluído, ele fica na "lixeira" do Entra ID por 30 dias. Durante esse período, é possível restaurá-lo com todos os seus atributos, associações a grupos e atribuições de papel. Após 30 dias, a exclusão se torna permanente.
Comportamentos importantes
-
Desabilitar vs. Excluir: desabilitar uma conta (
accountEnabled: false) bloqueia o login imediatamente, mas preserva o usuário e todas as suas associações. É a prática recomendada quando um funcionário sai temporariamente ou quando se quer bloquear acesso sem perder o registro. -
Reset de senha: administradores com o papel de "User Administrator" ou superior podem redefinir senhas de outros usuários, exceto de Global Administrators (para isso, é necessário ser também Global Administrator).
-
Atribuição de licenças: licenças do Microsoft 365 podem ser atribuídas diretamente ao usuário ou via grupo (group-based licensing). A atribuição via grupo é mais escalável e é a abordagem recomendada para ambientes maiores.
6. Formas de Implementação
6.1 Portal do Azure (Interface Gráfica)
Quando usar: tarefas pontuais, aprendizado, verificação visual, criação de poucos usuários.
Caminho no portal: Microsoft Entra ID > Users > New user ou Microsoft Entra ID > Groups > New group
Vantagens:
- Visual e intuitivo
- Feedback imediato de erros de configuração
- Ideal para exploração e verificação
Limitações:
- Não escala para muitos usuários
- Não é repetível ou auditável como código
6.2 PowerShell (Microsoft Graph PowerShell SDK)
Quando usar: criação em lote, automação, scripts de provisionamento, tarefas recorrentes.
O módulo relevante é o Microsoft Graph PowerShell SDK, que substituiu o módulo AzureAD (descontinuado).
Exemplo de criação de usuário:
$PasswordProfile = @{
Password = 'TempPassword@123'
ForceChangePasswordNextSignIn = $true
}
New-MgUser `
-DisplayName "João Silva" `
-UserPrincipalName "joao.silva@contoso.com" `
-AccountEnabled `
-PasswordProfile $PasswordProfile `
-MailNickname "joao.silva" `
-UsageLocation "BR"
Exemplo de criação de grupo:
New-MgGroup `
-DisplayName "Desenvolvedores" `
-MailEnabled:$false `
-SecurityEnabled `
-MailNickname "desenvolvedores"
Exemplo de adição de membro a um grupo:
$userId = (Get-MgUser -UserId "joao.silva@contoso.com").Id
$groupId = (Get-MgGroup -Filter "displayName eq 'Desenvolvedores'").Id
New-MgGroupMember -GroupId $groupId -DirectoryObjectId $userId
Vantagens:
- Scriptável e repetível
- Ideal para provisionamento em lote
- Pode ser integrado a pipelines CI/CD
Limitações:
- Requer autenticação e permissões no Graph API
- Curva de aprendizado do SDK
6.3 Azure CLI
Quando usar: ambientes onde o PowerShell não é preferido, scripts shell em Linux/macOS, pipelines baseados em bash.
# Criar usuário
az ad user create \
--display-name "João Silva" \
--user-principal-name joao.silva@contoso.com \
--password "TempPassword@123" \
--force-change-password-next-sign-in true
# Criar grupo
az ad group create \
--display-name "Desenvolvedores" \
--mail-nickname "desenvolvedores"
# Adicionar membro ao grupo
az ad group member add \
--group "Desenvolvedores" \
--member-id <object-id-do-usuario>
Vantagens:
- Sintaxe simples e direta
- Ótimo para scripts bash e pipelines DevOps
Limitações:
- Menos expressivo que PowerShell para lógica complexa
6.4 Microsoft Graph API (REST)
Quando usar: integração de sistemas, aplicações que precisam criar ou gerenciar usuários programaticamente, automação customizada.
POST https://graph.microsoft.com/v1.0/users
Content-Type: application/json
{
"accountEnabled": true,
"displayName": "João Silva",
"mailNickname": "joao.silva",
"userPrincipalName": "joao.silva@contoso.com",
"passwordProfile": {
"forceChangePasswordNextSignIn": true,
"password": "TempPassword@123"
},
"usageLocation": "BR"
}
Vantagens:
- Qualquer linguagem de programação pode ser usada
- Máxima flexibilidade
- Base de todas as outras ferramentas (portal, CLI e PowerShell usam Graph internamente)
Limitações:
- Requer gerenciamento de tokens de autenticação
- Mais verboso para tarefas simples
6.5 Importação em Massa (Bulk Operations)
O portal do Azure permite criar usuários em massa via upload de um arquivo CSV. O caminho é: Microsoft Entra ID > Users > Bulk operations > Bulk create.
O arquivo CSV deve seguir um template específico fornecido pelo portal. Esta é uma boa opção para onboarding inicial de muitos usuários sem necessidade de escrever scripts.
7. Controle e Segurança
Papéis Administrativos Relevantes
Para criar e gerenciar usuários e grupos, o administrador precisa ter papéis adequados no Entra ID. Os principais são:
| Papel (Role) | O que pode fazer |
|---|---|
| Global Administrator | Tudo. Acesso irrestrito ao Entra ID e a todos os serviços Microsoft. |
| User Administrator | Criar, editar, excluir usuários e grupos. Resetar senhas (exceto de Global Admins). |
| Groups Administrator | Criar e gerenciar grupos, incluindo grupos dinâmicos. |
| Guest Inviter | Convidar usuários externos (guests) para o tenant. |
| Helpdesk Administrator | Resetar senhas de usuários não-administradores. |
Estes são papéis do Entra ID (directory roles), diferentes dos papéis RBAC do Azure (que controlam acesso a recursos como VMs e storage). Os dois sistemas coexistem e são complementares.
Boas Práticas de Segurança
- Princípio do menor privilégio: atribua apenas o papel mínimo necessário para cada administrador. Um helpdesk que só reseta senhas não precisa ser User Administrator completo.
- Contas administrativas separadas: administradores devem ter uma conta regular para uso do dia a dia e uma conta separada com privilégios elevados para tarefas administrativas.
- MFA obrigatório para admins: contas com papéis administrativos devem sempre ter autenticação multifator habilitada.
- Monitoramento de contas guest: usuários convidados acumulam ao longo do tempo. Revise periodicamente quais guests ainda precisam de acesso.
8. Tomada de Decisão
Qual tipo de associação de grupo usar?
| Situação | Melhor escolha | Motivo |
|---|---|---|
| Equipe pequena e estável | Assigned | Simples, sem necessidade de licença P1 |
| Muitos usuários com atributos consistentes (departamento, cargo) | Dynamic User | Automação elimina erros manuais e sobrecarga operacional |
| Precisa controlar dispositivos | Dynamic Device | Permite políticas baseadas em características do dispositivo |
| Atributos de usuário não são confiáveis ou padronizados | Assigned | Grupos dinâmicos dependem da qualidade dos dados de atributos |
Qual ferramenta usar para criar usuários?
| Situação | Melhor escolha | Motivo |
|---|---|---|
| Criar 1 a 5 usuários pontualmente | Portal Azure | Rápido e visual |
| Onboarding de 20+ usuários de uma vez | CSV Bulk Upload ou PowerShell | Escala sem esforço excessivo |
| Provisionamento automatizado e recorrente | PowerShell com Graph SDK ou Graph API | Repetível, versionável, integrável |
| Integração com sistema de RH | Graph API | Flexibilidade máxima para integração |
| Ambiente Linux/macOS ou pipeline bash | Azure CLI | Sintaxe mais natural nesses ambientes |
9. Boas Práticas
Nomenclatura consistente: defina e documente convenções de nomenclatura para UPNs e grupos antes de começar. Exemplo de padrão para UPN: primeironome.ultimonome@contoso.com. Para grupos: SG-[Função]-[Escopo], como SG-Devs-Producao.
Uso de grupos para tudo: nunca atribua permissões diretamente a usuários individuais se você puder usar grupos. Isso torna a gestão de acesso muito mais escalável e auditável.
Preencha atributos de usuário: campos como department, jobTitle e manager parecem opcionais, mas são essenciais para grupos dinâmicos, relatórios de segurança e revisões de acesso. Invista em qualidade de dados desde o início.
Defina Usage Location sempre: é fácil esquecer esse campo, mas ele bloqueia a atribuição de licenças Microsoft 365. Configure-o no momento da criação.
Grupos de segurança vs. M365 Groups: não misture os propósitos. Use Security Groups para controle de acesso. Use Microsoft 365 Groups para colaboração. Usar um M365 Group para atribuir papéis RBAC funciona tecnicamente, mas cria confusão e é uma má prática.
Revise membros de grupos regularmente: especialmente grupos com acesso privilegiado. O Entra ID oferece o recurso de Access Reviews (revisões de acesso periódicas e automatizadas) para isso.
10. Erros Comuns
Confundir papéis do Entra ID com papéis RBAC do Azure: são dois sistemas diferentes. O papel "Owner" em uma assinatura Azure não torna alguém Global Administrator do Entra ID. E ser Global Administrator não concede automaticamente acesso a recursos Azure como VMs ou Storage Accounts.
Esquecer o Usage Location ao criar usuários: o usuário é criado com sucesso, mas qualquer tentativa posterior de atribuir uma licença do Microsoft 365 falha com um erro que pode confundir quem não conhece esse requisito.
Depender de grupos aninhados para licenciamento: como mencionado, o licenciamento baseado em grupo não propaga para membros de grupos aninhados. Só membros diretos recebem a licença. Administradores criam hierarquias de grupos achando que a herança funcionará, e ficam com usuários sem licença.
Criar grupos dinâmicos com atributos incorretos ou mal formatados: uma regra mal escrita pode incluir usuários incorretos ou não incluir ninguém. Sempre use o botão "Validate Rules" disponível na interface de criação de grupos dinâmicos para testar a regra antes de salvar.
Excluir usuários em vez de desabilitá-los: quando um funcionário sai, a tendência é excluir a conta imediatamente. O problema é que isso remove o usuário de todos os grupos e de todas as atribuições RBAC. Se houver necessidade de investigação ou auditoria futura, os rastros de acesso ficam mais difíceis de reconstruir. A melhor prática é desabilitar a conta primeiro, aguardar o período de retenção necessário e só então excluir.
Não configurar senha temporária adequadamente: ao criar um usuário com a opção "Auto-generate password" e não marcar "Require password change at first login", o usuário recebe uma senha fixa que nunca expira até que seja alterada manualmente. Sempre force a troca de senha no primeiro login.
11. Operação e Manutenção
Monitoramento e Auditoria
Toda ação de criação, modificação e exclusão de usuários e grupos gera registros no Audit Logs do Entra ID. O caminho no portal é: Microsoft Entra ID > Monitoring > Audit logs.
Os logs registram: quem fez a ação, o que foi feito, quando e em qual objeto. Esses logs são retidos por 30 dias no plano gratuito e por até 90 dias com Entra ID P1/P2. Para retenção maior, os logs devem ser exportados para um Log Analytics Workspace ou Storage Account.
O Sign-in logs (também em Monitoring) registra cada tentativa de login: sucessos, falhas, localização, dispositivo usado. É essencial para detectar acessos suspeitos.
Limites Importantes
| Item | Limite |
|---|---|
| Usuários por tenant | 300.000 (padrão, pode ser aumentado) |
| Grupos por tenant | 300.000 |
| Membros por grupo (atribuído) | Sem limite prático documentado |
| Grupos dinâmicos por tenant | 5.000 (com licença P1/P2) |
| Grupos dos quais um usuário pode ser membro | 2.048 (limite de token) |
| Objetos na lixeira | 30 dias de retenção |
O limite de 2.048 grupos por usuário é particularmente importante em ambientes grandes. Quando um usuário é membro de muitos grupos, o token de autenticação pode ficar muito grande, causando falhas em aplicações que validam membros de grupo. Esse é um problema real em organizações com arquiteturas de grupos muito granulares.
12. Integração e Automação
Sincronização com Active Directory On-Premises
Em ambientes híbridos (onde existe um Active Directory local além do Entra ID), o Microsoft Entra Connect (antigo Azure AD Connect) sincroniza usuários, grupos e atributos do AD local para o Entra ID.
Nesse cenário, os usuários sincronizados são gerenciados no AD on-premises, não diretamente no Entra ID. Qualquer alteração (nome, departamento, senha) deve ser feita no AD local e será sincronizada para o Entra ID.
Provisionamento Automatizado via SCIM
Para aplicações SaaS externas, o Entra ID suporta o protocolo SCIM (System for Cross-domain Identity Management) para provisionamento automático. Quando um usuário é adicionado a um grupo específico, o Entra ID automaticamente cria uma conta na aplicação de destino. Quando é removido, a conta é desativada.
Integração com Azure DevOps e GitHub
Security Groups do Entra ID podem ser vinculados a organizações do Azure DevOps e GitHub Enterprise, centralizando o controle de acesso a repositórios e pipelines na mesma identidade gerenciada no Entra ID.
Lifecycle Workflows
O Entra ID (com licença Governance) oferece Lifecycle Workflows: automações que executam tarefas predefinidas baseadas em eventos do ciclo de vida do usuário, como criação de conta, mudança de departamento e desligamento. Exemplo: quando um usuário é contratado (atributo employeeHireDate chega), o sistema automaticamente cria a conta, atribui ao grupo correto, atribui licenças e envia e-mail de boas-vindas.
13. Resumo Final
Conceitos essenciais:
- O Microsoft Entra ID é o serviço de identidade central do Azure. Todos os acessos passam por ele.
- Um tenant é a instância isolada do Entra ID de uma organização.
- Usuários podem ser membros (criados no tenant), convidados (externos) ou sincronizados (vindos do AD on-premises).
- O UPN é o identificador único do usuário. O Usage Location é obrigatório para atribuição de licenças.
- Grupos podem ser do tipo Security (para controle de acesso) ou Microsoft 365 (para colaboração). Para o AZ-104, o foco é em Security Groups.
- A associação a grupos pode ser Assigned (manual) ou Dynamic (automática via regras). Grupos dinâmicos requerem licença Entra ID P1 ou P2.
Diferenças críticas:
- Papéis do Entra ID controlam quem pode administrar o diretório (criar usuários, resetar senhas). Papéis RBAC do Azure controlam quem pode agir sobre recursos (criar VMs, acessar storage). São sistemas separados.
- Desabilitar uma conta bloqueia o login mas preserva o objeto. Excluir remove a conta (com janela de restauração de 30 dias).
- Grupos aninhados propagam permissões RBAC, mas não propagam licenças do Microsoft 365.
- Grupos atribuídos são gratuitos. Grupos dinâmicos exigem Entra ID P1 ou P2.
O que precisa ser lembrado:
- Sempre atribua permissões a grupos, nunca diretamente a usuários individuais.
- Grupos dinâmicos dependem da qualidade dos atributos dos usuários. Dados sujos geram grupos errados.
- Usuários excluídos ficam recuperáveis por 30 dias e auditáveis por 30 dias (90 com P1/P2).
- O limite de 2.048 grupos por usuário pode causar falhas de autenticação em ambientes muito granulares.
- Em ambientes híbridos, usuários sincronizados são gerenciados no AD on-premises, não no portal do Azure.