¿Por qué los usuarios creados en el controlador de dominio siempre forman parte del dominio?

¿Por qué los usuarios creados en el controlador de dominio siempre forman parte del dominio?

Cuando quiero crear un usuario local en el controlador de dominio net user <username> <password> /add, encuentro que el usuario se incluye automáticamente en el Domain Usersgrupo.

Quiero crear una cuenta de administrador local en el controlador de dominio, que no sea parte del dominio, que pueda iniciar sesión en el controlador de dominio de forma interactiva y realizar tareas administrativas.

es posible?

windows active-directory

— Shuzheng
fuente

No. No es posible.

— joeqwerty

Respuestas:

Las cuentas locales se almacenan en un archivo llamado base de datos SAM . Esto existe en un controlador de dominio: si inicia un controlador de dominio en modo de restauración, la cuenta que usa para hacer esto es solo la cuenta de administrador local en la base de datos SAM. Sin embargo, cuando Windows se está ejecutando, normalmente el acceso a la base de datos SAM está deshabilitado y ninguna de las cuentas puede ser utilizada. Eso significa que es imposible iniciar sesión con una cuenta local en un controlador de dominio.

Sin embargo, esto se puede hacer si está contento de trabajar desde una línea de comandos y si no requiere acceso a la red. El truco es iniciar sesión como la cuenta del sistema local. Windows no proporciona ninguna forma de hacerlo, pero lo he hecho escribiendo un servidor telnet simple y luego ejecutándolo como un servicio utilizando la cuenta del sistema local. Cuando se conecta al servidor telnet, inicia sesión como la cuenta del sistema, no como una cuenta de dominio. Las únicas restricciones son que solo es la línea de comando y la cuenta del sistema no tiene acceso a la red. Si vas a usar un truco como este, ¡ten mucho cuidado con la seguridad!

Aunque todo esto suena como un truco horrible, tiene usos legítimos. Por ejemplo, en el trabajo utilizamos una herramienta de administración llamada N-able que permite el acceso remoto a una consola en los servidores, y lo hace utilizando básicamente la técnica que describí anteriormente. Si abro una consola en uno de nuestros controladores de dominio y uso el comando whoami obtengo:

Nota

Windows no tiene un método incorporado para abrir un símbolo del sistema remoto, pero como menciona Grawity en un comentario, la utilidad psexec de SysInternals puede hacer esto, y las utilidades de SysInternals son proporcionadas y respaldadas por Microsoft, por lo que esto es al menos semioficial. Usando psexec en uno de mis servidores obtengo:

D:\temp\psexec>psexec64 \\cheddar -s cmd.exe

PsExec v2.2 - Execute processes remotely
Copyright (C) 2001-2016 Mark Russinovich
Sysinternals - www.sysinternals.com


Microsoft Windows [Version 10.0.17134.345]
(c) 2018 Microsoft Corporation. All rights reserved.

C:\Windows\system32>whoami
nt authority\system

C:\Windows\system32>exit
cmd.exe exited on cheddar with error code 0.

— John Rennie
fuente

¿Reinventaste SysInternals psexec -s ?

— user1686

@grawity Primero hice esto en Windows NT 3.1 antes de que existieran las utilidades Sysinternals :-) Sin embargo, usted hace un buen punto. Había olvidado que psexec podía hacer eso.

— John Rennie

Punto a favor. ¿Aunque con suerte el telnetd original "abierto" no está en uso ahora?

— user1686

No, esto no es posible. Los controladores de dominio no tienen su propia base de datos de autenticación. Se reemplaza por Active Directory cuando se promueve a un controlador de dominio.

— cuello largo
fuente

Esto responde "¿Es esto posible?" del cuerpo de la pregunta, pero no responde "por qué" del título. ¿Alguna idea sobre la parte del "por qué"?

— Mołot

Domain controllers don't have their own authentication database. It is replaced by Active Directory when promoted to a Domain Controller

Es el por qué. Entonces esto responde el por qué.

— joeqwerty

@peterh Solo Microsoft puede saber por qué lo diseñaron de esa manera, pero dudo que lo sepan. Durante mi entrega, la mayoría de las preguntas de "por qué" tuve que responder con "lo hice porque fue lo primero que se me vino a la mente y funcionó, y después de eso, nunca cambié un sistema en ejecución".

— Alexander

Honestamente, si la pregunta es "¿Por qué Microsoft lo diseñó de esta manera?" es la pregunta, me gustaría VTC. Cualquier respuesta que proporcionemos sería pura especulación (a menos que alguien aquí haya trabajado en ese proyecto en MS alrededor de 1999-ish?).

— Katherine Villyard

Era un MVP de MS para el servidor de Windows en ese entonces e hice algunas cosas con el equipo beta "NT 5" y asistí a algunas reuniones donde se discutieron las decisiones de diseño. El argumento entonces era que en realidad no existía una acción de administrador "local" en un controlador de dominio, ya que cualquier cosa tenía el potencial de afectar el dominio. ¿Quieres reiniciar el DC? ¿Quieres agregar o eliminar un rol? ¿Desea cambiar la configuración de DNS en la tarjeta de red? Todos potencialmente capaces de afectar la capacidad de ese DC para atender su dominio y, por lo tanto, no realmente acciones de "administrador local" en un DC.

— Rob Moir