¿Qué son los Servicios de dominio de Active Directory y cómo funciona?

Esta es una pregunta canónica sobre los Servicios de dominio de Active Directory (AD DS).

¿Qué es Active Directory? ¿Qué hace y cómo funciona?

Cómo está organizado Active Directory: bosque, dominio secundario, árbol, sitio u OU

Me encuentro explicando algo de lo que supongo que es de conocimiento común casi a diario. Con suerte, esta pregunta servirá como una pregunta y respuesta canónica para la mayoría de las preguntas básicas de Active Directory. Si cree que puede mejorar la respuesta a esta pregunta, edítela.

¿Qué es Active Directory?

Active Directory Domain Services es el servidor de directorio de Microsoft. Proporciona mecanismos de autenticación y autorización, así como un marco dentro del cual se pueden implementar otros servicios relacionados (AD Certificate Services, AD Federated Services, etc.). Es una base de datos compatible con LDAP que contiene objetos. Los objetos más utilizados son los usuarios, las computadoras y los grupos. Estos objetos se pueden organizar en unidades organizativas (OU) por cualquier cantidad de necesidades lógicas o comerciales. Los Objetos de directiva de grupo (GPO) se pueden vincular a unidades organizativas para centralizar la configuración de varios usuarios o equipos en una organización.

Cuando las personas dicen "Active Directory", generalmente se refieren a "Servicios de dominio de Active Directory". Es importante tener en cuenta que existen otros roles / productos de Active Directory, como los Servicios de certificados, los Servicios de federación, los Servicios de directorio ligero, los Servicios de administración de derechos, etc. Esta respuesta se refiere específicamente a los Servicios de dominio de Active Directory.

¿Qué es un dominio y qué es un bosque?

Un bosque es un límite de seguridad. Los objetos en bosques separados no pueden interactuar entre sí, a menos que los administradores de cada bosque separado creen una confianza entre ellos. Por ejemplo, una cuenta de administrador de empresa domain1.com, que normalmente es la cuenta más privilegiada de un bosque, no tendrá permisos en absoluto en un segundo bosque nombrado domain2.com, incluso si esos bosques existen dentro de la misma LAN, a menos que exista una confianza .

Si tiene varias unidades de negocio disjuntas o necesita límites de seguridad separados, necesita varios bosques.

Un dominio es un límite de gestión. Los dominios son parte de un bosque. El primer dominio en un bosque se conoce como el dominio raíz del bosque. En muchas organizaciones pequeñas y medianas (e incluso en algunas grandes), solo encontrará un único dominio en un solo bosque. El dominio raíz del bosque define el espacio de nombres predeterminado para el bosque. Por ejemplo, si se nombra el primer dominio en un nuevo bosque domain1.com, entonces ese es el dominio raíz del bosque. Si tiene una necesidad comercial de un dominio secundario, por ejemplo, una sucursal en Chicago, puede nombrar el dominio secundario chi. El FQDN del dominio secundario seríachi.domain1.com. Puede ver que el nombre del dominio secundario se antepuso al nombre del dominio raíz del bosque. Esto es típicamente cómo funciona. Puede tener espacios de nombres disjuntos en el mismo bosque, pero esa es una lata completamente separada de gusanos para un momento diferente.

En la mayoría de los casos, querrás probar y hacer todo lo posible para tener un solo dominio de AD. Simplifica la administración, y las versiones modernas de AD hacen que sea muy fácil delegar el control basado en OU, lo que disminuye la necesidad de dominios secundarios.

Puedo nombrar mi dominio como quiera, ¿verdad?

Realmente no. dcpromo.exe, la herramienta que maneja la promoción de un servidor a un DC no es a prueba de idiotas. Te permite tomar malas decisiones con tu nombre, así que presta atención a esta sección si no estás seguro. (Editar: dcpromo está en desuso en el servidor 2012. Use el Install-ADDSForestcmdlet de PowerShell o instale AD DS desde el Administrador del servidor).

En primer lugar, no use TLD inventados como .local, .lan, .corp o cualquier otra basura. Esos TLD no están reservados. ICANN está vendiendo TLD ahora, por lo mycompany.corpque el que está usando hoy podría pertenecer a alguien mañana. Si posee mycompany.com, lo más inteligente es usar algo como internal.mycompany.como ad.mycompany.compara su nombre interno de AD. Si lo usa mycompany.comcomo un sitio web que se puede resolver externamente, también debe evitar usarlo como su nombre interno de AD, ya que terminará con un DNS de cerebro dividido.

Controladores de dominio y catálogos globales

Un servidor que responde a las solicitudes de autenticación o autorización es un controlador de dominio (DC). En la mayoría de los casos, un controlador de dominio tendrá una copia del catálogo global . Un Catálogo global (GC) es un conjunto parcial de objetos en todos los dominios de un bosque. Se puede buscar directamente, lo que significa que las consultas entre dominios generalmente se pueden realizar en un GC sin necesidad de una referencia a un DC en el dominio de destino. Si se consulta un DC en el puerto 3268 (3269 si se usa SSL), se está consultando el GC. Si se consulta el puerto 389 (636 si se usa SSL), se está utilizando una consulta LDAP estándar y los objetos existentes en otros dominios pueden requerir una referencia .

Cuando un usuario intenta iniciar sesión en una computadora que está unida a AD usando sus credenciales de AD, la combinación de nombre de usuario y contraseña con sal y hash se envía al DC tanto para la cuenta de usuario como para la cuenta de la computadora que está iniciando sesión. Sí, el la computadora también inicia sesión. Esto es importante, porque si algo le sucede a la cuenta de la computadora en AD, como si alguien restablece la cuenta o la elimina, puede recibir un error que dice que no existe una relación de confianza entre la computadora y el dominio. Aunque sus credenciales de red están bien, ya no se confía en la computadora para iniciar sesión en el dominio.

Problemas de disponibilidad del controlador de dominio

Escucho "Tengo un controlador de dominio primario (PDC) y quiero instalar un controlador de dominio de respaldo (BDC)" con mucha más frecuencia de lo que me gustaría creer. El concepto de PDC y BDC murió con Windows NT4. El último bastión para PDC estaba en un AD de modo mixto de transición de Windows 2000 cuando todavía tenía DCs NT4. Básicamente, a menos que sea compatible con una instalación de más de 15 años que nunca se ha actualizado, realmente no tiene un PDC o un BDC, solo tiene dos controladores de dominio.

Múltiples DC son capaces de responder a solicitudes de autenticación de diferentes usuarios y computadoras simultáneamente. Si uno falla, los otros continuarán ofreciendo servicios de autenticación sin tener que hacer uno "primario" como habría tenido que hacer en los días NT4. Es una buena práctica tener al menos dos DC por dominio. Estos DC deben tener una copia del GC y ser servidores DNS que también tengan una copia de las zonas DNS integradas de Active Directory para su dominio.

Roles FSMO

"Entonces, si no hay PDC, ¿por qué hay una función de PDC que solo un DC puede tener?"

He oído esto muchas veces. Hay un rol de emulador PDC . Es diferente a ser un PDC. De hecho, hay 5 roles flexibles de operaciones de maestro único (FSMO) . Estos también se denominan roles de maestro de operaciones. Los dos términos son intercambiables. ¿Qué son y qué hacen? ¡Buena pregunta! Los 5 roles y su función son:

Maestro de nombres de dominio : solo hay un maestro de nombres de dominio por bosque. El Maestro de nombres de dominio se asegura de que cuando se agrega un nuevo dominio a un bosque sea único. Si el servidor que desempeña este rol está fuera de línea, no podrá realizar cambios en el espacio de nombres de AD, que incluye cosas como agregar nuevos dominios secundarios.

Maestro de esquemas : solo hay un Maestro de operaciones de esquemas en un bosque. Es responsable de actualizar el esquema de Active Directory. Las tareas que requieren esto, como preparar AD para una nueva versión de Windows Server que funcione como DC o la instalación de Exchange, requieren modificaciones de esquema. Estas modificaciones deben hacerse desde el maestro de esquema.

Maestro de infraestructura : hay un maestro de infraestructura por dominio. Si solo tiene un único dominio en su bosque, realmente no necesita preocuparse por ello. Si tiene varios bosques, debe asegurarse de que esta función no la tenga un servidor que también sea titular de un GC, a menos que cada DC del bosque sea un GC . El maestro de infraestructura es responsable de garantizar que las referencias entre dominios se manejen correctamente. Si un usuario en un dominio se agrega a un grupo en otro dominio, el maestro de infraestructura para los dominios en cuestión se asegura de que se maneje correctamente. Este rol no funcionará correctamente si está en un catálogo global.

Maestro RID: el maestro de identificación relativa (maestro RID) es responsable de emitir agrupaciones RID a los DC. Hay un maestro RID por dominio. Cualquier objeto en un dominio AD tiene un identificador de seguridad (SID) único. Esto se compone de una combinación del identificador de dominio y un identificador relativo. Cada objeto en un dominio dado tiene el mismo identificador de dominio, por lo que el identificador relativo es lo que hace que los objetos sean únicos. Cada DC tiene un grupo de ID relativos para usar, por lo que cuando ese DC crea un nuevo objeto, agrega un RID que aún no ha utilizado. Dado que los DC se emiten agrupaciones no superpuestas, cada RID debe permanecer único durante la vida útil del dominio. Cuando un DC llega a ~ 100 RID restantes en su grupo, solicita un nuevo grupo al maestro RID. Si el maestro RID está fuera de línea durante un período prolongado, la creación de objetos puede fallar.

PDC Emulator : Finalmente, llegamos al rol más incomprendido de todos, el rol de PDC Emulator. Hay un emulador PDC por dominio. Si hay un intento de autenticación fallido, se reenvía al emulador PDC. El PDC Emulator funciona como el "desempate" si una contraseña se actualizó en un DC y aún no se ha replicado en los demás. El PDC Emulator también es el servidor que controla la sincronización horaria en todo el dominio. Todos los demás DC sincronizan su tiempo desde el emulador PDC. Todos los clientes sincronizan su tiempo desde el DC en el que iniciaron sesión. Es importante que todo permanezca con 5 minutos de diferencia, de lo contrario Kerberos se rompe y cuando eso sucede, todos lloran.

Lo importante para recordar es que los servidores en los que se ejecutan estos roles no están establecidos en piedra. Por lo general, es trivial mover estos roles, por lo que, aunque algunos DC hacen un poco más que otros, si caen por períodos cortos de tiempo, todo funcionará normalmente. Si están inactivos durante mucho tiempo, es fácil transferir de forma transparente los roles. Es mucho más agradable que los días NT4 PDC / BDC, así que deje de llamar a sus DC por esos viejos nombres. :)

Entonces, um ... ¿cómo comparten los DCs información si pueden funcionar independientemente unos de otros?

Replicación, por supuesto . Por defecto, los DC que pertenecen al mismo dominio en el mismo sitio replicarán sus datos entre sí a intervalos de 15 segundos. Esto asegura que todo esté relativamente actualizado.

Hay algunos eventos "urgentes" que desencadenan la replicación inmediata. Estos eventos son: una cuenta está bloqueada por demasiados inicios de sesión fallidos, se realiza un cambio en la contraseña del dominio o en las políticas de bloqueo, se cambia el secreto LSA, se cambia la contraseña en una cuenta de computadora de DC o se transfiere la función RID Master a un nuevo DC. Cualquiera de estos eventos desencadenará un evento de replicación inmediata.

Los cambios de contraseña caen en algún lugar entre urgente y no urgente y se manejan de manera única. Si se cambia la contraseña de DC01un usuario y un usuario intenta iniciar sesión en una computadora que se está autenticando DC02antes de que ocurra la replicación, esperaría que esto fallara, ¿verdad? Afortunadamente eso no sucede. Suponga que también hay un tercer DC aquí llamado DC03que tiene el rol de emulador PDC. Cuando DC01se actualiza con la nueva contraseña del usuario, ese cambio también se replica inmediatamente DC03. Cuando el intento de autenticación DC02falla, DC02reenvía ese intento de autenticación DC03, lo que verifica que es realmente bueno y que el inicio de sesión está permitido.

Hablemos de DNS

El DNS es crítico para un AD que funcione correctamente. La línea oficial de Microsoft es que se puede usar cualquier servidor DNS si está configurado correctamente. Si intenta usar BIND para alojar sus zonas de AD, está alto. Seriamente. Siga con el uso de zonas DNS integradas de AD y use reenviadores condicionales o globales para otras zonas si es necesario. Todos sus clientes deben estar configurados para usar sus servidores AD DNS, por lo que es importante tener redundancia aquí. Si tiene dos DC, haga que ambos ejecuten DNS y configure a sus clientes para que usen ambos para la resolución de nombres.

Además, querrá asegurarse de que si tiene más de un DC, que no se enumeren primero para la resolución de DNS. Esto puede conducir a una situación en la que se encuentran en una "isla de replicación" donde están desconectados del resto de la topología de replicación de AD y no pueden recuperarse. Si tiene dos servidores DC01 - 10.1.1.1y DC02 - 10.1.1.2, entonces, su lista de servidores DNS debe configurarse así:

Servidor: DC01 (10.1.1.1)
DNS primario - 10.1.1.2
DNS secundario - 127.0.0.1

Servidor: DC02 (10.1.1.2)
DNS primario - 10.1.1.1
DNS secundario - 127.0.0.1

OK, esto parece complicado. ¿Por qué quiero usar AD en absoluto?

Porque una vez que sabes lo que estás haciendo, tu vida se vuelve infinitamente mejor. AD permite la centralización de la gestión de usuarios y computadoras, así como la centralización del acceso y uso de recursos. Imagine una situación en la que tiene 50 usuarios en una oficina. Si desea que cada usuario tenga su propio inicio de sesión en cada computadora, deberá configurar 50 cuentas de usuario locales en cada PC. Con AD, solo tiene que crear la cuenta de usuario una vez y puede iniciar sesión en cualquier PC del dominio de forma predeterminada. Si quisieras reforzar la seguridad, tendrías que hacerlo 50 veces. Una especie de pesadilla, ¿verdad? También imagine que tiene un recurso compartido de archivos al que solo desea que llegue la mitad de esas personas. Si no está utilizando AD, necesitaría replicar su nombre de usuario y contraseñas a mano en el servidor para dar un acceso aparentemente, o usted ' d tiene que hacer una cuenta compartida y dar a cada usuario el nombre de usuario y la contraseña. Una forma significa que usted conoce (y tiene que actualizar constantemente) las contraseñas de los usuarios. La otra forma significa que no tiene ninguna pista de auditoría. No es bueno, ¿verdad?

También puede usar la Política de grupo cuando tiene configurado AD. La directiva de grupo es un conjunto de objetos que están vinculados a unidades organizativas que definen la configuración de los usuarios y / o equipos en esas unidades organizativas. Por ejemplo, si desea que el "Apagado" no esté en el menú de inicio para 500 PC de laboratorio, puede hacerlo en una configuración en la Política de grupo. En lugar de pasar horas o días configurando manualmente las entradas de registro adecuadas, cree un Objeto de directiva de grupo una vez, vincúlelo a la unidad organizativa o unidades organizativas correctas, y nunca más tenga que pensar en ello. Hay cientos de GPO que se pueden configurar, y la flexibilidad de la directiva de grupo es una de las principales razones por las que Microsoft es tan dominante en el mercado empresarial.

Nota: Esta respuesta se fusionó con esta pregunta de una pregunta diferente que preguntó sobre las diferencias entre bosques, dominios secundarios, árboles, sitios y unidades organizativas. Esto no se escribió originalmente como respuesta a esta pregunta específica.

Bosque

Desea crear un nuevo bosque cuando necesita un límite de seguridad. Por ejemplo, puede tener una red perimetral (DMZ) que desee administrar con AD, pero no desea que su AD interna esté disponible en la red perimetral por razones de seguridad. En este caso, desearía crear un nuevo bosque para esa zona de seguridad. También puede desear esta separación si tiene varias entidades que no confían entre sí, por ejemplo, una corporación fantasma que abarca negocios individuales que operan de manera independiente. En este caso, desearía que cada entidad tenga su propio bosque.

Dominio secundario

Realmente, ya no los necesitas. Hay algunos buenos ejemplos de cuándo desea un dominio secundario. Una razón heredada se debe a los diferentes requisitos de la política de contraseñas, pero esto ya no es válido, ya que existen Políticas de contraseñas específicas desde el servidor 2008. Realmente solo necesita un dominio secundario si tiene áreas con una conectividad de red increíblemente pobre y desea para reducir drásticamente el tráfico de replicación: un crucero con conectividad WAN satelital es un buen ejemplo. En este caso, cada crucero puede ser su propio dominio secundario, para ser relativamente autónomo y al mismo tiempo aprovechar los beneficios de estar en el mismo bosque que otros dominios de la misma compañía.

Árbol

Esta es una bola extraña. Los nuevos árboles se utilizan cuando desea mantener los beneficios de gestión de un solo bosque pero tiene un dominio en un nuevo espacio de nombres DNS. Por ejemplo, corp.example.compuede ser la raíz del bosque, pero podría tener ad.mdmarra.comen el mismo bosque utilizando un nuevo árbol. Aquí se aplican las mismas reglas y recomendaciones para dominios secundarios: úselas con moderación. Por lo general, no son necesarios en los AD modernos.

Sitio

Un sitio debe representar límites físicos o lógicos en su red. Por ejemplo, sucursales. Los sitios se utilizan para seleccionar de forma inteligente socios de replicación para controladores de dominio en diferentes áreas. Sin definir sitios, todos los DC se tratarán como si estuvieran en la misma ubicación física y se replicarían en una topología de malla. En la práctica, la mayoría de las organizaciones están configuradas de forma lógica en un centro de distribución, por lo que los sitios y servicios deben configurarse para reflejar esto.

Otras aplicaciones también usan Sitios y Servicios. DFS lo usa para referencias de espacios de nombres y selección de socios de replicación. Exchange y Outlook lo utilizan para buscar el catálogo global "más cercano" para consultar. Sus computadoras unidas al dominio lo usan para localizar los DC "más cercanos" para autenticarse. Sin esto, su tráfico de replicación y autenticación es como el Salvaje Oeste.

Unidad organizacional

Deben crearse de manera que reflejen la necesidad de su organización de delegar permisos y aplicar políticas de grupo. Muchas organizaciones tienen una unidad organizativa por sitio, porque aplican GPO de esa manera; esto es una tontería, porque también puede aplicar GPO a un sitio desde Sitios y Servicios. Otras organizaciones separan las unidades organizativas por departamento o función. Esto tiene sentido para muchas personas, pero realmente el diseño de OU debe satisfacer sus necesidades y es bastante flexible. No hay "una forma" de hacerlo.

Una multinacional puede tener alto nivel de unidades organizativas North America, Europe, Asia, South America, Africapara que puedan delegar privilegios administrativos sobre la base de los continentes. Otras organizaciones pueden tener alto nivel de unidades organizativas Human Resources, Accounting, Sales, etc, si es que tiene más sentido para ellos. Otras organizaciones tienen necesidades políticas mínimas y utilizan un diseño "plano" con solo Employee Usersy Employee Computers. Realmente no hay una respuesta correcta aquí, es lo que satisfaga las necesidades de su empresa.