O usuário não pode alterar a senha devido à complexidade

O usuário não pode alterar a senha devido à complexidade

Em um dos domínios filhos do meu cliente, ele tem o problema de que vários (parece) usuários aleatórios não conseguem alterar suas senhas devido à "complexidade, blá, blá". No entanto, isto não é verdade quando:

a) Um Administrador redefine para uma nova senha ou

b) o usuário tinha o sinalizador "deve redefinir a senha no logon"

O que eu tentei até agora:

  1. GPOs: existe apenas a política de domínio padrão com configurações de senha. As configurações são:

    • Comprimento de 10
    • Complexidade habilitada
    • o histórico está definido como 5, mas irrelevante neste caso (tentei senhas diferentes)
    • Todo o resto é indefinido ou 0
  2. Provedor de senha no PDC: li que você pode usar provedores de senha personalizados por meio do registro. Verifiquei com um domínio onde tudo funciona. Parece padrão. A única coisa que vi foi o cenário EveryoneIncludesAnonymous = 0.

  3. O usuário ainda não conseguiu alterar seu PW depois que criei um PSO para ele, com configuração que deve funcionar. Parecia que eles não foram aplicados.

  4. O CDP está disponível

  5. Set-ADAccountPasswordem um controlador de domínio também não funcionou.

  6. O descritor de segurança da conta do usuário parece bastante bom. Todos têm o direito de alterar a senha.

  7. No ADUC as propriedades do usuário estão ok. O usuário não pode alterar a senha = $false, etc.

Saída denet user /domain Myuser

User name                    cardm004
Full Name                    Cardman, Michael
Comment                      Test User
User's comment
Country/region code          000 (System Default)
Account active               Yes
Account expires              Never

Password last set            16.01.2017 13:14:58
Password expires             Never
Password changeable          15.02.2017 13:14:58
Password required            Yes
User may change password     Yes

Workstations allowed         All
Logon script                 login.cmd
User profile
Home directory
Last logon                   18.01.2017 08:14:01

Logon hours allowed          All

Local Group Memberships
Global Group memberships     *Domain Users
The command completed successfully.

Saída denet accounts

Force user logoff how long after time expires?:       Never
Minimum password age (days):                          0
Maximum password age (days):                          37201
Minimum password length:                              10
Length of password history maintained:                5
Lockout threshold:                                    Never
Lockout duration (minutes):                           30
Lockout observation window (minutes):                 30
Computer role:                                        Workstation

Estou sem ideias agora. O que eu poderia tentar descobrir por que os usuários não conseguem alterar suas senhas?

Atualizar

Descobri que a modelagem de políticas de grupo mostra configurações diferentes para usuários diferentes. A parte “configurações de senha” e “política de bloqueio de conta” não são mostradas para os usuários que não podem alterar suas senhas. Portanto, presumo que possa haver um problema de replicação nos controladores de domínio. Verifiquei o status de replicação com repadmin /showreple os resultados foram ok. Verifiquei o conteúdo do arquivo em sysvol em todos os três controladores de domínio e eles eram idênticos. Então, de alguma forma, os DCs estão atualizados, mas os computadores não recebem a configuração.

GPUpdate /forcee GPResult /r, ou GPResult /h file.htmlparecem bons e não mostram nenhum erro. Reiniciar depois GPUpdate /forcenão alterou o erro. GPResult /rmostra o site correto, e exibe uma conexão rápida, Default Domain Policy(onde as configurações são feitas) é exibido como aplicado.

Atualização 2 Criei um GPO adicional para definir as configurações de senha. Para isso criei uma UO, para onde movi o computador e a conta do usuário e vinculei esse GPO a enforced = $trueessa UO. GPResult /hmostra a configuração aplicada correta, Net user /domain testusernão. As configurações da política local são idênticas às do GPO.

O problema ainda ocorre.

Atualização 3 O cliente abriu um ticket na Microsoft. Eles ainda não têm uma solução, mas descobriram que parece haver um problema com o GP: o usuário e seu dispositivo foram movidos para uma UO separada para teste com herança desabilitada. Eles aplicaram um novo GPO com várias configurações de senha. GPResultmostrou as configurações atualizadas, mas o usuário ainda não conseguiu alterar sua senha.

Em seguida, removeram o link GP e habilitaram a herança novamente, as configurações do GPO de teste permaneceram no sistema. As configurações dePolítica de domínio padrãonão foram aplicadas (eram menores que no GPO de teste) e o usuário ainda não conseguiu alterar sua senha.

Vou mantê-los atualizados, talvez um de vocês se depare com esse problema um dia ou encontre uma solução antes da Microsoft.

Responder1

O erro IIRC é o erro genérico para qualquer problema de alteração de senha.

Com base no seu comentário de:

No entanto, isto não é verdade quando:

a) Um Administrador redefine para uma nova senha ou

b) o usuário tinha o sinalizador "deve redefinir a senha no logon"

Direi que o problema é que sua política de senha tem uma configuração para um Minimum Password Ageou Enforce Password Historyambos. Provavelmente o primeiro é o culpado aqui.

EDITAR:

Com base na sua atualização mais recente, você pode ver:

Password changeable 15.02.2017 13:14:58

Isso mostra que a senha não pode ser alterada por 30 dias.

Agora, você afirmou que a idade mínima da senha está definida como 0.

Isso me leva a duas conclusões possíveis:

  1. As contas ou as UOs estão bloqueando a herança da política... apesar de mostrar a política adequada com "contas líquidas", o usuário específico não parece estar conseguindo aplicá-la.

  2. Existem alguns DCs que estão bloqueando a herança e não obtendo as configurações adequadas. Veja aqui:https://community.spiceworks.com/topic/1838052-minimum-password-age-password-changeable

Verifique e verifique se não há nenhum bloqueio de GPO feito no GPMC. Em seguida, verifique e certifique-se de que o DC no qual o usuário está se autenticando, junto com seu computador e sua conta de usuário... todos os 3 têm "Incluir permissões herdáveis ​​do pai deste objeto".

Responder2

A saída do net user /domain Myusercomando atualmente reflete uma idade mínima de senha de 31 dias. Parece que você precisamodifique seu PSO para este usuário e defina a idade mínima da senha para 0 nesse objeto.

Além disso, você confirmou que o PSO foi aplicado com sucesso ao usuário ou grupo? Se for, você deverá ver um msDS-ResultantPSOatributo preenchido na conta do AD do usuário. Você pode verificar isso facilmente usando ADUC na guia de atributos ou executando os seguintes comandos do PowerShell:

Import-Module ActiveDirectory
Get-ADUser cardm004 -Properties msDS-ResultantPSO | FL

Por outro lado, a execução net accountsretornará as configurações paracontas de computadores locais. As configurações da conta local são definidas separadamente das configurações da conta de domínio.

Responder3

Sugestão estúpida, mas você verificou se a senha do usuário atende aos requisitos:

  1. As senhas não devem conter o nome completo do usuáriosamAccountNameValor (nome da conta) ou inteironome de exibiçãoValor (Nome Completo). Ambas as verificações não diferenciam maiúsculas de minúsculas:
    • OsamAccountNameé verificado em sua totalidade apenas para determinar se faz parte da senha. Se osamAccountNametiver menos de três caracteres, esta verificação será ignorada.
    • Onome de exibiçãoé analisado para delimitadores: vírgulas, pontos, travessões ou hífens, sublinhados, espaços, cerquilhas e tabulações. Se algum desses delimitadores for encontrado, onome de exibiçãoé dividido e todas as seções analisadas (tokens) são confirmadas para não serem incluídas na senha. Os tokens com menos de três caracteres são ignorados e as substrings dos tokens não são verificadas. Por exemplo, o nome “Erin M. Hagens” é dividido em três tokens: “Erin”, “M” e “Hagens”. Como o segundo token tem apenas um caractere, ele é ignorado. Portanto, esse usuário não poderia ter uma senha que incluísse "erin" ou "hagens" como substring em qualquer lugar da senha.
  2. As senhas devem conter caracteres de três das cinco categorias a seguir:
    • Caracteres maiúsculos de línguas europeias ( Aaté Z, com sinais diacríticos, caracteres gregos e cirílicos)
    • Caracteres minúsculos de idiomas europeus ( aaté z, sustenidos, com sinais diacríticos, caracteres gregos e cirílicos)
    • Base de 10 dígitos ( 0até 9)
    • Caracteres não alfanuméricos:~!@#$%^&*_-+=`|\(){}[]:;"',.?/
    • Qualquer caractere Unicode classificado como alfabético, mas que não seja maiúsculo ou minúsculo. Isto inclui caracteres Unicode de idiomas asiáticos

De acordo com:https://technet.microsoft.com/en-us/library/cc786468%28v=ws.10%29.aspx

Responder4

Honestamente, parece que você está encontrando uma política secundária de configuração de produto por meio de edições locais de GPO. Algo como ScriptLogic (também conhecido como Desktop Authority).

Alguns sintomas que você veria em PCs mais antigos seriam:

  1. Existência de SLStart ou wKiX32 no PC em system32 ou na raiz de C:.
  2. Se ele estivesse lá e fosse removido anteriormente, você veria que todos os programas instalados anteriormente nos PCs não aparecem em adicionar/remover programas.

Já faz... alguns anos. Alguma ideia de qual foi a solução?

informação relacionada