Senhas de usuários e atualizações
Sua segunda hipótese está quase correta:
B) no password is required when the account is created but if the password is changed it must still follow password policies.
Para que isso faça sentido, por favor, entenda que a atualização de uma senha de conta de usuário pode ser realizada por meio de duas operações aparentemente semelhantes, mas muito distintas:
-
Por configuração da senha
- Isso é feito por um usuário administrativo
- Normalmente, uma permissão delegada ao pessoal do helpdesk
- Deve aderir a
userAccountControl
settings - Não vinculado às configurações da política de histórico de senhas
-
Ao alterar a senha
- Isso é feito pelo usuário
- Geralmente, uma parte da primeira tentativa de autenticação após a expiração da senha
- Precisa estar em conformidade com a Política de senha e
userAccountControl
settings
Isso significa que um Administrador pode definir sua senha como null
se o objeto da sua conta permitir (ou seja, PASSWD_NOTREQD
estiver definido), independentemente do Política de senha que se aplica e por quanto tempo ela exige que as senhas sejam.
Não é possível alterar sua senha para null
, já que a "Alteração de senha" significa que você está substituindo uma senha e não a desativando. Ao alterar a senha, a nova senha será validada com base na Política de Senha efetiva.
Acho que a maneira mais fácil de lembrar é que as Senha aplicam-se às Senhas - PASSWD_NOTREQD
, por outro lado, é um medida de se você está permitido para não ter uma senha - nesse caso, a política não é mais relevante.
É perigoso?
PASSWORD_NOTREQD
pode parecer uma bandeira perigosa, mas não é prejudicial, já que vários mecanismos impedem o uso de null
-passwords (ou "senhas em branco"). Como mencionado acima, os usuários não podem desanexar suas próprias senhas de usuário do AD por padrão, e o Windows (edições do consumidor e do servidor) rejeitará a autenticação de senha pela rede, por padrão com senhas em branco - isso significa que você só pode fazer logon a partir do console.