Recentemente, entrei em um ambiente em que muitos logins de bancos de dados não têm o enforce_password_policy
sinalizador ativado.
Uma auditoria futura está exigindo a verificação das senhas desses logins.
Usei a seguinte consulta para obter uma lista de logins e se os sinalizadores estão ativados ou desativados.
select
@@SERVERNAME as servername,
name,
IS_SRVROLEMEMBER('sysadmin', name) as SYSADMIN,
type_desc,
create_date,
is_policy_checked,
is_disabled,
password_hash,
PWDCOMPARE(name, password_hash) as UsernameAsPassword
FROM sys.sql_logins
No entanto, isso não me diz se as senhas realmente aderem à política de senhas, pois o sinalizador só é relevante ao criar um usuário.
Existe uma maneira conhecida de testar usuários existentes quanto à conformidade com a política de senha?
Não tenho acesso às senhas antigas e prefiro um método que não as exija.
Isso pode não ser popular entre seus usuários, mas acredito que a única maneira de saber com certeza é forçar uma alteração de senha para cada login SQL com
CHECK_POLICY = ON
. Isso gerará um conjunto deALTER LOGIN
comandos com senhas em branco, você pode atualizar a consulta dando a todos uma senha comum ou atualizar manualmente cada um com senhas individuais - apenas certifique-se de que atendam à sua política. Claro que você precisa ter certeza de que a política de senha é tão complexa quanto você espera e que ela está habilitada (Painel de Controle > Ferramentas Administrativas > Política de Segurança Local > Políticas de Conta > Política de Senha > A senha deve atender aos requisitos de complexidade).Steve Jones escreveu sobre isso um tempo atrás. Observe que - devido ao que descobri abaixo - você não pode confiar
is_policy_checked = 1
que a senha realmente atende à sua política atual, pois o login pode ter sido criado com uma senha com hash (nesse caso, a senha de texto simples não pode ser marcada) ou enquanto a política de complexidade local estava desativada (o que ainda leva ais_policy_checked = 1
).Outra abordagem que achei que funcionaria seria tentar criar uma cópia de cada login com o atual
password_hash
e comCHECK_POLICY = ON
, e anotar todos os que falharem. No entanto, isso não pode funcionar - mesmo comCHECK_POLICY = ON
, ele não executa nenhuma validação de uma senha já com hash. Incluirei o código para a posteridade - mas, por design, a política simplesmente não pode ser verificada.Pessoalmente, acho que isso é um bug. Se a sintaxe me permitir criar um login usando uma senha com hash e eu puder estipular que essa senha deve atender à minha política de complexidade, ela deve gerar um erro ou aviso de que a política não foi, de fato, verificada.
UPDATE : Eu registrei um bug contra esse comportamento.
Não há como você obter 100% de precisão. Embora você possa usar
PWDCOMPARE
para verificar uma lista de senhas fracas (você pode adicionar à lista de senhas fracas e fazer uma comparação).Eu escrevi um script semelhante que faz a comparação e fornece os resultados. Eu postei no github .
EDITAR:
Agora você pode ter uma lista de senhas fracas em um csv e então usar dbatools
Test-DbaLoginPassword
com-Dictionary
switch (Especifica uma lista de senhas para incluir no teste de senhas fracas.)A política de senha por login do SQL é apenas um sinalizador para ativado ou desativado. Se o sinalizador de Política de Senha estiver marcado, a Política de Senha do Windows do sistema operacional será aplicada.
Verifique a documentação CREATE LOGIN para obter detalhes sobre o que acontece quando CHECK_POLICY e CHECK_EXPIRATION são definidos.
Você pode ver as configurações por usuário do SQL verificando as colunas is_policy_checked e is_expiration_checked em sys.sql_logins
algo como abaixo:
Para logins de autenticação do SQL Server:
select * from sys.server_principals where type in ('U','G')
- mostrará os logins e grupos que podem acessar um SQL Server via Autenticação do Windows.