L'IT avrebbe mai bisogno della password del dominio di un utente?

C'è qualcosa che un amministratore di dominio Windows potrebbe dover fare durante la configurazione di una workstation per un nuovo utente che non può assolutamente essere fatto senza la password dell'account di dominio dell'utente? Per evitare di chiedere agli utenti le loro password, l'amministratore potrebbe, in teoria, cambiare la password, accedere come utente e fare tutto ciò che vogliono fare, ma ciò darebbe loro effettivamente eventuali autorizzazioni aggiuntive che non hanno già virtù di essere un amministratore di dominio?

AGGIORNARE:

Le risposte finora hanno fatto riferimento a "tuning" o modifica del profilo dell'utente. Tuttavia, c'è questo articolo di Microsoft sulla modifica del profilo predefinito che viene applicato agli utenti quando accedono per la prima volta e queste istruzioni per modificare le impostazioni del registro di Windows di un altro utente in qualsiasi momento. Che cosa cambierebbe un amministratore durante l'accesso come utente che l'amministratore non potrebbe cambiare usando queste o altre tecniche disponibili che non comportano l'accesso come utente? Il solo "accesso come utente" non è un motivo per chiedere o modificare la password dell'utente. Sto cercando un motivo pratico per farlo.

Non è accettabile né necessario che un amministratore richieda la password di un utente.

Nelle circostanze in cui potrebbe essere necessario per un amministratore accedere come utente (e non credo che tali circostanze esistano), l'utente dovrebbe accedere e supervisionare le attività dell'amministratore.

La ragione di ciò è la responsabilità. È responsabilità di ciascun utente assicurarsi che la propria password sia protetta. Se l'attività dannosa fosse ricondotta alle credenziali di un utente, tale utente potrebbe essere ritenuto responsabile. Pertanto, devono garantire che le loro credenziali rimangano sicure.

È anche responsabilità dell'organizzazione garantire che ciò non sia solo adottato, ma applicato. C'è stato un caso legale in cui qualcuno in un'organizzazione ha inviato un'email malevola utilizzando la cassetta postale di qualcun altro. Il proprietario della cassetta postale è stato infine licenziato. Mentre sostenevano di aver dato la propria password a qualcun altro, la società ha insistito sul fatto che era loro responsabilità mantenere l'integrità delle proprie credenziali e quindi erano responsabili, come dettato dalla politica IT della propria azienda. Ciò è stato poi annullato da un tribunale quando questo utente ha dimostrato che all'interno dell'organizzazione esisteva una cultura della condivisione delle password endemica. Il tribunale ha stabilito che se la società non fosse in grado di far rispettare attivamente la propria politica IT, in tali circostanze non avrebbe potuto fare affidamento su di essa per la responsabilità.

Detto questo, c'è chiaramente un abisso tra teoria e pratica. Ho stipulato un contratto con un'importante società multinazionale che fornisce, tra le altre cose, servizi di consulenza IT e, come parte della procedura documentata per un aggiornamento SOE, ci è stato chiesto di richiedere la password dell'utente finale.

Personalmente, seguo un approccio rigoroso a questo. Non credo che richiedere password (o reimpostarle per accedere all'account di un utente) sia necessario. Se c'è un carico di lavoro notevolmente aumentato per aggirare questo, allora così sia. Non è una scusa per compromettere la sicurezza. Immagino di essere semplicemente fortunato a non essere un manager, quindi non devo assumermi la responsabilità di queste decisioni quando gli viene richiesto da qualcuno di livello superiore.

Cerchiamo di essere chiari: se sei un amministratore di dominio, puoi installare un software - mi viene in mente un driver di dispositivo - che può letteralmente fare qualsiasi cosa. Tuttavia, può essere poco pratico, a partire da "Qual è la chiave di registro per lo sfondo del desktop?" fino a "E poi ci agganciamo al file read call all'interno del livello del profilo crittografato in modo da falsificare Firefox facendogli credere che abbiano disabilitato i cookie da doubleclick.net".

Stai chiedendo un assoluto, e penso che sia il modo sbagliato di guardare a questo, perché la risposta sarà "Non hai mai bisogno della password dell'utente, davvero ", il che è molto fuorviante. La realtà è che fino a quando Microsoft non fornirà (o installerai software di terze parti per consentire) una funzionalità come * NIX su/ sudo, non sarai mai in grado di imitare perfettamente l'account di un utente per tutti gli scopi mantenendo una parvenza di sanità mentale, senza richiedere occasionali Nota sull'utilizzo non ho detto "divulgazione!" della loro password.

Molti di noi hanno lavorato in ambienti in cui era richiesta la divulgazione di password per vari motivi. Vado persino al punto di dire che tutti noi la consideriamo una cattiva idea. Se ciò deve essere fatto, l'utente finale deve acconsentire, non essere costretto.

In passato, come nel 1998, il mio dipartimento IT richiedeva la password di un utente quando stavamo facendo una sostituzione del PC in modo da poterlo impostare esattamente come avevano la loro vecchia. Fino alle posizioni delle icone. Dato che ci trovavamo in un ambiente Novell NetWare senza un dominio WinNT corrispondente, la modifica della password di rete non ha cambiato la password locale, quindi se avessimo voluto fornire quel livello di servizio continuo avremmo dovuto disporre di quella password.

È successo 13 anni fa. Hai chiesto informazioni specifiche sui domini Windows. Al lavoro che ho appena lasciato, una grande università, spettava all'utente finale se rivelare o meno una password o essere lì per qualsiasi lavoro fosse svolto. In altre parole, l'utente finale ha optato per questo piuttosto che forzato dall'IT. Alcuni tipi esecutivi molto impegnati in cima all'organigramma generalmente avevano il loro assistente di amministratore che li accedeva, quindi era facile per le persone IT scivolare (il consenso era già stato delegato).

In Windows, l'unico modo per ottimizzare il profilo di un utente è accedere come tale utente. Se per qualche motivo quel profilo necessita di un adattamento manuale (rimane una disinstallazione non valida che sta ostacolando la reinstallazione o altre cose strane), la persona IT dovrà accedere come tale utente. Questo può essere fatto forzando una modifica della password amministrativa, facendo in modo che l'utente divulga la propria password o facendo in modo che l'utente acceda alla persona IT come se stessa e lasci che la persona IT lavori.

Alcune applicazioni durante l'installazione richiedono la possibilità di apportare modifiche o fare riferimento al profilo dell'utente (ad esempio applicazioni CRM che si integrano con Outlook) utilizzando variabili ambientali come% userprofile%, modificando HK_CURRENT_USER e simili.

Sebbene si possa certamente "decodificare" un'installazione con strumenti come procmon e poi modificare manualmente il profilo dell'utente, il registro, ecc. Dopo il fatto, questo è altamente inefficiente, poco pratico e soggetto a errori.

Assolutamente no al 100%. Tutto ciò che deve essere fatto con un altro account utente dovrebbe essere fatto reimpostando la password dell'utente, effettuando il login e quindi facendo in modo che l'utente chiami l'helpdesk o reimpostando la password su qualcosa che gli viene detto agli utenti e impostando l'account per forzare la modifica della password al prossimo accesso. Pur ammettendo di aver lavorato in ambienti abbastanza grandi e sicuri, la divulgazione della password a chiunque di solito è stata motivo di risoluzione (e questo dovrebbe accadere nella maggior parte delle situazioni)

La maggior parte di questi post sembra piuttosto vecchia, ma si spera che alcune persone esperte siano ancora attive sul thread, dal momento che questo sembra continuare a essere un argomento attuale.

Si può certamente sostenere che non dovresti mai richiedere una password. Preferirei di gran lunga dire ai miei utenti "non condividere mai" ... e sì, nella maggior parte dei casi la configurazione può essere gestita da un amministratore per un utente. Ma la risoluzione dei problemi è un'altra cosa.

Supportiamo un programma individuale con 2600 studenti e 500 dipendenti. Ci occupiamo quotidianamente di problemi software "strani". È abbastanza frequente che si debba verificare il problema come utente per risolverlo (o determinare con una certa sicurezza che sarà necessario un ricaricamento). Assolutamente, proviamo a farlo con l'utente presente - ma non è sempre pratico; hanno un programma da mantenere.

E le smart card? Esiste la fattibilità in un ambiente AD 2010/2012 che una smartcard possa essere associata (temporaneamente) a un account di dominio? Ciò consentirebbe l'accesso all'account dell'utente in tutta la realtà, senza esporre in modo specifico la password. La scheda potrebbe quindi essere disattivata al termine della risoluzione dei problemi. I tecnici potrebbero utilizzare l'account, ma le carte potrebbero essere ben controllate.

Abbiamo usato i lettori di impronte digitali per anni, ma il processo per configurarlo per una tecnologia specifica, quindi cancellare quella stampa semplicemente non è fattibile. Non sono sicuro di quanto sarebbe complesso il processo di "autorizzazione" e quindi di "disattivazione" di una smart card per un determinato utente, ma sembra che potrebbe essere un discreto compromesso.

Sì: tutto ciò che deve essere fatto per il loro profilo. Quando ciò accade, devi conoscere la loro password o impostarla, come hai detto. Quindi possono cambiarlo quando hai finito.

Se accedi come quell'utente, non stai concedendo loro ulteriori autorizzazioni. Stai accedendo come loro con le loro autorizzazioni.