¿Alguna vez necesitará la contraseña de dominio de un usuario?

¿Hay algo que deba hacer un administrador de dominio de Windows al configurar una estación de trabajo para un nuevo usuario que no se pueda hacer sin la contraseña de la cuenta de dominio del usuario? Para evitar pedir a los usuarios sus contraseñas, el administrador podría, en teoría, cambiar la contraseña, iniciar sesión como usuario y hacer lo que sea que quisieran hacer, pero eso en realidad les daría permisos adicionales que aún no tienen virtud de ser un administrador de dominio?

ACTUALIZAR:

Las respuestas hasta ahora se han referido a "afinar" o cambiar el perfil del usuario. Sin embargo, existe este artículo de Microsoft sobre la modificación del perfil predeterminado que se aplica a los usuarios cuando inician sesión por primera vez y estas instrucciones para cambiar la configuración del registro de Windows de otro usuario en cualquier momento. ¿Qué cambiaría un administrador mientras está conectado como usuario que el administrador no podría cambiar usando estas u otras técnicas disponibles que no implican iniciar sesión como usuario? Simplemente "iniciar sesión como usuario" no es una razón para pedir o cambiar la contraseña del usuario. Estoy buscando una razón práctica para hacerlo.

No es aceptable ni necesario que un administrador solicite la contraseña de un usuario.

En las circunstancias en que puede ser necesario que un administrador inicie sesión como usuario (y no creo que existan tales circunstancias), el usuario debe iniciar sesión y supervisar las actividades del administrador.

La razón de esto es la responsabilidad. Es responsabilidad de cada usuario asegurarse de que su contraseña sea segura. Si la actividad maliciosa se remonta a las credenciales de un usuario, ese usuario podría ser considerado responsable. Por lo tanto, deben asegurarse de que sus credenciales permanezcan seguras.

También es responsabilidad de la organización asegurarse de que esto no solo se adopte, sino que se haga cumplir. Hubo un caso legal en el que alguien de una organización envió un correo electrónico malicioso utilizando el buzón de otra persona. El propietario del buzón fue finalmente despedido. Si bien argumentaron que le habían dado su contraseña a otra persona, la compañía insistió en que era su responsabilidad mantener la integridad de sus credenciales y, por lo tanto, eran responsables, como lo dictaba la política de TI de su compañía. Esto fue revocado por un tribunal cuando este usuario demostró que había una cultura de intercambio de contraseñas endémicas dentro de la organización. El tribunal dictaminó que si no se podía ver a la compañía hacer cumplir activamente su política de TI, no podían confiar en ella para la rendición de cuentas en estas circunstancias.

Dicho esto, claramente hay un abismo entre la teoría y la práctica. Contraté a una importante empresa multinacional que brinda, entre otras cosas, servicios de asesoramiento de TI, y como parte del procedimiento documentado para una actualización SOE, se nos indicó que solicitemos la contraseña del usuario final.

Personalmente, adopto un enfoque de línea dura para esto. No creo que sea necesario solicitar contraseñas (o volver a configurarlas para acceder a la cuenta de un usuario). Si hay una carga de trabajo enormemente aumentada para evitar esto, entonces que así sea. No es excusa para comprometer la seguridad. Supongo que soy afortunado de no ser un gerente, por lo que no tengo que asumir la responsabilidad de estas decisiones cuando alguien más alto me lo indique.

Seamos claros: si usted es un administrador de dominio, puede instalar una pieza de software, se le ocurre un controlador de dispositivo, que literalmente puede hacer cualquier cosa. Sin embargo, es poco práctico, desde "¿Cuál es la clave de registro para el fondo de escritorio?" todo el camino hasta "Y luego nos conectamos a la llamada de lectura de archivo dentro de la capa de perfil cifrado para engañar a Firefox para que piense que han deshabilitado las cookies de doubleclick.net".

Estás pidiendo un absoluto, y creo que esa es la forma incorrecta de ver esto, porque la respuesta será "Nunca necesitas la contraseña del usuario, realmente ", lo cual es muy engañoso. La realidad es que hasta que Microsoft entregue (o instale un software de terceros para permitir) una capacidad como * NIX's su/ sudo, nunca podrá imitar perfectamente la cuenta de un usuario para todos los propósitos mientras mantiene una apariencia de cordura, sin requerir ocasionales uso - nota No dije "divulgación" - de su contraseña.

Muchos de nosotros hemos trabajado en entornos donde se requería la divulgación de la contraseña por varias razones. Incluso iré tan lejos como para decir que todos lo consideramos una mala idea. Si es necesario hacerlo, el usuario final debe consentirlo, no ser forzado.

En el pasado, como 1998, mi departamento de TI solía solicitar la contraseña de un usuario cuando estábamos haciendo un reemplazo de PC para poder configurarlo exactamente como tenían la anterior. Abajo a las ubicaciones de los iconos. Como estábamos en un entorno Novell NetWare sin el dominio WinNT correspondiente, cambiar su contraseña de red no cambió su contraseña local, por lo que necesitábamos tener esa contraseña si queríamos ofrecer ese nivel de servicio sin interrupciones.

Eso fue hace 13 años. Usted preguntó específicamente sobre los dominios de Windows. En el trabajo que acabo de dejar, una gran universidad, dependía del usuario final si revelar o no una contraseña o estar allí para cualquier trabajo que se estuviera haciendo. En otras palabras, el usuario final optó por él en lugar de ser forzado por TI. Ciertos tipos ejecutivos muy ocupados en la parte superior del organigrama general generalmente tenían su asistente de administrador para iniciar sesión, por lo que fue fácil para las personas de TI ingresar (el consentimiento ya se había delegado).

En Windows, la única forma de ajustar manualmente el perfil de un usuario es iniciar sesión como ese usuario. Si ese perfil necesita ajuste manual por alguna razón (queda una mala desinstalación que se interpone en el camino de una reinstalación u otras cosas extrañas), la persona de TI deberá iniciar sesión como ese usuario. Esto se puede hacer forzando un cambio de contraseña administrativa, haciendo que el usuario revele su contraseña o haciendo que el usuario registre a la persona de TI como ellos mismos y permitiendo que la persona de TI trabaje.

Algunas aplicaciones durante la instalación requieren la capacidad de realizar cambios o hacer referencia al perfil del usuario (es decir, aplicaciones CRM que se integran con Outlook) mediante el uso de variables ambientales como% userprofile%, modificando HK_CURRENT_USER y similares.

Si bien podría "realizar ingeniería inversa" en una instalación con herramientas como procmon y luego modificar manualmente el perfil del usuario, el registro, etc. después del hecho, esto es altamente ineficiente, poco práctico y propenso a errores.

Absolutamente 100% no. Cualquier cosa que deba hacerse con la cuenta de otro usuario debe hacerse restableciendo la contraseña de los usuarios, iniciando sesión y luego haciendo que el usuario llame al servicio de asistencia o colocando la contraseña en algo que le indiquen a los usuarios y configurando la cuenta para forzar el cambio de contraseña. en el próximo inicio de sesión. Si bien admití que he trabajado en entornos bastante grandes o seguros, revelar su contraseña a cualquier persona fue motivo de terminación (y ese debería ser el caso en la mayoría de las situaciones)

La mayoría de estas publicaciones parecen bastante antiguas, pero es de esperar que algunas personas conocedoras todavía estén activas en el hilo, ya que esto parece seguir siendo un tema actual.

Ciertamente se pueden hacer argumentos para que nunca deba solicitar una contraseña. Prefiero decirles a mis usuarios "nunca compartan" ... y sí, la configuración puede ser manejada en la mayoría de los casos por un administrador para un usuario. Pero la solución de problemas es otro asunto.

Apoyamos un programa individual con 2600 estudiantes y 500 empleados. Abordamos los problemas de software "extraños" a diario. Es muy frecuente que tengamos que experimentar el problema como usuario para resolver el problema (o determinar con cierta confianza que será necesaria una recarga). Absolutamente, tratamos de hacer esto con el usuario presente, pero eso no siempre es práctico; Tienen un horario que mantener.

¿Qué pasa con las tarjetas inteligentes? ¿Existe alguna posibilidad en un entorno de AD 2010/2012 de que una tarjeta inteligente pueda asociarse (temporalmente) con una cuenta de dominio? Esto permitiría el acceso a la cuenta del usuario en realidad, sin exponer su contraseña específicamente. La tarjeta podría desactivarse cuando se completara la resolución de problemas. Los técnicos podrían utilizar la cuenta, pero las tarjetas podrían estar bien supervisadas.

Hemos utilizado lectores de huellas dactilares durante años, pero el proceso para configurarlo para una tecnología específica y luego eliminar esa impresión simplemente no es factible. No estoy seguro de cuán complejo sería el proceso para "autorizar" y luego "desactivar" una tarjeta inteligente para un usuario en particular, pero parece que podría ser un compromiso decente.

Sí: cualquier cosa que deba hacerse en su perfil. Cuando eso suceda, debe conocer su contraseña o establecerla, como dijo. Luego pueden cambiarlo cuando haya terminado.

Si inicia sesión como ese usuario, no le está otorgando permisos adicionales. Estás iniciando sesión como ellos con sus permisos.