Verificando a política de senha em usuários existentes

Recentemente, entrei em um ambiente em que muitos logons de bancos de dados não têm o enforce_password_policysinalizador ativado.
Uma próxima auditoria está exigindo a verificação das senhas desses logons.

Usei a consulta a seguir para obter uma lista de logons 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 indica se as senhas realmente aderem à política de senhas, pois o sinalizador é relevante apenas ao criar um usuário.

Existe uma maneira conhecida de testar os usuários existentes quanto à conformidade com a diretiva de senha?
Não tenho acesso às senhas antigas e prefiro um método que não as exija.

— Reaces
fonte

Que conferência? Dias do SQL Server? BICC? Fiz uma pesquisa rápida, parece que não há nenhuma função nativa que lhe dará um resultado rapidamente. Pode ser possível usar uma ferramenta de terceiros.

— Stijn Wynants

Dias do SQL Server. Também fiz algumas pesquisas rápidas e, além de algumas ferramentas que apenas fazem ataques de dicionário PWDCOMPARE(), não encontrei muita coisa, apesar de obrigado pelo esforço!

— Reaces

Você pode validar a política no próximo logon e forçar uma redefinição para todos os usuários que não efetuam login antes da auditoria. Menos aborrecimento do usuário em comparação com a redefinição de todas as senhas.

— CodesInChaos

@CodesInChaos Como você valida a política durante um evento de login?

— Aaron Bertrand

Eu escrevi sobre esse problema no blog - e incentivo todos vocês a votar e comentar o item do Connect .

— Aaron Bertrand

Respostas:

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 CHECK_POLICY = ON. Isso gerará um conjunto de ALTER LOGINcomandos com senhas em branco. Você pode atualizar a consulta, fornecendo a todos uma senha comum ou atualizar manualmente cada uma com senhas individuais - apenas verifique se elas atendem à sua política. Obviamente, você precisa ter certeza de que a política de senha é tão complexa quanto o esperado e ativada (Painel de Controle> Ferramentas Administrativas> Política de Segurança Local> Políticas de Conta> Políticas de Senha> Política de Senha> A senha deve atender aos requisitos de complexidade).

SELECT N'ALTER LOGIN ' + QUOTENAME(name) 
  + N' WITH PASSWORD = N'''' MUST_CHANGE, CHECK_POLICY = ON;' 
  FROM sys.sql_logins 
  --WHERE is_policy_checked = 0;

Steve Jones escreveu sobre isso há um tempo. Observe que, devido ao que descobri abaixo, você não pode confiar is_policy_checked = 1para que a senha realmente atenda à sua política atual, pois o login pode ter sido criado com uma senha com hash (nesse caso, a senha em texto sem formatação não pode ser marcado) ou enquanto a política de complexidade local estava desativada (o que ainda leva a is_policy_checked = 1).

Outra abordagem que pensei que funcionaria seria tentar criar uma cópia de cada login com seu atual password_hashe com CHECK_POLICY = ONe anotar todos que falharem. No entanto, isso não pode funcionar - mesmo com CHECK_POLICY = ON, ele não executa nenhuma validação de uma senha já com hash. Incluirei o código da posteridade - mas, por padrão, a política simplesmente não pode ser verificada.

SELECT N'BEGIN TRY
  CREATE LOGIN ' + QUOTENAME(N'copy_of_' + name) 
    + N' WITH PASSWORD = ' 
    + CONVERT(NVARCHAR(255), password_hash, 1)
    + ' HASHED, CHECK_POLICY = ON;
  DROP LOGIN ' + QUOTENAME(N'copy_of_' + name) + ';
END TRY
BEGIN CATCH
  IF ERROR_NUMBER() = 15118
    PRINT N''' + REPLACE(name, '''', '''''') 
      + N' was not complex enough.'';
END CATCH'
FROM sys.sql_logins;

Pessoalmente, acho que isso é um bug. Se a sintaxe permitir que eu crie um login usando uma senha com hash e eu possa estipular que essa senha deve atender à minha política de complexidade, ela deverá gerar um erro ou aviso de que a política não foi, de fato, verificada.

UPDATE : Eu registrei um bug contra esse comportamento.

CHECK_POLICY é um no-op com CREATE LOGIN ... PASSWORD ... HASHED

— Aaron Bertrand
fonte

Outra complicação é que, na verdade, tenho certeza de que o administrador anterior apenas verificou essa política depois de inserir senhas fáceis de lembrar.

select  	@@SERVERNAME as servername,  	name FROM sys.sql_logins where PWDCOMPARE(name, password_hash) = 1 AND is_policy_checked = 1;

deu vários resultados positivos. Portanto, terei que fazer isso em todos os logins, não apenas nos que estão is_policy_checkeddesativados.

— Reaces

@Reaces Possivelmente. Ou sua política de senha no Windows pode estar fraca ou desabilitada, portanto, tentar impor a política não ajuda.

— Aaron Bertrand

Eu apenas tentei criar o mesmo usuário em um segundo servidor e obtive uma validação de senha falhada. Então, acho que a verificação de complexidade funciona. Eu gosto da idéia de recriar cópias dos usuários! Vou começar a trabalhar criando um script que faça exatamente isso! Edição: na verdade, eu poderia apenas usar sp_help_revlogin para fazer o trabalho pesado.

— Reaces em 15/04

"ele não executa nenhuma validação de uma senha já com hash" Como isso seria feito? Se você souber apenas o hash e não a senha simples, não poderá verificar a complexidade da senha. Você poderia adivinhar a senha, mas isso seria muito caro para um hash de senha decente, pois todo o ponto de um hash de senha está impedindo a recuperação da senha de texto sem formatação.

— código é o seguinte

@CodesInChaos Eu sei, esse é o meu ponto ... eu disse "não", mas também poderia ter escrito "não poderia" ...

— Aaron Bertrand

Não há como você obter isso 100% preciso. Embora você possa usar PWDCOMPAREpara 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, em seguida, usar dbatools Test-DbaLoginPasswordcom -Dictionaryswitch (especifica uma lista de senhas a serem incluídas no teste de senhas fracas).

— Kin Shah
fonte

Eu gostaria muito de usar seu script se precisar fazer uma auditoria da senha de um usuário em particular. No entanto, sem saber o que o auditor fará, prefiro apenas garantir que tudo esteja em conformidade com as políticas e confiar naqueles que as criam. Obrigado embora! 1

— Reage em 15/04

Política de senha por logon do SQL é apenas um sinalizador para ativar ou desativar. 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 de CREATE LOGIN para obter detalhes sobre o que acontece quando CHECK_POLICY e CHECK_EXPIRATION estão definidos.

Você pode ver as configurações por usuário SQL, verificando as colunas is_policy_checked e is_expiration_checked em sys.sql_logins

algo como abaixo:

SELECT name,
create_date,
modify_date,
LOGINPROPERTY(name, 'DaysUntilExpiration') DaysUntilExpiration,
LOGINPROPERTY(name, 'PasswordLastSetTime') PasswordLastSetTime,
LOGINPROPERTY(name, 'IsExpired') IsExpired,
LOGINPROPERTY(name, 'IsMustChange') IsMustChange
From sys.sql_logins ;

Para logons 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.

— KASQLDBA
fonte

Atualizei minha pergunta um pouco, pois eu já estava usando uma consulta semelhante. Meu principal problema é que preciso garantir ao meu chefe que as senhas são compatíveis com a política, mas não sei as senhas que não sei como poderia.

— Reaces