Implemente y configure las mejores prácticas de Domain Controller
Jan 30, 2017
Los administradores de TI han estado trabajando con y alrededor de Active Directory desde la introducción de la tecnología en Windows 2000 Server. Windows 2000 Server se lanzó el 17 de febrero de 2000, pero muchos administradores comenzaron a trabajar con Active Directory a finales de 1999 cuando se lanzó para fabricación (RTM) el 15 de diciembre de 1999.
Existen algunas buenas prácticas a seguir al implementar DCs. Muchas de estas prácticas están documentadas. Pero no muchas organizaciones están implementando estas prácticas.
Cómo implementar y configurar Domain Controller
Omitiremos las buenas prácticas conocidas como mantener la Active Directory database en un conjunto de husillos de disco, los archivos de registro en husillos de disco separados y el sistema operativo en su propio conjunto de husillos de disco.
Algunas de las buenas prácticas menos implementadas para los controladores de dominio son:
Ejecute la instalación de Server Core del sistema operativo.
Muchos administradores evitan los cambios, especialmente en sistemas tan estables como AD DS. Por lo tanto, cuando un nuevo administrador propone cambiar a la instalación de Server Core, a menudo se encuentra con miradas frías. Pero la realidad es que la mayoría de los administradores gestionan AD DS de forma remota lanzando ADUC o PowerShell en su computadora cliente o computadora administrativa. Todas las herramientas principales de gestión, incluyendo el Centro Administrativo de Active Directory (ADAC) y Windows PowerShell, funcionan casi idénticamente cuando se usan localmente en un DC o de forma remota desde una computadora cliente o una computadora administrativa. Por lo tanto, al pasar a la instalación de Server Core, la experiencia administrativa no se degrada. Además, se obtienen mejoras de seguridad y algunas pequeñas mejoras de rendimiento.
Contenido relacionado seleccionado:
No ejecute otro software o servicios en un DC.
Hace tiempo, como hace 10 años, la mayoría de las organizaciones utilizaban servidores físicos porque la virtualización estaba en sus inicios. Entonces, cuando llegaba el momento de aprovisionar un nuevo servidor de archivos, servidor DHCP o servidor de impresión, los administradores a menudo simplemente utilizaban un servidor existente. Un DC también se usaba a menudo. Avanzamos rápidamente hasta 2015 cuando la virtualización es el estándar de facto y el aprovisionamiento automatizado ayuda a entregar una nueva VM en minutos y la antigua forma de hacer las cosas ya no es tan atractiva. Ahora, cuando necesitas un lugar para un servidor de archivos, servidor DHCP, servidor de impresión u otro servidor de aplicaciones, puedes aprovisionar una nueva VM. O, mejor aún, puedes aprovisionar una nueva VM como un servidor de utilidades. Un servidor de utilidades es un servidor que aloja todas las aplicaciones y servicios que son demasiado pequeños para justificar un servidor dedicado. Esto permite que tus DCs se adhieran a un servicio dedicado lo que aporta más estabilidad.
Ajuste el orden de arranque y establezca una contraseña de BIOS.
Aunque todos tus DC de lectura-escritura deberían estar en un centro de datos seguro, hay muchos empleados de TI y no TI que tienen acceso al centro de datos. Por ejemplo, los electricistas contratados que trabajan en el sistema de refrigeración tienen acceso al centro de datos. Además, es probable que haya técnicos de red, especialistas en cableado y gestión de TI con acceso al centro de datos. Cualquiera que tenga acceso físico a un DC puede obtener acceso a un DC físico en solo un par de minutos en una consola en el centro de datos. Hay imágenes de arranque freeware especializadas disponibles que puedes usar para arrancar y restablecer contraseñas, instalar malware o acceder a los datos del disco, asumiendo que el disco no esté cifrado. Para evitar esto, realiza las siguientes configuraciones:
- Asegúrese de que ningún medio extraíble forme parte del orden de arranque del BIOS. En su lugar, solo el disco duro donde está instalado el sistema operativo debe ser parte del orden de arranque. Esto también es válido para sus servidores anfitriones de virtualización, si tiene DCs virtuales.
- Establezca una contraseña fuerte para el BIOS. Si no configura una contraseña de BIOS, alguien podría actualizar el orden de arranque, iniciar desde el medio de instalación de Windows Server o utilizar herramientas gratuitas, realizar una reparación para acceder a una línea de comandos. Una vez en la línea de comandos, podrían causar estragos y restablecer rápidamente las contraseñas de las cuentas de dominio.
- Mantenga los DCs en un gabinete con llave. Aunque una contraseña de BIOS es una capa de seguridad, si el atacante tiene cierta capacidad, probablemente sabrá cómo restablecer el BIOS para que la configuración se reinicie y se elimine la contraseña. A menudo, esto requiere acceder a la placa base. Puede reducir el riesgo de tal ataque manteniendo los DCs en un gabinete con llave. Algunos servidores también permiten cerraduras de chasis. En entornos de alta seguridad, debería optar por ambos.
Estandarice la configuración de todos los controladores de dominio.
Deberías intentar igualar la configuración de los ajustes para cada DC. Puedes lograr parte de esto mediante la automatización de la construcción a través de herramientas de despliegue como System Center Configuration Manager. Los elementos de interés para los DCs son los ajustes del tamaño del registro de eventos para asegurar que tengas tamaños grandes para capturar información relacionada con la auditoría y la seguridad, ajustes de arranque como el tiempo de espera para la selección del SO en servidores físicos, versiones y ajustes de firmware y BIOS, y configuración del hardware. Por supuesto, hay muchos otros elementos de configuración para estandarizar mediante el uso de Group Policy. El objetivo principal es configurar los DCs de manera idéntica.
Encontrará más información sobre los conceptos básicos de Active Directory en nuestro AD tutorial for beginners.
Compartir en
Aprende más
Acerca del autor
Brian Svidergol
TI
Experto en infraestructura de Microsoft y soluciones basadas en la nube alrededor de Windows, Active Directory, Azure, Microsoft Exchange, System Center, virtualización y MDOP. Además de escribir libros, Brian crea contenido de formación, documentos técnicos y es revisor técnico en un gran número de libros y publicaciones.
Aprende más sobre este tema
Crear usuarios de AD en masa y enviar sus credenciales por correo electrónico usando PowerShell
Cómo crear, cambiar y probar contraseñas usando PowerShell
Cómo agregar y eliminar grupos de AD y objetos en grupos con PowerShell
Confianzas en Active Directory
Ataques de ransomware a Active Directory