Acesso negado usando o comando NET USER via sessão SSH

1

Estou usando um cliente ssh para efetuar login em um servidor para emitir comandos de alteração de senha a partir do prompt. O problema ocorre ao tentar 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 de rede UserName password / domain) e recebo o seguinte erro:

Erro de sistema 5 ocorreu.

O acesso é negado.

Agora, se eu fizer login usando a conta de administrador, o comando será concluído com êxito. Portanto, deve haver alguma permissão de política ou segurança em algum lugar que permita que a conta de administrador faça o que a conta de administrador não pode. Eu comparei grupos e a conta de administrador faz parte de todos os grupos necessários. Alguma entrada para onde isso poderia estar localizado?

    
por Evan Anderson 08.07.2009 / 18:35

5 respostas

2

Mesmo que você diga que verificou as associações a grupos, realmente parece que sua conta "admin" não tem as mesmas associações de grupo que a conta "Administrador".

O Windows "whoami.exe" (não o Cygwin whoami) com o parâmetro "/ ALL" mostrará as afiliações de grupo de cada usuário para que você possa compará-las.

(Em teoria, seria possível modificar as permissões de objetos de usuário no AD para negar aos usuários de "admin" direitos para alterar suas senhas e ainda ter "admin" membros do mesmo grupo que "Administrador", mas Eu acho que é altamente improvável.)

Para descartar qualquer coisa a ver com o cygwin SSH, por que não fazer logon localmente no servidor comuter com a credencial "admin" e tentar o seu "NET USER" a partir de um prompt de comando do NT?

Editar:

Realmente não existe nenhum tipo de configuração de política de grupo que afeta a capacidade de alterar senhas, por si só. Se a sua conta "admin" for um membro de "Enterprise Admins", ela poderá redefinir a senha de qualquer outra conta no Active Directory. Como eu disse acima, há "ajustes" que alguém poderia ter feito na AD que mudariam esse comportamento, mas acho altamente improvável que algo disso tenha sido feito. Eu acho que algo mais está acontecendo.

Se você não tiver a auditoria de falha dos eventos de gerenciamento de conta habilitados, agora é um bom momento para criar um novo GPO vinculado à UO "Controladores de domínio" (o preferido) ou para modificar o GPO "Controladores de domínio padrão". (não é preferível - você realmente deixa o GPO "estoque") e ativa a auditoria de falhas de eventos do gerenciamento de contas. Vá até "Configuração do Computador", "Configurações do Windows", "Configurações de Segurança", "Políticas Locais" e "Política de Auditoria". "e habilitar a auditoria de falhas em" Gerenciamento de contas ".

Execute um "gpupdate" em seus controladores de domínio, experimente seu "NET USER" novamente e examine o Security Event Log em todos os seus DC's para ver qual deles está registrando a mudança de senha com falha.

Estou interessado em descobrir o que está acontecendo. Como eu disse, espero que seja algo simples que está sendo ignorado ... Vamos ver ...

    
por 08.07.2009 / 18:37
1

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 de Administrador. Em Usuários e Computadores do AD, clique com o botão direito do mouse na conta Administrador e escolha "Copiar". Economiza muito tempo!

Se é boa prática ter várias contas de administrador, é claro que é discutível ...

JR

    
por 08.07.2009 / 18:41
0

A primeira conta de administrador tem associação ao grupo de administradores de domínio ou de operadores de conta no domínio? Ou ele delegou o direito de redefinir a senha na 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.

    
por 08.07.2009 / 18:40
0

Sua conta de rede pode ser um administrador local para a máquina, mas você provavelmente não está no grupo Operador da conta. Com a opção / domain você nem precisa executá-la no servidor real, apenas a emita a partir de um prompt de comando com as credenciais apropriadas de qualquer computador no domínio.

    
por 08.07.2009 / 18:41
0

Usuário da rede? Ewwww . Você deveria estar usando DSMOD .

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 você quiser se interessar, você pode canalizar o resultado da DSQUERY direto para o DSMOD, da seguinte forma:

DSQUERY user -name userName -d yourDomain.loc -u yourDomain\yourAdminUserAcct | DSMOD user -pwd newPassword -d yourDomain.loc -u yourDomain\yourAdminUserAcct

Se você deseja definir o sinalizador Usuário deve alterar a senha no próximo login , adicione -mustchpwd yes à string de argumento DSMOD, da seguinte forma:

DSQUERY user -name userName -d yourDomain.loc -u yourDomain\yourAdminUserAcct | DSMOD user -pwd newPassword -d yourDomain.loc -u yourDomain\yourAdminUserAcct -mustchpwd yes
    
por 08.07.2009 / 20:05