Security Management (Proceso)

La Gestión de la Seguridad esta estrechamente relacionada con prácticamente todos los otros procesos TI y necesita para su éxito la colaboración de toda la organización.

Para que esa colaboración sea eficaz es necesario que la Gestión de la Seguridad:

  • Establezca una clara y definida política de seguridad que sirva de guía a todos los otros procesos.
  • Elabore un Plan de Seguridad que incluya los niveles de seguridad adecuados tanto en los servicios prestados a los clientes como en los acuerdos de servicio firmados con proveedores internos y externos.
  • Implemente el Plan de Seguridad.
  • Monitorice y evalúe el cumplimiento de dicho plan.
  • Supervise proactivamente los niveles de seguridad analizando tendencias, nuevos riesgos y vulnerabilidades.
  • Realice periódicamente auditorías de seguridad.

Política de Seguridad

Es imprescindible disponer de un marco general en el que encuadrar todos los subprocesos asociados a la Gestión de la Seguridad. Su complejidad e intricadas interrelaciones necesitan de una política global clara en donde se fijen aspectos tales como los objetivos, responsabilidades y recursos.

En particular la Política de Seguridad debe determinar:

  • La relación con la política general del negocio.
  • La coordinación con los otros procesos TI.
  • Los protocolos de acceso a la información.
  • Los procedimientos de análisis de riesgos.
  • Los programas de formación.
  • El nivel de monitorización de la seguridad.
  • Qué informes deben ser emitidos periódicamente.
  • El alcance del Plan de Seguridad.
  • La estructura y responsables del proceso de Gestión de la Seguridad.
  • Los procesos y procedimientos empleados.
  • Los responsables de cada subproceso.
  • Los auditores externos e internos de seguridad.
  • Los recursos necesarios: software, hardware y personal.
Plan de Seguridad

El objetivo del Plan de Seguridad es fijar los niveles de seguridad que han de ser incluidos como parte de los SLAs, OLAs y UCs.

Este plan ha de ser desarrollado en colaboración con la Gestión de Niveles de Servicio que es la responsable en última instancia tanto de la calidad del servicio prestado a los clientes como la del servicio recibido por la propia organización TI y los proveedores externos.

El Plan de Seguridad debe diseñarse para ofrecer un mejor y más seguro servicio al cliente y nunca como un obstáculo para el desarrollo de sus actividades de negocio.

Siempre que sea posible deben definirse métricas e indicadores clave que permitan evaluar los niveles de seguridad acordados.

Un aspecto esencial a tener en cuenta es el establecimiento de unos protocolos de seguridad coherentes en todas las fases del servicio y para todos los estamentos implicados. “Una cadena es tan resistente como el más débil de sus eslabones”, por lo que carece de sentido, por ejemplo, establecer una estrictas normas de acceso si una aplicación tiene vulnerabilidades frente a inyecciones de SQL. Quizá con ello podamos engañar a algún cliente durante algún tiempo ofreciendo la imagen de “fortaleza” pero esto valdrá de poco si alguien descubre que la “puerta de atrás está abierta”.


Aplicación de las Medidas de Seguridad

Por muy buena que sea la planificación de la seguridad resultará inútil si las medidas previstas no se ponen en práctica.

Es responsabilidad de la Gestión de Seguridad coordinar la implementación de los protocolos y medidas de seguridad establecidas en la Política y el Plan de Seguridad.

En primer lugar la Gestión de la Seguridad debe verificar que:

  • El personal conoce y acepta las medidas de seguridad establecidas así como sus responsabilidades al respecto.
  • Los empleados firmen los acuerdos de confidencialidad correspondientes a su cargo y responsabilidad.
  • Se imparte la formación pertinente.

Es también responsabilidad directa de la Gestión de la Seguridad:

  • Asignar los recursos necesarios.
  • Generar la documentación de referencia necesaria.
  • Colaborar con el Service Desk y la Gestión de Incidentes en el tratamiento y resolución de incidentes relacionados con la seguridad.
  • Instalar y mantener las herramientas de hardware y software necesarias para garantizar la seguridad.
  • Colaborar con la Gestión de Cambios y Versiones para asegurar que no se introducen nuevas vulnerabilidades en los sistemas en producción o entornos de pruebas.
  • Proponer RFCs a la Gestión de Cambios que aumenten los niveles de seguridad.
  • Colaborar con la Gestión de la Continuidad del Servicio para asegurar que no peligra la integridad y confidencialidad de los datos en caso de desastre.
  • Establecer las políticas y protocolos de acceso a la información.
  • Monitorizar las redes y servicios en red para detectar intrusiones y ataques.

Es necesario que la gestión de la empresa reconozca la autoridad de la Gestión de la Seguridad respecto a todas estas cuestiones y que incluso permita que ésta proponga medidas disciplinarias vinculantes cuando los empleados u otro personal relacionado con la seguridad de los servicios incumpla con sus responsabilidades.


Evaluación y Mantenimiento

Evaluación

No es posible mejorar aquello que no se conoce, es por la tanto indispensable evaluar el cumplimiento de las medidas de seguridad, sus resultados y el cumplimiento de los SLAs.

Aunque no es imprescindible, es recomendable que estas evaluaciones se complementen con auditorías de seguridad externas y/o internas realizadas por personal independiente de la Gestión de la Seguridad.

Estas evaluaciones/auditorias deben valorar el rendimiento del proceso y proponer mejoras que se plasmaran en RFCs que habrán de ser evaluados por la Gestión de Cambios.

Independientemente de estas evaluaciones de carácter periódico se deberán generar informes independientes cada vez que ocurra algún incidente grave relacionado con la seguridad. De nuevo, si la Gestión de la Seguridad lo considera oportuno, estos informes se acompañaran de las RFCs correspondientes.

Mantenimiento

La Gestión de la Seguridad es un proceso continuo y se han de mantener al día el Plan de Seguridad y las secciones de seguridad de los SLAs.

Los cambios en el Plan de Seguridad y los SLAs pueden ser resultado de la evaluación arriba citada o de cambios implementados en la infraestructura o servicios TI.

No hay nada más peligroso que la falsa sensación de seguridad que ofrecen medidas de seguridad obsoletas.

Es asimismo importante que la Gestión de la Seguridad esté al día en lo que respecta a nuevos riesgos y vulnerabilidades frente a virus, spyware, ataques de denegación de servicio, etcétera, y que adopte las medidas necesarias de actualización de equipos de hardware y software, sin olvidar el apartado de formación: el factor humano es normalmente el eslabón más débil de la cadena.


Control del Proceso

Al igual que en el resto de procesos TI es necesario realizar un riguroso control del proceso para asegurar que la Gestión de la Seguridad cumple sus objetivos.

Una buena Gestión de la Seguridad debe traducirse en una:

  • Disminución del número de incidentes relacionados con la seguridad.
  • Un acceso eficiente a la información por el personal autorizado.
  • Gestión proactiva que permita identificar vulnerabilidades potenciales antes de que estas se manifiesten y provoquen una seria degradación de la calidad del servicio.

La correcta elaboración de informes permite evaluar el rendimiento de la Gestión de Seguridad y aporta información de vital importancia a otras áreas de la infraestructura TI.

Entre la documentación generada cabría destacar:

  • Informes sobre el cumplimiento, en lo todo lo referente al apartado de seguridad, de los SLAs, OLAs y UCs en vigor.
  • Relación de incidentes relacionados con la seguridad calificados por su impacto sobre la calidad del servicio.
  • Evaluación de los programas de formación impartidos y sus resultados.
  • Identificación de nuevos peligros y vulnerabilidades a las que se enfrenta la infraestructura TI.
  • Auditorías de seguridad.
  • Informes sobre el grado de implementación y cumplimiento de los planes de seguridad establecidos.

Security Management (Objetivos)

Los principales objetivos de la Gestión de la Seguridad se resumen en:

  • Diseñar una política de seguridad, en colaboración con clientes y proveedores correctamente alineada con las necesidades del negocio.
  • Asegurar el cumplimiento de los estándares de seguridad acordados.
  • Minimizar los riesgos de seguridad que amenacen la continuidad del servicio.

La correcta Gestión de la Seguridad no es responsabilidad (exclusiva) de “expertos en seguridad” que desconocen los otros procesos de negocio. Si caemos en la tentación de establecer la seguridad como una prioridad en sí misma limitaremos las oportunidades de negocio que nos ofrece el flujo de información entre los diferentes agentes implicados y la apertura de nuevas redes y canales de comunicación.

La Gestión de la Seguridad debe conocer en profundidad el negocio y los servicios que presta la organización TI para establecer protocolos de seguridad que aseguren que la información esté accesible cuando se necesita por aquellos que tengan autorización para utilizarla.

Una vez comprendidos cuales son los requisitos de seguridad del negocio, la Gestión de la Seguridad debe supervisar que estos se hallen convenientemente plasmados en los SLAs correspondientes para, a renglón seguido, garantizar su cumplimiento.

La Gestión de la Seguridad debe asimismo tener en cuenta los riesgos generales a los que está expuesta la infraestructura TI, y que no necesariamente tienen porque figurar en un SLA, para asegurar, en la medida de lo posible, que no representan un peligro para la continuidad del servicio.

Es importante que la Gestión de la Seguridad sea proactiva y evalúe a priori los riesgos de seguridad que pueden suponer los cambios realizados en la infraestructura, nuevas líneas de negocio, etcétera.

 

Los principales beneficios de una correcta Gestión de la Seguridad:

  • Se evitan interrupciones del servicio causadas por virus, ataques informáticos, etcétera.
  • Se minimiza el número de incidentes.
  • Se tiene acceso a la información cuando se necesita y se preserva la integridad de los datos.
  • Se preserva la confidencialidad de los datos y la privacidad de clientes y usuarios.
  • Se cumplen los reglamentos sobre protección de datos.
  • Mejora la percepción y confianza de clientes y usuarios en lo que respecta a la calidad del servicio.

Las principales dificultades a la hora de implementar la Gestión de la Seguridad se resumen en:

  • No existe el suficiente compromiso de todos los miembros de la organización TI con el proceso.
  • Se establecen políticas de seguridad excesivamente restrictivas que afectan negativamente al negocio.
  • No se dispone de las herramientas necesarias para monitorizar y garantizar la seguridad del servicio (firewalls, antivirus, …).
  • El personal no recibe una formación adecuada para la aplicación de los protocolos de seguridad.
  • Falta de coordinación entre los diferentes procesos lo que impide una correcta evaluación de los riesgos.

Seguridad en estado puro (Cloud Security)

La compañía Proyecto Cero presenta oficialmente un servicio de seguridad gestionada, diseñado para todo tipo de empresas que permite mantener actualizado, eficiente, seguro y dinamico nuestros servicios, permitiendonos disponer de la cualificación más actualizada de los profesionales en el ámbito de la seguridad.

OPIDUM

 

 

TI ante nuevas amenazas, Seguridad Gestionada

La protección que proporcionan los sistemas de seguridad TI actuales no es suficiente. Según Stonesoft, las nuevas amenazas que han descubierto, las llamadas nuevas Técnicas de Evasión Avanzadas (AET, en sus siglas en inglés), son capaces de burlar la amplia mayoría de los sistemas de seguridad tradicionales; al menos, el 90 por ciento de los appliances de seguridad no están preparados para ofrecer la adecuada protección frente a las AETs.

Las técnicas de evasión son un medio de ocultar y modificar ataques con la finalidad de evitar su detección y bloqueo por parte de las soluciones de seguridad TI, pudiendo introducir códigos maliciosos o ataques a los sistemas corporativos. Aunque las técnicas de evasión no es algo nuevo, ya que se han investigado al menos desde 1998, de acuerdo con María Campos, country manager de Stonesoft Ibérica, “la mayoría de los fabricantes ha ignorado la investigación en este campo y ahora, los sistemas de seguridad TI no son vulnerables ante estas amenazas”.

Hasta ahora existía un conjunto limitado de técnicas de evasión conocidas y controladas, como la fragmentación IP y segmentación TCP con tamaño del fragmento y orden manipulados, fragmentación SMB y MSRPC, encriptación MSRPC, etc, pero según Campos, en la actualidad, estas técnicas han evolucionado y ahora son más avanzadas y dinámicas, “capaces de invalidar por ejemplo, las tecnologías IPS, los firewalls de próxima generación, los UTM o los productos para securizar entornos virtuales”. Y es que, las AET permiten un número de combinaciones exponencial, lo que provocan poder sobrepasar el 99 por ciento de los sistemas de seguridad que utilizan métodos de protección convencionales.

Un nuevo modelo de seguridad TI ante nuevas amenazas

La protección que proporcionan los sistemas de seguridad TI actuales no es suficiente. Según Stonesoft, las nuevas amenazas que han descubierto, las llamadas nuevas Técnicas de Evasión Avanzadas (AET, en sus siglas en inglés), son capaces de burlar la amplia mayoría de los sistemas de seguridad tradicionales; al menos, el 90 por ciento de los appliances de seguridad no están preparados para ofrecer la adecuada protección frente a las AETs.

Las técnicas de evasión son un medio de ocultar y modificar ataques con la finalidad de evitar su detección y bloqueo por parte de las soluciones de seguridad TI, pudiendo introducir códigos maliciosos o ataques a los sistemas corporativos. Aunque las técnicas de evasión no es algo nuevo, ya que se han investigado al menos desde 1998, de acuerdo con María Campos, country manager de Stonesoft Ibérica, “la mayoría de los fabricantes ha ignorado la investigación en este campo y ahora, los sistemas de seguridad TI no son vulnerables ante estas amenazas”.

Hasta ahora existía un conjunto limitado de técnicas de evasión conocidas y controladas, como la fragmentación IP y segmentación TCP con tamaño del fragmento y orden manipulados, fragmentación SMB y MSRPC, encriptación MSRPC, etc, pero según Campos, en la actualidad, estas técnicas han evolucionado y ahora son más avanzadas y dinámicas, “capaces de invalidar por ejemplo, las tecnologías IPS, los firewalls de próxima generación, los UTM o los productos para securizar entornos virtuales”. Y es que, las AET permiten un número de combinaciones exponencial, lo que provocan poder sobrepasar el 99 por ciento de los sistemas de seguridad que utilizan métodos de protección convencionales.

La directiva enfatizó la seriedad del descubrimiento de estas nuevas AETs que pueden causar grandes daños en la seguridad de la información de las empresas, que incluso, ha sido enviado al equipo nacional del CERT-FI, así como a ICSA Labs (división independiente de Verizon Business), y ha sido validado por líderes de la industria y, “lo más importante, es que lo hemos probado”, asegura Campos.

Ante esta situación, Stonesoft plantea un nuevo modelo de seguridad TI para hacer frente a las AETs. “Lo que proponemos es una lucha anti-evasión en el conjunto de la industria de seguridad TI, no sólo de Stonesoft, desarrollando nuevas soluciones”. En concreto, Campos habló de crear sistemas de seguridad dinámicas, que se actualicen de forma rápida y remota, y que se gestionen desde un único punto. Además, de acuerdo con la directiva, las soluciones deberían ser software, más que hardware, ya que es posible actualizarlas con mayor rapidez.

Campos ha anunciado que las primeras soluciones anti-evasión de la compañía saldrán a finales de este mes de noviembre, y la idea es que vayan actualizándose a través de parches.

De momento, Stonesoft cuenta con Predator 3, una herramienta de testing de dispositivos de seguridad orientada a descubrir nuevos métodos de evasión diseñada con su propia pila TCP/IP al margen de la del sistema operativo.

Además, Stonesoft ha puesto en marcha la iniciativa antievasión.com, “un foro de discusión abierto y de conocimiento sobre las AETs”, concluye Campos.

Proceso para transferir y asumir la función Operación de maestro único flexible

Transferir la función Operación de maestro único flexible

La transferencia de una función FSMO es la forma recomendada de mover una función FSMO entre controladores de dominio y puede iniciarla el administrador o mediante la degradación de un controlador de dominio, pero no la inicia automáticamente el sistema operativo. Esto incluye un servidor en estado de cierre. Las funciones FSMO no se reubican automáticamente durante el proceso de apagado; debe tenerlo en cuenta al apagar un controlador de dominio que tiene una función FSMO para realizar tareas de mantenimiento por ejemplo.
En una transferencia correcta de una función FSMO entre dos controladores de dominio, antes de transferir la función se realiza una sincronización de los datos mantenidos por el propietario de la función FSMO en el servidor que recibe la función FSMO para asegurarse de que todos los cambios han quedado grabados antes del cambio de función.
Los atributos operacionales son atributos que se convierten en una acción en el servidor. Este tipo de atributo no se define en el esquema, sino que el servidor lo mantiene y lo intercepta cuando un cliente intenta leerlo o escribir en él. Cuando se lee el atributo, el resultado suele ser un resultado calculado del servidor. Cuando se escribe el atributo, se realiza una acción predefinida en el controlador de dominio.
Los siguientes atributos operacionales se utilizan para transferir funciones FSMO y se encuentran en la RootDSE (o Root DSA Specific Entry, la raíz del árbol de Active Directory para un controlador de dominio determinado donde se mantiene información específica del controlador de dominio). Al escribir en el atributo operacional apropiado en el controlador de dominio para recibir la función FSMO, se degrada el controlador de dominio anterior y se promueve automáticamente el controlador de dominio nuevo. No se requiere ninguna intervención manual. Los atributos operacionales que representan las funciones de FSMO son los siguientes:

becomeRidMaster
becomeSchemaMaster
becomeDomainMaster
becomePDC
becomeInfrastructureMaster

Si el administrador especifica el servidor que va a recibir la función FSMO mediante una herramienta como Ntdsutil, el intercambio de la función FSMO se define entre el propietario actual y el controlador de dominio especificado por el administrador.
Cuando se degrada un controlador de dominio se escribe el atributo operacional "GiveAwayAllFsmoRoles", lo que hace que el controlador de dominio busque otros controladores de dominio para descargar las funciones que posee actualmente. Windows 2000 determina qué funciones posee actualmente el controlador de dominio que se degrada y busca un controlador de dominio adecuado mediante estas reglas:

  1. Buscar un servidor en el mismo sitio.
  2. Buscar un servidor con el que haya conectividad RPC.
  3. Utilizar un servidor a través de un transporte asincrónico (como SMTP).

En todas las transferencias, si la función es específica del dominio, sólo se puede mover a otro controlador del mismo dominio. De lo contrario, cualquier controlador de dominio de la empresa es un candidato posible.

 

Asumir la función Operación de maestro único flexible

Los administradores deben tener mucho cuidado al asumir funciones FSMO. En la mayoría de los casos, esta operación sólo debe realizarse si el propietario de la función FSMO original no va a volver al entorno.
Cuando el administrador asume una función FSMO de un equipo existente, se modifica el atributo "fsmoRoleOwner" en el objeto que representa la raíz de los datos eludiendo directamente la sincronización de los datos y la transferencia de la función. El atributo "fsmoRoleOwner" de cada uno de los objetos siguientes se escribe con el Nombre completo (DN) del objeto Configuración de NTDS (los datos de Active Directory que definen un equipo como un controlador de dominio) del controlador de dominio que toma la propiedad de esa función. A medida que la replicación de este cambio empieza a extenderse, otros controladores de dominio conocen el cambio de la función FSMO.
FSMO de controlador principal de dominio (PDC):

LDAP://DC=MICROSOFT,DC=COM

FSMO de maestro RID:

LDAP://CN=Rid Manager$,CN=System,DC=MICROSOFT,DC=COM

FSMO de maestro de esquema:

LDAP://CN=Schema,CN=Configuration,DC=Microsoft,DC=Com

FSMO de maestro de infraestructura:

LDAP://CN=Infrastructure,DC=Microsoft,DC=Com

FSMO de maestro de nombres de dominio:

LDAP://CN=Partitions,CN=Configuration,DC=Microsoft,DC=Com

Por ejemplo, si el Servidor1 es el PDC del dominio Microsoft.com y se retira, y el administrador no puede degradar el equipo correctamente, es preciso asignar al Servidor2 la función FSMO del PDC. Una vez asumida la función, el valor

CN=NTDS Settings,CN=SERVIDOR2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=Microsoft,DC=Com

está presente en el objeto siguiente:

LDAP://DC=MICROSOFT,DC=COM

Ubicación y optimización del FSMO en controladores de dominio de Active Directory

Ciertas operaciones de los dominios y de las empresas que no son adecuadas para la ubicación en varios maestros residen en un único controlador de dominio del dominio o el bosque. La ventaja de las operaciones de maestro único es evitar la introducción de conflictos mientras un maestro de operaciones está sin conexión, en lugar de provocar conflictos potenciales y tener que resolverlos posteriormente. Disponer de un maestro de operación único significa, sin embargo, que el propietario de la función FSMO debe estar disponible cuando tengan lugar actividades dependientes en el dominio, o para hacer cambios en el directorio asociados a esa función.
El Asistente para instalación de Active Directory (Dcpromo.exe) define cinco funciones FSMO: maestro de esquema, maestro del dominio, maestro RID, emulador de PDC e infraestructura. El maestro de esquema y el maestro de nombres de dominio son funciones específicas de cada bosque. Las tres funciones restantes, maestro RID, emulador de PDC y maestro de infraestructura se definen para cada dominio.
Un bosque con un dominio tiene cinco funciones. Cada dominio adicional del bosque agrega tres funciones para todo el dominio. El número de funciones FSMO en un bosque y los potenciales propietarios de las funciones FSMO se pueden determinar con la fórmula ((Número de dominios * 3) +2).
Un bosque con tres dominios (A.com, con los dominios secundarios y los dominios secundarios de éstos B.A.com y C.B.A.com) tiene once funciones FSMO:
1 maestro de esquema – A.COM para todo el bosque
1 maestro de nombres de dominio – A.COM para todo el bosque
3 emuladores de PDC (A.com, B.A.com y C.B.A.com)
3 maestros RID (A.com, B.A.com y C.B.A.com)
3 maestros de infraestructura para cada dominio respectivo. (A.com, B.A.com y C.B.A.com)
Al crear el primer controlador de dominio de Active Directory de un bosque, Dcpromo.exe le asigna las cinco funciones. Al crear el primer controlador de dominio de Active Directory de un nuevo dominio en un bosque existente, el sistema le asigna las tres funciones del dominio. En un dominio de modo mixto que contiene controladores de dominio de Microsoft Windows NT 4.0, sólo los que ejecutan Microsoft Windows Server 2003 o Microsoft Windows 2000 Server pueden hospedar cualesquiera de las funciones FSMO para todo el dominio o el bosque.

 

Disponibilidad y ubicación de FSMO

Dcpromo.exe realiza la ubicación inicial de las funciones en los controladores de dominio. Esta ubicación suele ser correcta para directorios con pocos controladores de dominio. En un directorio con muchos controladores de dominio es muy poco probable que la ubicación predeterminada se corresponda de la mejor forma con la red.
Si se utiliza como base el dominio, seleccione los controladores de dominio FSMO principal y de reserva en caso de que se produzca un error en el propietario de FSMO principal. Además, puede ser conveniente seleccionar los propietarios de reserva fuera del sitio por si se produce una situación de desastre específica de un sitio. Considere lo siguiente en sus criterios de selección:

  • Si un dominio tiene sólo un controlador de dominio, éste contiene todas las funciones para cada dominio.
  • Si un dominio tiene más de un controlador de dominio, utilice el Administrador de sitios y servicios de Active Directory para seleccionar los asociados de replicación directos con vínculos persistentes, "bien conectados".
  • El servidor de reserva puede estar en el mismo sitio que el servidor de FSMO principal para que la coherencia de la convergencia de la replicación sea más rápida a través de un grupo grande de equipos, o en un sitio remoto por si se produce un desastre específico del sitio en la ubicación principal.
  • Cuando el controlador de dominio de reserva esté en un sitio remoto, asegúrese de que la conexión se configura para la replicación continua sobre un vínculo persistente.

 

Recomendaciones generales para la ubicación de FSMO
  • Ubique las funciones del emulador de PDC y de RID en el mismo controlador de dominio. También es más fácil mantener el seguimiento de las funciones de FSMO si las agrupa en menos equipos.
    Si la carga del FSMO principal justifica un cambio, ubique las funciones de emulador de controlador de dominio principal y de RID en controladores de dominio independientes del mismo dominio y sitio de Active Directory que sean asociados de replicación directos entre sí.
  • Como regla general, el maestro de infraestructura debería ser un servidor de catálogo que no fuera global y que tuviera un objeto de conexión directa con algún catálogo global del bosque, preferentemente en el mismo sitio de Active Directory. Dado que el servidor de catálogo global contiene una réplica parcial de cada objeto del bosque, el maestro de infraestructura, si se ubica en un servidor de catálogo global, nunca actualizará nada, porque no tiene ninguna referencia a los objetos que no contiene. Hay dos excepciones a la regla "no ubicar el maestro de infraestructura en un servidor de catálogo global":
    • Bosque de dominio único:
      En un bosque que contiene un único dominio de Active Directory, no hay ningún fantasma y por tanto el maestro de infraestructura no tiene ningún trabajo que hacer. El maestro de infraestructura se puede ubicar en cualquier controlador de dominio del dominio, independientemente de si hospeda el catálogo global o no.
    • Un bosque con varios dominios donde cada controlador de dominio de un dominio contiene el catálogo global:
      Si cada controlador de dominio de un dominio que forma parte de un bosque con varios dominios también hospeda el catálogo global, no hay ningún fantasma ni ningún trabajo que el maestro de infraestructura tenga que realizar. El maestro de infraestructura se puede ubicar en cualquier controlador de dominio de ese dominio.
  • En el bosque, las funciones de maestro de esquema y maestro de nombres de dominio se deben ubicar en el mismo controlador de dominio ya que se utilizan en muy pocas ocasiones y se deben controlar muy de cerca. Además, el FSMO del maestro de nombres de dominio también debería ser un servidor de catálogo global. Se producirá un error en ciertas operaciones que utilizan el maestro de nombres de dominio, como crear dominios secundarios de otros secundarios, si éste no es el caso.
    En un bosque en Windows Server 2003 del nivel funcional del bosque, no tiene que ubicar el maestro de nombres de dominio en un catálogo global.

Y, lo que es más importante, confirme que todas las funciones FSMO están disponibles mediante una de las consolas de administración (como Dsa.msc o Ntdsutil.exe).