Estou usando um cliente ssh para fazer login em um servidor e emitir comandos de alteração de senha no prompt. O problema ocorre ao tentar fazer isso no servidor de domínio. Efetuo login usando uma conta de administrador (não a conta de administrador) e tento alterar a senha de um usuário (usuário da rede UserName senha /domínio) e recebo o seguinte erro:
Ocorreu um erro de sistema 5.
Acesso negado.
Agora, se eu fizer login usando a conta de administrador, o comando será concluído com êxito. Portanto, deve haver alguma política ou permissão de segurança em algum lugar que permita que a conta do administrador faça o que a conta do administrador não pode. Comparei grupos e a conta de administrador faz parte de todos os grupos necessários. Alguma informação sobre onde isso pode estar localizado?
Responder1
Mesmo que você diga que verificou as associações ao grupo, realmente parece que sua conta “administrador” não tem as mesmas associações ao grupo que a conta “Administrador”.
O "whoami.exe" do Windows (não o whoami do Cygwin) com o parâmetro "/ALL" mostrará as associações de grupo de cada usuário para que você possa compará-las.
(Em teoria, seria possível modificar as permissões dos objetos de usuário no AD para negar ao usuário "admin" direitos de alterar sua senha e ainda ter "admin" como membro dos mesmos grupos de "Administrador", mas acho que isso é altamente improvável.)
Para descartar completamente qualquer coisa relacionada ao SSH do cygwin, por que não fazer logon localmente no computador do servidor com a credencial "admin" e tentar seu "NET USER" em um prompt de comando do NT?
Editar:
Na verdade, não existe nenhum tipo de configuração de política de grupo que afete a capacidade de alterar senhas, por si só. Se a sua conta "admin" for membro de "Administradores corporativos", ela poderá redefinir a senha de qualquer outra conta no Active Directory. Como eu disse acima, existem "ajustes" que alguém poderia ter feito no AD que mudariam esse comportamento, mas acho altamente improvável que algo disso tivesse sido feito. Acho que algo mais está acontecendo.
Se você não tiver a auditoria de falha de eventos de gerenciamento de contas ativada, agora é um bom momento para criar um novo GPO vinculado à sua unidade organizacional "Controladores de domínio" (o preferencial) ou modificar seu GPO "Controladores de domínio padrão" (não preferencial). - você realmente deve deixar esse "estoque" do GPO e ativar a auditoria de falha de evento de gerenciamento de contas. Vá em "Configuração do computador", "Configurações do Windows", "Configurações de segurança", "Políticas locais" e "Política de auditoria" e ative auditoria de falhas em "Gerenciamento de contas".
Execute um "gpupdate" em seus computadores controladores de domínio, tente seu "NET USER" novamente e examine o log de eventos de segurança em todos os seus controladores de domínio para ver qual deles está registrando a falha na alteração da senha.
Estou ansioso para descobrir o que está acontecendo. Como eu disse, espero que seja algo simples que esteja sendo esquecido... Veremos...
Responder2
A primeira conta de administrador tem associação ao grupo Administrador de Domínio ou Operador de Conta no domínio? Ou tem direito delegado para redefinir a senha da conta do usuário? Como você está especificando /domain, a alteração está sendo feita em uma conta de usuário do domínio, portanto, os direitos precisarão estar no nível do domínio.
Responder3
Depois de muitos anos tentando rastrear esse tipo de problema, hoje em dia, se eu quiser criar uma conta "admin", sempre faço isso copiando a conta do Administrador. Em Usuários e Computadores AD, clique com o botão direito na conta Administrador e escolha "Copiar". Economiza muito tempo!
É discutível se é uma boa prática ter várias contas de administrador ...
Jr.
Responder4
Usuário da rede? Ecawww. Você deveria estar usandoDSMOD.
DSMOD user userDN -pwd newPassword -d yourDomain.loc -u yourDomain\yourAdminUserAcct
Se você não sabe o que é o userDN, use isto:
DSQUERY user -name userName -d yourDomain.loc -u yourDomain\yourAdminUserAcct
Se quiser ser sofisticado, você pode canalizar o resultado do DSQUERY diretamente para o DSMOD, assim:
DSQUERY user -name userName -d yourDomain.loc -u yourDomain\yourAdminUserAcct | DSMOD user -pwd newPassword -d yourDomain.loc -u yourDomain\yourAdminUserAcct
Se você quiser definir oO usuário deve mudar a senha na próxima autenticaçãobandeira e, em seguida, adicione-mustchpwd simpara a string do argumento DSMOD, assim:
DSQUERY user -name userName -d yourDomain.loc -u yourDomain\yourAdminUserAcct | DSMOD user -pwd newPassword -d yourDomain.loc -u yourDomain\yourAdminUserAcct -mustchpwd yes