permissões para alteração de senha da conta local remota do VBScript / ADSI

1

Estou usando as páginas IISADMPWD no IIS8 / Windows 2012 e descobri que os direitos administrativos em um servidor remoto para alterações de senha não são necessários. Espero que alguém possa esclarecer por quê. Como esperado, se eu tentar net user username newpassword , obtenho acesso negado como um usuário comum (não como administrador local). Aqui está minha configuração:

  • Todos os servidores que executam a GUI mínima do Windows 2012 em uma configuração de grupo de trabalho.
  • Correspondendo nomes de usuários locais em cada servidor com senhas idênticas.
  • O nome de usuário é um usuário comum (membro do grupo Usuários) no servidor de origem e de destino; somente a associação de grupo adicional é IIS_IUSRS no servidor de origem para executar o pool de aplicativos que hospeda o IISADMPWD.
  • na página IISADMPWD, eu especifico remote.server\username e as senhas antiga e nova.
  • na página achg.asp, esse código está fazendo o trabalho pesado de alterar senhas:
    • set pUser = GetObject("WinNT://" & domain & "/" & username & ",user")
    • pUser.ChangePassword Request.Form("old"), Request.Form("new")

Minha pergunta é que, quando a conta que estou usando para executar o pool de aplicativos (e, portanto, executar o VBScript) é um membro apenas do grupo Usuários no servidor de destino, a senha é alterada. Tenho a impressão de que apenas os administradores locais podem alterar senhas em contas locais, mas esse "teste" parece dobrar as regras.

Eu segui a transação usando o Wireshark e posso ver o tráfego ultrapassando 445 / tcp, incluindo as etapas de autenticação do SMB2 usando o nome de usuário executando o pool de aplicativos, mas a maior parte do tráfego é DCERPC e não é legível, pelo menos para mim.

Ao examinar o log de eventos de Segurança, quando o IISADMPWD está sendo usado para alterar a senha, vejo o tráfego de autenticação remota sendo registrado e a ID de Evento 4723 do Gerenciamento de Conta de Usuário, mas nada mais. Quando executo net user para alterar a senha, vejo as IDs de Eventos 4738 e 4724 indicando que a alteração da senha foi bem-sucedida.

Todas as pessoas com familiaridade suficiente com as partes internas do Windows têm alguma ideia ou razões pelas quais o requisito de administrador comum parece ser contornado? Eu olhei através de gpresult / h e não fiz nenhuma alteração nas configurações padrão de Segurança ou (qualquer) GPO.

**** Editar ****

Fiz alguns testes adicionais e parece que somente a alteração de senha é permitida. Definir senha ainda dá a esperada mensagem de erro Acesso negado. FYI, testar com [ADSI] objetos em Powershell foi bom e fácil.

Não que isso seja muito importante, mas eu executei o ProcMon durante meus testes e basicamente todas as alterações de tráfego de rede e de registro (para o SAM da senha) são feitas por serviços executados como SYSTEM. Parece haver autenticação acontecendo no nível SMB (dadas as minhas capturas anteriores do Wireshark), mas não vejo evidência em nenhum lugar de verificação de direitos.

Existe documentação em qualquer lugar que declare ou mencione a capacidade de alterar as senhas de outros usuários se a senha atual for conhecida?

    
por jrtolle 29.04.2014 / 22:35

0 respostas