A TI precisaria da senha de domínio de um usuário?

Existe algo que um administrador de domínio do Windows precise fazer ao configurar uma estação de trabalho para um novo usuário que absolutamente não pode ser feito sem a senha da conta de domínio do usuário? Para evitar solicitar as senhas dos usuários, o administrador poderia, teoricamente, alterar a senha, fazer login como usuário e fazer o que quisesse, mas isso realmente lhes daria permissões adicionais que eles ainda não possuem? virtude de ser um administrador de domínio?

ATUALIZAR:

As respostas até agora se referiram a "ajuste" ou alteração do perfil do usuário. No entanto, existe este artigo da Microsoft sobre a modificação do perfil padrão que é aplicado aos usuários quando eles fazem logon pela primeira vez e estas instruções para alterar as configurações de registro do Windows de outro usuário a qualquer momento. O que um administrador alteraria durante o login como usuário que não poderia mudar usando essas ou outras técnicas disponíveis que não envolvem o login como usuário? Apenas "fazer login como usuário" não é um motivo para solicitar ou alterar a senha do usuário. Estou procurando uma razão prática para fazer isso.

Não é aceitável nem necessário para um administrador solicitar a senha de um usuário.

Sob as circunstâncias em que pode ser necessário que um administrador efetue login como usuário (e não acredito que tais circunstâncias existam), o usuário deve efetuar login e supervisionar as atividades do administrador.

A razão para isso é a prestação de contas. É de responsabilidade de cada usuário garantir que sua senha seja segura. Se a atividade maliciosa for rastreada até as credenciais do usuário, esse usuário poderá ser responsabilizado. Portanto, eles precisam garantir que suas credenciais permaneçam seguras.

Também é responsabilidade da organização garantir que isso não seja apenas adotado, mas imposto. Houve um caso legal em que alguém em uma organização enviou um email malicioso usando a caixa de correio de outra pessoa. O proprietário da caixa de correio foi finalmente demitido. Embora eles argumentassem que haviam dado sua senha a outra pessoa, a empresa insistia em que era sua responsabilidade manter a integridade de suas credenciais e, portanto, eles eram responsáveis, conforme exigido pela política de TI da empresa. Isso foi anulado por um tribunal quando esse usuário provou que havia uma cultura de compartilhamento de senha endêmica na organização. O tribunal decidiu que, se a empresa não pudesse impor ativamente sua política de TI, não poderia confiar nela para prestar contas nessas circunstâncias.

Dito isto, há claramente um abismo entre teoria e prática. Contratei uma grande empresa multinacional que fornece, entre outras coisas, serviços de consultoria de TI e, como parte do procedimento documentado para uma atualização de SOE, fomos instruídos a solicitar a senha do usuário final.

Pessoalmente, adoto uma abordagem rígida para isso. Não acredito que seja necessário solicitar senhas (ou redefini-las para acessar a conta de um usuário). Se houver uma carga de trabalho muito maior para contornar isso, que assim seja. Não é desculpa para comprometer a segurança. Acho que tenho sorte de não ser gerente e, portanto, não preciso assumir a responsabilidade por essas decisões quando instruído a fazê-lo por alguém do alto escalão.

Sejamos claros: se você é um administrador de domínio, pode instalar um software - um driver de dispositivo vem à mente - que pode literalmente fazer qualquer coisa. No entanto, existem vários graus de impraticabilidade, variando de "Qual é a chave do Registro para o plano de fundo da área de trabalho, novamente?" até "E então ligamos para a chamada de leitura de arquivo dentro da camada de perfil criptografado, a fim de enganar o Firefox pensando que eles desativaram os cookies do doubleclick.net".

Você está pedindo um absoluto, e acho que é a maneira errada de ver isso, porque a resposta será "Você nunca precisa da senha do usuário, na verdade ", o que é muito enganador. A realidade é que, até que a Microsoft ofereça (ou você instale software de terceiros para permitir) um recurso como * NIX su/ sudo, você nunca será capaz de imitar perfeitamente a conta de um usuário para todos os fins, mantendo uma aparência de sanidade, sem exigir ocasionais uso - note que eu não disse "divulgação!" - de sua senha.

Muitos de nós trabalhamos em ambientes onde a divulgação de senhas era necessária por vários motivos. Vou até dizer que todos consideramos uma má idéia. Se isso precisar ser feito, o usuário final precisará consentir, não ser coagido.

Naquela época, como 1998, meu departamento de TI solicitava a senha de um usuário quando estávamos substituindo um PC, para que pudéssemos configurá-la exatamente como na antiga. Até os locais dos ícones. Como estávamos em um ambiente Novell NetWare sem domínio WinNT correspondente, a alteração da senha de rede não mudou a senha local; portanto, precisávamos ter essa senha se desejássemos oferecer esse nível de serviço contínuo.

Isso foi há 13 anos. Você perguntou especificamente sobre os domínios do Windows. No trabalho que acabei de deixar, uma grande universidade, cabia ao usuário final divulgar ou não uma senha ou estar presente para qualquer trabalho que estivesse sendo realizado. Em outras palavras, o usuário final optou por ele em vez de ser forçado pela TI. Certos tipos de executivos muito ocupados, no alto do organograma, geralmente tinham o assistente do administrador para fazer o login, portanto era fácil para as pessoas de TI entrar (o consentimento já havia sido delegado).

No Windows, a única maneira de ajustar manualmente o perfil de um usuário é fazer login como esse usuário. Se esse perfil precisar de ajuste manual por algum motivo (ainda resta uma desinstalação ruim que está atrapalhando a reinstalação ou outras coisas estranhas), a pessoa de TI precisará fazer login como esse usuário. Isso pode ser feito forçando uma alteração de senha administrativa, solicitando que o usuário divulgue sua senha ou solicitando que o usuário efetue o logon da pessoa de TI e deixe a pessoa de TI trabalhar.

Alguns aplicativos durante a instalação exigem a capacidade de fazer alterações ou referenciar o perfil do usuário (ou seja, aplicativos de CRM que se integram ao Outlook) usando variáveis ​​ambientais como% userprofile%, modificando HK_CURRENT_USER e similares.

Embora você possa "fazer engenharia reversa" de uma instalação com ferramentas como procmon e modificar manualmente o perfil, o registro etc. do usuário após o fato, isso é altamente ineficiente, impraticável e propenso a erros.

Absolutamente 100% não. Qualquer coisa que precise ser feita com outra conta de usuário deve ser feita redefinindo a senha do usuário, efetuando login e, em seguida, solicitando que o usuário ligue para o suporte técnico ou restaurando a senha para algo que seja útil aos usuários, e informando e configurando a conta para forçar a alteração da senha no próximo login. Embora admitir que trabalhei em ambientes razoavelmente grandes e / ou seguros, a divulgação de sua senha a qualquer pessoa era geralmente motivo para rescisão (e esse deve ser o caso na maioria das situações)

A maioria dessas postagens parece bastante antiga, mas espero que algumas pessoas com conhecimento ainda estejam ativas no tópico, pois esse parece continuar sendo um tópico atual.

Certamente, pode-se argumentar que você nunca precisará solicitar uma senha. Eu preferiria dizer aos meus usuários "nunca compartilhem" ... e sim, na maioria dos casos , a configuração pode ser gerenciada por um administrador para um usuário. Mas a solução de problemas é outro caso.

Apoiamos um programa individual com 2600 alunos e 500 funcionários. Nós lidamos com problemas de software "estranhos" diariamente. Frequentemente, precisamos enfrentar o problema como usuário para resolver o problema (ou determinar com alguma confiança que será necessário recarregar). Absolutamente, tentamos fazer isso com o usuário presente - mas isso nem sempre é prático; eles têm um cronograma para manter.

E os cartões inteligentes? Existe alguma viabilidade no ambiente do AD 2010/2012 de que um cartão inteligente possa estar associado (temporariamente) a uma conta de domínio? Isso permitiria o acesso à conta do usuário em plena realidade, sem expor sua senha especificamente. O cartão pode então ser desativado quando a solução de problemas estiver concluída. Técnicos poderiam utilizar a conta, mas os cartões poderiam ser bem supervisionados.

Usamos leitores de impressão digital há anos, mas o processo de configuração para uma tecnologia específica e a limpeza da impressão simplesmente não é viável. Não tenho certeza de quão complexo seria o processo de "autorizar" e "desativar" um cartão inteligente para um usuário específico, mas parece que poderia ser um compromisso decente.

Sim: tudo o que precisa ser feito em seu perfil. Quando isso acontece, você deve saber sua senha ou configurá-la, como disse. Então eles podem mudar quando você terminar.

Se você efetuar login como esse usuário, não estará concedendo permissões adicionais. Você está efetuando login como eles com suas permissões.