Redefinir senha de usuário no Active Directory por conta de administrador de domínio ou outra conta de serviço


8

No Active Directory, você pode definir e aplicar regras nas quais os usuários precisam usar senha forte, não podem usar as últimas 5 ou mais senhas que já possuíam, impor a complexidade da senha. Existe uma maneira de impor essas configurações para que, se uma conta de serviço (serviço da web de redefinição de senha) tentar definir uma nova senha para o usuário, ela seja comparada à política e seja aceita ou negada?

Parece que, como a conta de serviço está forçando a alteração de senha, o usuário pode digitar a mesma senha via interface da web e continuar usando a mesma senha repetidamente. Como é uma conta de serviço que altera a senha para ele, ela não é verificada nas últimas senhas conhecidas, portanto, as regras da senha não são aplicadas.

Embora o programador possa codificar uma verificação de complexidade, as últimas senhas usadas não podem ser verificadas na interface da web porque o serviço da web não possui o conhecimento das últimas senhas.

É possível forçá-lo para que essa alteração da senha por conta de serviço também seja restrita, como seria a alteração normal da senha do usuário?

Respostas:


9

No AD, existem dois tipos de operações para alterar a senha de um usuário - uma alteração que pode ser executada anonimamente porque requer a senha antiga como parte da solicitação e uma redefinição , que não exige a senha antiga e deve ser feita por um usuário com acesso para redefinir senhas da conta segmentada.

Nesse caso, o aplicativo de software está fazendo a operação de redefinição, sem o conhecimento da senha antiga do usuário, mas enquanto autenticado como presumivelmente uma conta de serviço com os direitos necessários.

Da perspectiva do AD, a senha está sendo redefinida administrativamente; O histórico de senhas nunca é imposto nesse caso, pois o administrador que está fazendo a redefinição não deve saber as senhas antigas do usuário - se ele tem o hábito de definir a nova senha para, digamos Thursday1, ter essa falha em cumprir a política em uma operação de redefinição, ser bastante confuso.

Embora a experiência do usuário seja ruim, o melhor mecanismo que posso pensar para lidar com isso seria fazer com que o aplicativo da Web redefina a senha (talvez para algo que eles não inserem, apenas gerem) e defina a opção "deve alterar a senha no próximo login "na conta para forçar o usuário a executar imediatamente uma operação de alteração de senha, o que aplicará o histórico.

Há alguma discussão sobre o uso de APIs LDAP no .Net para atingir o objetivo de impor o histórico desse tipo de redefinição aqui , mas não tenho certeza se essa será uma opção para você, dependendo do aplicativo que estiver usando; se você controla o código e a biblioteca LDAP que você está usando suporta controles, deve ser possível.


É possível implementar uma alteração de senha, como você a descreve, em um aplicativo da web. O OWA faz isso, e minha universidade tem um aplicativo personalizado que faz isso também. Requer que o usuário insira a senha antiga e depois a nova senha duas vezes, como padrão. Eu não sei a programação por trás disso, esse seria um tópico mais adequado para SO.
Thomas

Aqui está um aplicativo da web shareware que executa essa função. Não testei e NÃO endosso este aplicativo, apenas o compartilho para demonstrar que a funcionalidade existe. softpedia.com/get/Internet/Servers/Server-Tools/...
Thomas

@ Tomás Meu palpite é que o aplicativo que ele está usando é para redefinir a senha de autoatendimento quando o usuário esqueceu sua senha (mas tem algum tipo de autenticação imposta pelo serviço da Web, como pergunta de segurança), o que tornaria impossível o mecanismo de "alteração" . Caso contrário, definitivamente, basta usar a operação de alteração!
Shane Madden

Entendo - o OP não explicou se era esse o caso, mas você pode estar certo.
Thomas
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.