Introdução
Apesar da crescente adoção de métodos de autenticação modernos, como MFA (autenticação multifator) e autenticação baseada em certificados, as senhas ainda representam uma das formas mais comuns de autenticação em ambientes corporativos. Infelizmente, muitas violações de segurança ainda ocorrem por conta do uso de senhas fracas ou reutilizadas.
Neste artigo, exploramos boas práticas e recursos nativos do Active Directory (AD DS) e do Microsoft Entra para impedir o uso de senhas vulneráveis por parte dos usuários, promovendo um ambiente mais seguro e alinhado com frameworks como NIST SP 800-63B, ISO 27001 e CIS Controls.
O problema das senhas fracas
Senhas fracas são aquelas que:
- Estão em dicionários públicos de senhas comprometidas;
- Contêm padrões simples e previsíveis (como 123456, senha123, welcome!);
- São curtas (menos de 8 caracteres);
- Utilizam informações pessoais fáceis de adivinhar (data de nascimento, nome da empresa, etc).
Esse tipo de senha é altamente suscetível a ataques como:
- Password spraying;
- Credential stuffing (reutilização de senhas vazadas);
- Ataques de dicionário/brute-force;
- Ataques internos (insider threats).
Estratégias para evitar senhas fracas no Active Directory
1. Implemente uma FGPP (Fine-Grained Password Policies)
O AD DS permite aplicar políticas de senha mais rígidas a grupos ou usuários específicos por meio das FGPP:
- Comprimento mínimo da senha: Recomendado 14 caracteres.
- Complexidade: Requer letras maiúsculas, minúsculas, números e símbolos.
- Histórico de senhas: Impeça a reutilização das últimas 24 senhas.
- Tempo de vida da senha: Recomendado não expirar automaticamente, mas monitorar por comportamento anômalo.
Comando PowerShell para criar uma FGPP:
New-ADFineGrainedPasswordPolicy
[-WhatIf]
[-Confirm]
[-AuthType <ADAuthType>]
[-ComplexityEnabled <Boolean>]
[-Credential <PSCredential>]
[-Description <String>]
[-DisplayName <String>]
[-Instance <ADFineGrainedPasswordPolicy>]
[-LockoutDuration <TimeSpan>]
[-LockoutObservationWindow <TimeSpan>]
[-LockoutThreshold <Int32>]
[-MaxPasswordAge <TimeSpan>]
[-MinPasswordAge <TimeSpan>]
[-MinPasswordLength <Int32>]
[-Name] <String>
[-OtherAttributes <Hashtable>]
[-PassThru]
[-PasswordHistoryCount <Int32>]
[-Precedence] <Int32>
[-ProtectedFromAccidentalDeletion <Boolean>]
[-ReversibleEncryptionEnabled <Boolean>]
[-Server <String>]
[<CommonParameters>]
Fonte: Microsoft Learn
Exemplo de FGPP:
New-ADFineGrainedPasswordPolicy -Name "FGPP-Domain-PSO" -Precedence 500 -ComplexityEnabled $true -Description "Política de senha aplicável a todo o domínio" -DisplayName "Domain Users Password Policy" -LockoutDuration "0.06:00:00" -LockoutObservationWindow "0.00:15:00" -LockoutThreshold 5 -MinPasswordLength 14 -PasswordHistoryCount 24
Explicação de cada parâmetro
Explicação Formal de Cada Parâmetro
| Parâmetro | Significado Técnico |
|---|---|
-Name "FGPP-Domain-PSO" | Nome interno do objeto de política (usado no AD). Será o identificador LDAP do PSO (Password Settings Object). |
-Precedence 500 | Define a prioridade desta política em relação a outras FGPPs. Valores menores (ex: 1) têm prioridade mais alta. |
-ComplexityEnabled $true | Obriga a utilização de senhas complexas (mistura de letras maiúsculas, minúsculas, números e caracteres especiais). |
-Description "Política de senha aplicável a todo o domínio" | Texto descritivo para ajudar na administração. Não impacta tecnicamente o funcionamento. |
-DisplayName "Domain Users Password Policy" | Nome amigável que será exibido em consoles de administração, como o Active Directory Administrative Center (ADAC). |
-LockoutDuration "0.06:00:00" | Duração do bloqueio de conta: 06 horas. Após esse tempo, o usuário poderá tentar logar novamente. |
-LockoutObservationWindow "0.00:15:00" | Janela de observação para contagem de tentativas inválidas: 15 minutos. |
-LockoutThreshold 5 | Após 5 tentativas inválidas dentro da janela de observação, a conta será bloqueada. |
| -MinPasswordLength 12 | Irá exigir um comprimento mínimo de 12 caracteres |
| -PasswordHistoryCount 24 | Irá manter como histórico as últimas 24 senhas de forma que estas últimas senhas não possam ser reutilizadas |
Importante: Criar o FGPP não faz com que ele automaticamente entre em vigor. Você precisa linkar (aplicar) essa política a um usuário ou grupo usando o cmdlet Add-ADFineGrainedPasswordPolicySubject.
Exemplo de associação:
Add-ADFineGrainedPasswordPolicySubject -Identity "FGPP-Domain-PSO" -Subjects "GrupoOuUsuarioDestino"Observação importante:
O que acontece em um ambiente onde existe GPO com políticas de senha e FGPP configuradas? Caso não tenha compreendido bem o que quero trazer a luz, vou dar o seguinte cenário:
No domínio Contoso.com Existe uma GPO linkada (na raiz do domínio) que dita algumas regras de política de senha. Além disso, existe uma FGPP atrelada a um grupo de usuários específico (Ex: grupo “Diretoria”).
A usuária Maria está dentro do grupo “Diretoria” (atralada a FGPP) e a Maria faz parte do domínio onde essa GPO está criada.
Qual regra prevalecerá? A GPO, a FGPP ou um seria um mix (quando não houver conflitos)? E se acaso houver conflito de políticas, qual prevalecerá? GPO ou FGPP?
No Active Directory, a aplicação de políticas de senha ocorre seguindo regras hierárquicas claras. E, especificamente no que tange a conflitos entre GPOs e FGPPs, a regra é absoluta:
| Cenário | Qual prevalece? |
|---|---|
| Existe uma FGPP aplicável ao usuário | FGPP prevalece completamente sobre a GPO de política de senha. |
| Não existe FGPP aplicável | GPO de política de senha de domínio prevalece (normalmente definida via Default Domain Policy ou outra GPO linkada na raiz do domínio). |
Ou seja:
- Não existe “mix” entre FGPP e GPO no que diz respeito às configurações de senha.
- A FGPP substitui inteiramente a GPO para aquele usuário específico, no escopo das configurações de:
- Complexidade de senha
- Tamanho mínimo
- Histórico de senha
- Tempo de expiração
- Bloqueio de conta
O que foi definido na FGPP será aplicado à ao grupo ou usuário, independentemente da GPO que está aplicada no domínio.
Sendo assim é de extrema importância que você, ao criar uma FGPP pense muito bem na política, pois uma FGPP mal criada, pode resultar em problemas sérios. Abaixo segue um exemplo de FGPP mal confIgurada (NÃO REPLIQUEM ESTA PRÁTICA!)
Cenário
A GPO do domínio define apenas os dois itens abaixo:
Tamanho mínimo: 8
Senha complexa: Sim
Uma FGPP foi criada e aplicada ao grupo “Diretoria”. Esta FGPP define apenas o item abaixo
Tamanho mínimo: 14
Supondo que Maria esteja no grupo “Diretoria”.
- Qual tamanho mínimo de senha vai ser aplicado a Maria?
R: Será aplicado o tamanho mínimo de 14 caracteres, conforme definido explicitamente na FGPP “Diretoria”. - Será exigido da Maria senha complexa?
R: Não, a complexidade de senha não será exigida para a Maria neste cenário.
Somente as FGPP resolvem o problema?
Você já atuou em alguma empresa onde percebia que certos tipos de contas “normalmente” tem quase que uma senha padrão?
Exemplo: Eu trabalho na contoso.com e a senha “normalmente” é Contoso@2025?
Se olharmos bem, Contoso@2025 tem:
- Contém 12 caracteres;
- Contém Letra Maiúscula
- Contém número;
- Contém carecter especial
Ou seja, se tentarmos usar a senha Contoso@2025 em um domínio com a FGPP criada acima o usuário vai conseguir usar esta senha, contudo há de se questionar: Esta senha realmente é segura?
Bom para resolver estas e outras questões em ambientes híbridos, existe um recurso muito bom: Microsoft Entra Password Protection
2. Use o Microsoft Entra Password Protection
Essa funcionalidade estende a proteção de senhas fortes existentes no Entra também para ambientes híbridos:
2.1. Banimento de senhas fracas
Neste caso, é usado um dicionário dinâmico da Microsoft (com mais de 1 bilhão de senhas comprometidas). A equipe da Proteção do Microsoft Entra ID analisa constantemente os dados de telemetria de segurança do Microsoft Entra procurando senhas mais fracas ou comprometidas usadas com frequência. Especificamente, a análise procura termos base que geralmente são usados como base para senhas fracas. Quando são encontrados termos fracos, eles são adicionados à lista de senhas proibidas globalmente. O conteúdo da lista de senhas proibidas globalmente não se baseia em nenhuma fonte de dados externa, mas nos resultados da análise e telemetria de segurança do Microsoft Entra.
Quando uma senha é alterada ou redefinida para qualquer usuário em um locatário do Microsoft Entra, a versão atual da lista de senhas proibidas globalmente é usada para validar a força da senha. Essa verificação de validação resulta em senhas mais fortes para todos os clientes do Microsoft Entra.
A lista global de senhas proibidas é aplicada automaticamente a todos os usuários em um locatário do Microsoft Entra e não pode ser desabilitada.
2.2. Criação de uma lista personalizada de senhas proibidas
Se você deseja aperfeiçoar a segurança é possível adicionar sua própria personalização. Os termos adicionados à lista personalizada de senhas banidas devem ter como base expressões específicas e de conhecimento da empresa, como por exemplo:
- Abreviações que tenham um significado específico para a empresa. Exemplo: A Contoso é conhecida pela abreviação CTZ
- Localizações e silgas – Ex: A CTZ tem um escritório chamado NSC40 (Nossa Senhora de Copacabana, 40 – Exemplo fictício de endereço de um dos escritórios da Contoso)
- Nomes de produtos que a empresa fabrica ou usa
- Termos internos específicos da empresa
Aplicável tanto no Microsoft Entra quanto no Active Directory on-premises (com o uso do Password Protection Proxy).
Para aplicar:
- Acesse o portal do Microsoft Entra Admin Center;
- Vá em Security → Authentication methods → Password Protection;
- Ative o modo “Enforce” e configure as listas proibidas;
- Instale o agente no(s) DC(s) locais para proteção on-premises.
Vamos considerar a empresa Contoso (que é conhecida internamente pela expressão CTZ) e tem sede na Av. Nossa Senhora de Copacabana, 40, site este conhecido como NSC40. Para este caso de exemplo, seria um desperdício e menos seguro tentar bloquear variações específicas desses termos:
- “Contoso!1”
- “Contoso@2025”
- “Contoso@nsc40”
- “ContosoWidget”
- “!CTZNSc40”
Em vez disso, é muito mais eficiente e seguro bloquear apenas os termos básicos da chave, como os exemplos a seguir:
- “Contoso”
- “CTZ”
- “NSC40”
3. Integração com Microsoft Defender for Identity e Entra ID Protection
Monitorar e responder a atividades suspeitas também é crucial. As soluções Microsoft oferecem alertas como:
- Usuário com senha vazada (baseado em sinalizações da Microsoft);
- Autenticações incomuns (fora do padrão geográfico ou comportamental);
- Uso de senhas fracas detectadas no Azure AD.
4. Educação e Treinamento de Usuários
A tecnologia sozinha não é suficiente. Campanhas de conscientização periódicas devem incluir:
- Exemplos de senhas fortes e fracas;
- Demonstração de ataques de força bruta;
Frameworks e Referências
- NIST SP 800-63B recomenda não impor expiração periódica e sim usar verificação contra dicionários de senhas comprometidas.
- CIS Controls v8 – Control 5 sugere o uso de MFA e mecanismos que bloqueiem senhas fracas.
- ISO/IEC 27001:2022 A.5.17 exige controles para autenticação segura de usuários.
Considerações Finais
Eliminar o uso de senhas fracas é um dos pilares fundamentais da segurança cibernética. No contexto do Microsoft Entra ID e Active Directory, há ferramentas robustas disponíveis — muitas delas inclusas em licenças corporativas — que ajudam a automatizar essa proteção.
A combinação de tecnologia, boas práticas administrativas e conscientização do usuário é essencial para criar uma política de senhas verdadeiramente eficaz.
Checklist rápido:
✅ Use FGPP com requisitos rígidos
✅ Habilite o Azure AD Password Protection
✅ Implemente listas banidas personalizadas
✅ Monitore!
✅ Promova campanhas educativas contínuas