Precisa adicionar um campo “Gender” ao Active Directory (AD) sem surpresas? Este guia prático mostra como planejar, testar e estender o esquema com segurança — do OID ao LDIF e PowerShell — além de governança, LGPD/GDPR e integração com Microsoft Entra ID.
Por que criar o atributo “Gender” no Active Directory
Organizações que desejam personalizar comunicações, apoiar iniciativas de diversidade e produzir relatórios confiáveis precisam de um dado estruturado, pesquisável e governado. Um atributo nativo no AD:
- Permite filtros LDAP e automação via PowerShell/LDAP.
- Integra-se a sistemas de RH/IAM e pipelines de provisionamento.
- Oferece base sólida para relatórios de diversidade e inclusão.
O que você realmente precisa saber antes de mudar o esquema
- É permanente: mudanças no schema são irreversíveis e replicam para todo o forest.
- Impacto global: o atributo passa a existir para todos os objetos da classe escolhida (ex.:
user). - Janela de manutenção e testes: sempre validar em laboratório e planejar replicação.
- Privacidade: “gênero” pode ser tratado como dado sensível — ver governança e LGPD/GDPR adiante.
Valores recomendados e convenções
Padronize valores e documente-os para todas as equipes (RH, TI, apps):
| Valor | Descrição | Observações |
|---|---|---|
Male | Masculino | Evite traduções no atributo; use inglês para consistência técnica. |
Female | Feminino | Valores devem ser case-insensitive, mas normalize em maiúsculas/minúsculas. |
NonBinary | Não binário | Inclua e documente a semântica organizacional. |
PreferNotToSay | Prefere não declarar | Útil para respeitar a autodeterminação de dados. |
Importante: o AD não aplica enumerações nativamente em atributos de texto. A validação de valores deve ocorrer nos processos/sistemas de entrada (provisionamento, formulários, integrações).
Resumo do processo recomendado
| Passo | O que fazer | Observações importantes |
|---|---|---|
| Planejar | • Definir valores aceitos (Male, Female, NonBinary, PreferNotToSay).• Reservar um OID corporativo exclusivo (ver seção OID). • Definir classe(s) alvo (ex.: user, contact). | Mudanças de esquema são irreversíveis e se propagam a todo o forest. |
| Testar em laboratório | Clonar um DC do schema master, aplicar o LDIF e verificar replicação com repadmin /showrepl. | Nunca altere o esquema em produção sem testes prévios. |
| Estender o esquema | a) Entrar no schema master como membro de Schema Admins. b) Registrar o snap‑in (se necessário): regsvr32 schmmgmt.dll.c) Abrir Active Directory Schema ( mmc /a) → Attributes → Create Attribute.d) Criar o atributo: • ldapDisplayName: gender• Syntax: Unicode String (case-insensitive) • Single‑Valued • Range: 1‑32 caracteres e) Associar o atributo à classe user (ou outras necessárias).f) Forçar/aguardar replicação. | Alternativamente, importar um .ldf via ldifde -i -f ou usar extadsch.exe em ambientes que já usam Configuration Manager. |
| Proteger e governar | Delegar leitura/escrita do novo atributo apenas a quem precisa; atualizar políticas de privacidade (LGPD/GDPR); ativar auditoria de alterações. | O atributo existe para todos os objetos da classe; controle de acesso por ACL. |
| Integrar e validar | Atualizar processos de provisionamento; validar com Get-ADUser -Properties gender e consultas LDAP; documentar e monitorar. | Inclua auditoria para rastrear quem escreve o campo. |
Pré‑requisitos e papéis
| Tópico | Detalhes |
|---|---|
| Permissões | Conta membro de Schema Admins (e, idealmente, Enterprise Admins para operações correlatas). |
| Backup | Backup de estado do sistema dos DCs críticos e schema master antes da alteração. |
| Janela | Janela de manutenção com comunicação ao negócio, dada a replicação em todo o forest. |
| Ambiente | Laboratório isolado (snapshot/clone do schema master) e documentação de testes. |
Planejamento de OID e nomenclatura
Cada novo atributo no AD requer um OID único. Use um OID corporativo oficial. Caso não exista, é prática comum gerar um OID derivado do seu forest com a raiz reservada pela Microsoft (ex.: 1.2.840.113556.1.8000.2554.<sequência-única>). Documente o OID e mantenha um inventário de atributos para evitar colisões.
Nomenclatura recomendada:
- lDAPDisplayName:
gender - adminDisplayName:
Gender - Descrição: “User gender (Male, Female, NonBinary, PreferNotToSay)”
Criação via GUI (MMC)
- No schema master, registre o snap‑in:
regsvr32 schmmgmt.dll. - Abra
mmc /a→ File → Add/Remove Snap-in → Active Directory Schema. - Em Attributes → Action → Create Attribute, preencha:
- Common Name: Gender
- LDAP Display Name: gender
- Unique X.500 OID: seu OID corporativo para o atributo
- Syntax: Unicode String (insensível a maiúsculas/minúsculas)
- Minimum/Maximum: 1–32
- Single-Valued: marcado
- Em Classes →
user→ Properties → Attributes (Optional) → Add → selecionegender. - Confirme e monitore a replicação.
Criação via LDIF (recomendado para repetibilidade)
Substitua DC=contoso,DC=com e 1.2.840... pelos valores da sua organização:
dn: CN=gender,CN=Schema,CN=Configuration,DC=contoso,DC=com
changetype: add
attributeID: 1.2.840.113556.1.8000.2554.1234567
lDAPDisplayName: gender
adminDisplayName: Gender
adminDescription: User gender (Male, Female, NonBinary, PreferNotToSay)
attributeSyntax: 2.5.5.12
oMSyntax: 64
isSingleValued: TRUE
rangeLower: 1
rangeUpper: 32
searchFlags: 0
systemOnly: FALSE
dn: CN=User,CN=Schema,CN=Configuration,DC=contoso,DC=com
changetype: modify
add: mayContain
mayContain: gender
------------------
Importe com:
ldifde -i -f .\Gender-Attribute.ldf -k -j .\logs
Opcional (apenas se fizer sentido): indexar o atributo para buscas frequentes e/ou publicá-lo no Global Catalog:
# Indexar (searchFlags bit 1)
dn: CN=gender,CN=Schema,CN=Configuration,DC=contoso,DC=com
changetype: modify
replace: searchFlags
searchFlags: 1
- # Tornar parte do Global Catalog (Partial Attribute Set)
dn: CN=gender,CN=Schema,CN=Configuration,DC=contoso,DC=com
changetype: modify
replace: isMemberOfPartialAttributeSet
isMemberOfPartialAttributeSet: TRUE
-----------------------------------
Nota: indexação e presença no GC aumentam uso de armazenamento/replicação; avalie a necessidade real.
Validação pós‑implantação
# Confirmar existência do atributo no Schema
$schemaNC = (Get-ADRootDSE).schemaNamingContext
Get-ADObject -SearchBase $schemaNC -LDAPFilter "(lDAPDisplayName=gender)" -Properties lDAPDisplayName,attributeID,rangeUpper,isSingleValued
Verificar replicação
repadmin /showrepl
dcdiag /test\:replications
Ler/escrever o atributo em um usuário
Get-ADUser jdoe -Properties gender | Select-Object SamAccountName,gender
Set-ADUser jdoe -Replace @{gender="NonBinary"} Consultas LDAP típicas:
(&(objectClass=user)(gender=Female))
Contagem por valor com PowerShell:
Get-ADUser -LDAPFilter "(gender=*)" -Properties gender |
Group-Object gender |
Sort-Object Count -Descending |
Select-Object Name,Count
Governança, LGPD/GDPR e segurança
- Base legal e finalidade: documente a finalidade e a base legal (consentimento, interesse legítimo, obrigação legal, etc.).
- Minimização: armazene apenas o necessário; permita PreferNotToSay.
- Transparência: atualize avisos de privacidade e registros de tratamento.
- Controle de acesso: atribua permissões de leitura/escrita do atributo “Gender” apenas a grupos/sistemas necessários.
- Auditoria: habilite “Directory Service Changes” para registrar alterações (ex.: Event ID 5136) e monitore via SIEM.
Como aplicar ACL por atributo (exemplo prático):
- Abra “Active Directory Users and Computers” (ADUC), ative Advanced Features.
- No OU alvo, abra Properties → Security → Advanced → Add.
- Escolha o grupo (ex.:
HR-Writers), em “Applies to” selecione “Descendant User objects”. - Em “Properties”, marque “Write gender” (ou “Read gender” conforme o caso).
Embora o atributo exista para toda a classe user, você pode modular a capacidade de ler/escrever por OU usando ACLs no contêiner apropriado.
Integração com Microsoft Entra ID (Azure AD) e M365
Para sincronizar o novo atributo para a nuvem:
- No Microsoft Entra Connect Sync (ou Cloud Sync), habilite Directory extensions e selecione
genderpara sincronização. - O atributo aparecerá no Entra ID como uma extensão de esquema (por padrão, com prefixo
extension<appId>gender). - Atualize apps (Graph/PowerShell) para ler/gravar a extensão correspondente.
Exchange: se a organização já usa Exchange (local/Online), considere reaproveitar extensionAttribute1–15 para evitar alteração de esquema. Veja a seção de alternativas.
Vantagens
- Campo estruturado, pesquisável e utilizável por scripts e filtros LDAP.
- Melhora relatórios de diversidade e personalização de comunicações.
- Integração consistente entre RH, IAM, e diretórios (on‑premises e nuvem).
Desvantagens e riscos
- Extensão de esquema é permanente e replica para todo o forest.
- Exige janela de manutenção, backup e aprovação formal (grupo Schema Admins).
- O atributo existe em todos os objetos da classe; não é possível restringir sua existência a um único OU.
Alternativas menos invasivas
| Opção | Quando usar |
|---|---|
extensionAttribute1–15 / customAttribute (Exchange) | Se a organização tem Exchange local/Online; basta reutilizar um campo existente e renomeá-lo na aplicação. |
Campos genéricos existentes (info, notes, etc.) | Quando apenas armazenamento de texto livre basta e não há necessidade de filtro LDAP estruturado. |
| Microsoft Entra ID (Azure AD) Directory Extensions | Ambientes híbridos ou 100% cloud que preferem manter atributos fora do AD local. |
| Sistemas de RH/IAM externos | Quando o dado não precisa residir no AD; apenas sistemas de provisionamento leem e populam conforme necessário. |
Checklist de implantação segura
- Definir valores, OID e classe(s) alvo; aprovar em CAB (Change Advisory Board).
- Preparar laboratório, snapshots, e plano de testes (criação/leitura/replicação/ACL).
- Executar LDIF em lab; validar com
repadmin,dcdiageGet-ADObject. - Documentar ACLs por OU e grupos responsáveis (RACI).
- Planejar janela e comunicação; realizar backup de estado do sistema.
- Aplicar LDIF em produção no schema master.
- Validar replicação e leitura/escrita em OUs representativas.
- Atualizar processos de provisionamento e integrações (Entra Connect, HR, IAM).
- Configurar auditoria e monitoramento (SIEM, alertas de alteração).
- Remover acesso temporário ao grupo Schema Admins; encerrar a mudança.
Provisionamento e automação
Exemplo de carga inicial a partir de CSV (SamAccountName,Gender):
Import-Csv .\users_gender.csv | ForEach-Object {
$value = $_.Gender.Trim()
if ($value -in @("Male","Female","NonBinary","PreferNotToSay")) {
Set-ADUser -Identity $_.SamAccountName -Replace @{gender=$value}
} else {
Write-Warning "Valor inválido para $($_.SamAccountName): '$value'"
}
}
Validação contínua (bloquear valores fora do padrão):
Get-ADUser -LDAPFilter "(gender=*)" -Properties gender |
Where-Object { $_.gender -notin @("Male","Female","NonBinary","PreferNotToSay") } |
Select-Object SamAccountName,gender
Boas práticas de desempenho e replicação
- Indexação: só indexe se houver consultas frequentes por
gender=em grande escala. - Global Catalog: publicar no GC apenas se o atributo for necessário em pesquisas de floresta.
- Sites e links: valide a replicação intersite e latência após a mudança.
Solução de problemas
| Sintoma | Causa provável | Como resolver |
|---|---|---|
| “Server is unwilling to perform” ao importar LDIF | Conta sem Schema Admins ou alteração fora do schema master. | Executar no schema master com conta apropriada. |
Não consigo escrever gender em usuários | Atributo não associado à classe user ou ACL negando escrita. | Verificar mayContain da classe e permissões de “Write gender”. |
| Valores inconsistentes (“male”, “MALE”) | Falta de padronização no provisionamento. | Normalize no ponto de entrada (scripts, HR, integrações). |
| Latência de replicação elevada | GC e/ou indexação habilitados sem necessidade; topologia de sites limitada. | Reavaliar GC/indexação; revisar agendamentos e custos de site. |
Perguntas frequentes (FAQ)
É possível remover o atributo depois?
Na prática, não. Você pode parar de usá-lo, mas a definição permanece no esquema do AD.
Posso restringir o atributo a um único OU?
Não quanto à existência; o atributo existe para toda a classe. Entretanto, você pode controlar quem lê/escreve por OU via ACL.
Como testar sem impactar produção?
Use laboratório com clone/snapshot do schema master; aplique LDIF e valide com repadmin e scripts.
É melhor usar extensionAttribute1–15?
Se você já usa Exchange e não precisa de um nome de atributo dedicado no esquema, essa é uma alternativa sem extensão de schema.
Como levar o atributo para a nuvem?
Habilite Directory extensions no Microsoft Entra Connect/Cloud Sync e selecione gender.
Resumo prático
- A única forma nativa de ter um atributo “Gender” no AD é estender o schema.
- Por ser definitivo, avalie alternativas (
extensionAttribute1–15, extensões no Entra ID, campos genéricos) antes. - Se indispensável, siga processo controlado: laboratório → backup → execução por Schema Admins → validação → governança contínua.
Modelo de runbook (copiável)
1) Aprovação (CAB) e design:
- Valores e semântica
- OID e nomenclatura
- Classe(s) alvo: user/contact
- ACLs de leitura/escrita
- Necessidade de indexação/GC
2. Preparação:
- Lab com clone/snapshot do schema master
- Backups de estado do sistema
- Scripts LDIF/PowerShell versionados
3. Execução em lab:
- Importar LDIF
- Associar à classe
- Testar leitura/escrita e ACLs
- Validar replicação (repadmin/dcdiag)
4. Produção:
- Janela e comunicação
- Executar LDIF no schema master
- Confirmar replicação
- Testes de fumaça (criar/ler/filtrar)
5. Pós-go-live:
- Monitorar eventos de alteração
- Habilitar Directory Extensions (se houver sincronização)
- Remover membros temporários de Schema Admins
- Atualizar documentação e CMDB Exemplos de mapeamentos para integrações
| Origem | Transformação | Destino |
|---|---|---|
HR API genderCode | 1→Male, 2→Female, 3→NonBinary, 9→PreferNotToSay | AD user.gender |
AD user.gender | Direto (sem transformação) | Entra ID extension<appId>gender |
AD user.gender | Uppercase para comparação | Ferramenta de e‑mail segmentado |
Boilerplate de comunicação ao negócio
Resumo: inclusão do atributo “Gender” no AD para personalização e relatórios de diversidade. Impacto: sem downtime para usuários; replicação transparente. Privacidade: dado visível apenas para equipes autorizadas; opção “PreferNotToSay”. Contato: time de Identidade/IAM.
Conclusão: adicionar o atributo “Gender” ao Active Directory é uma mudança estratégica e definitiva. Com um planejamento sólido (valores, OID, ACLs), testes em laboratório e execução controlada (LDIF/GUI), você habilita automação e relatórios confiáveis, preservando segurança e privacidade.