DirectoryServices.AccountManagement “velho” senha ainda valida após a alteração de senha

Question

Depois de redefinir a senha de usuário no Active Directory, se o usuário tenta fazer login usando sua senha antiga, os seguintes valida código como True:

Dim up As UserPrincipal = GetAdUser(objContext, arg_strBA, arg_strUsername)

If up IsNot Nothing Then

    Dim valid As Boolean = up.Context.ValidateCredentials(
    up.UserPrincipalName, arg_strPassword, ContextOptions.Negotiate)


    If (valid) Then strReturn = up.SamAccountName

End If

Estamos redefinindo a senha usando o seguinte código:

Dim objUser As New DirectoryEntry(arg_strLDAPPath)

If Not objUser Is Nothing Then
    objUser.AuthenticationType = AuthenticationTypes.Secure


    objUser.Invoke("SetPassword", arg_strNewPW)
    objUser.CommitChanges()
end if

A redefinição de senha funciona bem e que o usuário pode fazer login com sua nova senha, mas a sua senha antiga não deve ainda validar.

Quando os ValidateCredentials obras acima para a senha antiga, estamos atribuindo as credenciais para uma chamada de serviço web, que, em seguida, falhar com um "401: Unauthorized". Erro

Alguém viu nada parecido com isso?

Answer 1

Eu Fount a resposta Aqui

A partir do link ...

"No entanto, o que conta é que ContextOption não garantir o uso de Kerberos somente. Acontece que, em certas situações (como se você está especificando AD em vez de local, e você tem uma suficientemente -se ao servidor data), os escolhe código para fazer Negociar não importa o quê. Nesse sentido, especificando vedação provavelmente significa que ele vai usar Kerberos, mas não necessariamente de forma exclusiva. a bandeira que realmente importa é enterrado várias camadas sob esse. nos bastidores , este método acaba por estabelecer um LdapConnection, estabelecendo as credenciais de rede para a conexão, estabelecendo que AuthType (a bandeira real que importa!), e, finalmente, chamar o método Bind (). o método LdapConnection.Bind () estabelece uma conexão autenticada um dos servidores de anúncios usando as credenciais especificadas. o problema é que quando PrincipalContext.ValidateCredentials conjuntos até esta chamada (em seu cenário), ele sempre define o AuthType = Negociar. neste caso, Kerberos faz em fato get usado, e acaba falhando, mas o sistema cai de volta para NTLM. "

Answer 2

Este problema não está relacionado com o Código, mas o culpado mais ouve é o diretório do Active ...

Por favor, consulte http://support.microsoft.com/kb/906305 para solução. ..

Answer 3

Isso funciona - Veja solução abaixo -. Por favor, deixe-me saber se você encontrar este útil como nossa loja está dividida sobre se esta é uma solução OK

A seguir é uma solução para Active Directory Permitir senha antiga para o trabalho depois de ser alterado. Eu gostaria muito feedback sobre a aceitação desta solução como ele usa o ChangePassword durante a autenticação Faça login. Esta é uma coisa estranha para fazer, mas ele funciona. Atualmente nossa loja não está usando esta solução por isso, se alguém pode me dizer se eles estão usando ou não que seria apreciada.

Obrigado Ch

Active Directory e senhas antigas voltando válidos (15 minutos a + - hora). Isso ocorre quando SetPassword ou ChangePassword são invocados.

História:

Eu acho que isso é chamado de “recurso” de AD e é por design construído em AD de modo que quando um usuário muda senhas Há uma espécie de período de carência que permite que todos os recursos que usam essas senhas para transferir para o novo .

Um exemplo de AD que suporta o conceito que AD sabe a última senha é a de mudar a senha de login em um PC - neste caso, o computador não vai permitir que a senha antiga para login. Enquanto eu não tenho a resposta para isso (que não seja a Microsoft teve que chegar a este trabalho) é minha opinião que isso não é tão simples como pode parecer como o PC está envolvido e tem senhas nele também.

Um exemplo mostrando como as mudanças de senha no AD fazer duram por um período de tempo pode ser:

Usando o Remote Desktop a partir de um PC com Windows 7 para uma caixa de Windows Server 2008 R2. Entrada da Caixa de Segurança do Windows, em seguida, o, clique aparece caixa OK, clique em OK e você está logado. Agora mude sua senha para o usuário que utilizou para remoto na caixa com (diferente do seu usuário Kirkman ??), logout e login novamente com senha de idade (dentro do prazo de 15 minutos a uma hora + -). A senha antiga irá começar após a caixa de Segurança do Windows e para a Caixa OK. Ao clicar em OK ele irá falhar. Se você começar de novo a partir de Remote Desktop e tente uma senha ruim você será parado na Caixa de Segurança do Windows com a mensagem “A tentativa de logon falhou”. Após o prazo expirar, você não vai passar a caixa de segurança do Windows com a senha antiga. (Certifique-se de começar a partir de Remote Desktop cada vez NÃO alternar usuários que atuarão como esperado que também mostra que o PC envolvido de alguma forma). Pelo menos ele não o login do usuário - mas isso mostra que (o que parece ser AD) em algum nível permite que senhas antigas para autenticar a algum nível

.

Research: Eu encontrei muitas referências a este problema e apenas uma solução potencial que a este ponto eu não tenho sido capaz de determinar se podemos implementá-lo (isto é a referência para chamar estritamente via Kerberos e não NTLM que não é tão simples como pode aparecem de acordo com a documentação e minha pesquisa). Tenho encontrado muitos links para a forma de interagir com o AD em .NET, mas nenhum manual AD real.

Solução Solução SOLUÇÃO - Leia esta parte se você quiser a solução SOLUÇÃO !!! Presente: Eu descobri (por acidente durante os testes) que a chamada ChangePassword a AD não permitirá que o OldPassword passado para ele ter sucesso em mudar a senha para a nova senha. É minha opinião que este teste que faz o trabalho não é realmente conhecida como eu não encontrei nenhuma referência a ele está sendo usado. Na verdade, eu não encontrei nenhuma solução para este problema. Uma manhã às 3:00 da manhã eu percebi que eu poderia explorar esta uso de ChangePassword para fornecer uma solução para este problema -., Pelo menos, uma forma de contornar podemos usar imediatamente até que possamos determinar a melhor abordagem

Primeiro eu verificar se está tudo retornos válidos e AD que a senha é válida. Em seguida, uma chamada para ChangePassword (nome de usuário, oldpassword, newpassword) com o oldpassword e newpassword como senha fornecida pelo usuário (ambos o mesmo) é feito. Eu sei que um dos dois (possivelmente três, mas os pasespada violação da política impede de sucesso) os resultados vai acontecer. Ou o OldPassword é bom e nós falham porque a política de senha não for cumprida (história, nova senha não pode ser uma das senhas últimos N) ou falhamos porque a senha antiga está incorreta (ambos retornado como erro de exceção com texto em mensagem). Nós verificamos para esta última condição e se o oldpassword não é válido nós não deixamos o registo de utilizador no.

Future: Talvez um segundo par de olhos vai ajudar.
Acho que a solução está na representação ou Kerberos. Eu não tive sucesso em descobrir o suficiente sobre qualquer um destes como soluções. É óbvio que a AD pode diferenciar entre senhas antigas porque o ChangePassword faz. O que estamos fazendo é o cerne de segurança para que nem tudo está aberto (como a capacidade de ver a história senha no AD, eu não encontrei uma maneira de acessá-lo).

Answer 4

Você tomou a até 15 minutos de tempo em conta que AD requer para propagar mudanças como essa em toda a rede ??

Marc

Answer 5

Eu suponho que você está ValidateCredentials executado em uma máquina cliente. Se for esse o caso, então ele tem a senha antiga (bem sucedida) em cache. Isto é feito para permitir que os usuários façam login, se o Active Directory está offline ou inacessível. Propagar alterações leva algum tempo.

Se você deseja obter em torno isso, você deve autenticar com o servidor servir o Webservice em tempo de autenticação em vez da máquina do cliente local.