Cuentas y grupos privilegiados en Active Directory <\/h2>\n
Esta secci\u00f3n proporciona informaci\u00f3n b\u00e1sica sobre las cuentas y grupos privilegiados en Active Directory con la intenci\u00f3n de explicar los aspectos comunes y las diferencias entre las cuentas y grupos privilegiados en Active Directory. Al comprender estas distinciones, ya sea que implemente las recomendaciones en Implementaci\u00f3n de modelos administrativos de m\u00ednimo privilegio al pie de la letra o elija personalizarlas para su organizaci\u00f3n, tiene las herramientas que necesita para proteger cada grupo y cuenta de manera adecuada.<\/p>\n
Cuentas y grupos privilegiados incorporados <\/h2>\n
Active Directory facilita la delegaci\u00f3n de administraci\u00f3n y respalda el principio de privilegio m\u00ednimo al asignar derechos y permisos. Los usuarios "normales" que tienen cuentas en un dominio pueden, por defecto, leer gran parte de lo que est\u00e1 almacenado en el directorio, pero solo pueden cambiar un conjunto muy limitado de datos en el directorio. Los usuarios que requieren privilegios adicionales pueden obtener membres\u00eda en varios grupos "privilegiados" que est\u00e1n integrados en el directorio para que puedan realizar tareas espec\u00edficas relacionadas con sus roles, pero no pueden realizar tareas que no son relevantes para sus funciones. Las organizaciones tambi\u00e9n pueden crear grupos que se adaptan a las responsabilidades espec\u00edficas del trabajo y se les otorgan derechos y permisos detallados que permiten al personal de TI realizar las funciones administrativas cotidianas sin otorgar derechos y permisos que excedan lo que se requiere para esas funciones.<\/p>\n
Dentro de Active Directory, tres grupos integrados son los grupos de privilegios m\u00e1s altos en el directorio: Administradores de empresa, Administradores de dominio y Administradores. La configuraci\u00f3n y las capacidades predeterminadas de cada uno de estos grupos se describen en las siguientes secciones:<\/p>\n
Los grupos de privilegios m\u00e1s altos en Active Directory <\/h2>\nAdministradores de la empresa <\/h4>\n
Los Administradores de empresa (EA) son un grupo que existe solo en el dominio ra\u00edz del bosque y, de manera predeterminada, es un miembro del grupo Administradores en todos los dominios del bosque. La cuenta de administrador integrada en el dominio ra\u00edz del bosque es el \u00fanico miembro predeterminado del grupo de EA. A los EA se les otorgan derechos y permisos que les permiten implementar cambios en todo el bosque (es decir, cambios que afectan a todos los dominios del bosque), como agregar o eliminar dominios, establecer confianzas forestales o elevar los niveles funcionales del bosque. En un modelo de delegaci\u00f3n correctamente dise\u00f1ado e implementado, la membres\u00eda EA se requiere solo cuando se construye el bosque por primera vez o cuando se realizan ciertos cambios en todo el bosque, como el establecimiento de una confianza forestal saliente. La mayor\u00eda de los derechos y permisos otorgados al grupo EA se pueden delegar a usuarios y grupos con menores privilegios.<\/p>\n
Administradores del dominio <\/h4>\n
Cada dominio en un bosque tiene su propio grupo Administradores de dominio (DA), que es miembro del grupo Administradores de ese dominio y miembro del grupo Administradores local en cada computadora que se une al dominio. El \u00fanico miembro predeterminado del grupo DA para un dominio es la cuenta de administrador integrada para ese dominio. Los DA son "todopoderosos" dentro de sus dominios, mientras que los EA tienen privilegios en todo el bosque. En un modelo de delegaci\u00f3n correctamente dise\u00f1ado e implementado, la membres\u00eda de Administradores de Dominio deber\u00eda ser requerida solo en escenarios de "interrupci\u00f3n" (como situaciones en las que se necesita una cuenta con altos niveles de privilegios en cada computadora del dominio). Aunque los mecanismos de delegaci\u00f3n nativos de Active Directory permiten la delegaci\u00f3n en la medida en que es posible usar cuentas DA solo en situaciones de emergencia, construir un modelo de delegaci\u00f3n efectivo puede llevar mucho tiempo, y muchas organizaciones aprovechan las herramientas de terceros para agilizar el proceso.<\/p>\n
Administradores <\/h4>\n
El tercer grupo es el grupo de administradores locales de dominio (BA) en el que est\u00e1n anidados los DA y los EA. A este grupo se le otorgan muchos de los derechos y permisos directos en el directorio y en los controladores de dominio. Sin embargo, el grupo Administradores para un dominio no tiene privilegios en los servidores miembro o en las estaciones de trabajo. Es a trav\u00e9s de la membres\u00eda en el grupo de administradores locales de las computadoras que se concede el privilegio local.<\/p>\n
Nota: Aunque estas son las configuraciones predeterminadas de estos grupos con privilegios, un miembro de cualquiera de los tres grupos puede manipular el directorio para ganar membres\u00eda en cualquiera de los otros grupos. En algunos casos, es trivial obtener membres\u00eda en los otros grupos, mientras que en otros es m\u00e1s dif\u00edcil, pero desde la perspectiva del privilegio potencial, los tres grupos deben considerarse efectivamente equivalentes.<\/p>\n
Administradores de esquema <\/h6>\n
Un cuarto grupo privilegiado, Schema Admins (SA), existe solo en el dominio ra\u00edz del bosque y solo tiene la cuenta de administrador incorporada de ese dominio como miembro predeterminado, similar al grupo Administradores de la empresa. El grupo de administradores de esquema est\u00e1 destinado a poblarse solo de forma temporal y ocasional (cuando se requiere la modificaci\u00f3n del esquema de AD DS).<\/p>\n
Aunque el grupo SA es el \u00fanico grupo que puede modificar el esquema de Active Directory (es decir, las estructuras de datos subyacentes del directorio como objetos y atributos), el alcance de los derechos y permisos del grupo SA es m\u00e1s limitado que los grupos descritos anteriormente. Tambi\u00e9n es com\u00fan encontrar que las organizaciones han desarrollado pr\u00e1cticas apropiadas para el manejo de la membres\u00eda del grupo de SA porque la membres\u00eda en el grupo generalmente se necesita con poca frecuencia, y solo por cortos per\u00edodos de tiempo. Esto tambi\u00e9n es t\u00e9cnicamente cierto para los grupos EA, DA y BA en Active Directory, pero es mucho menos com\u00fan encontrar que las organizaciones hayan implementado pr\u00e1cticas similares para estos grupos como para el grupo SA.<\/p>\n
Cuentas y grupos protegidos en Active Directory <\/h4>\n
Dentro de Active Directory, un conjunto predeterminado de cuentas y grupos privilegiados llamados cuentas y grupos "protegidos" se protegen de forma diferente que otros objetos en el directorio. Cualquier cuenta que tenga membres\u00eda directa o transitiva en cualquier grupo protegido (independientemente de si la membres\u00eda proviene de grupos de seguridad o distribuci\u00f3n) hereda esta seguridad restringida.<\/p>\n
Por ejemplo, si un usuario es miembro de un grupo de distribuci\u00f3n que, a su vez, es miembro de un grupo protegido en Active Directory, ese objeto de usuario se marca como una cuenta protegida. Cuando una cuenta se marca como una cuenta protegida, el valor del atributo adminCount en el objeto se establece en 1.<\/p>\n
Nota: Aunque la membres\u00eda transitiva en un grupo protegido incluye distribuci\u00f3n anidada y grupos de seguridad anidados, las cuentas que son miembros de grupos de distribuci\u00f3n anidados no recibir\u00e1n el SID del grupo protegido en sus tokens de acceso. Sin embargo, los grupos de distribuci\u00f3n se pueden convertir a grupos de seguridad en Active Directory, por lo que los grupos de distribuci\u00f3n se incluyen en la enumeraci\u00f3n de miembros de grupos protegidos. Si un grupo de distribuci\u00f3n anidado protegido alguna vez se convierte a un grupo de seguridad, las cuentas que son miembros del grupo de distribuci\u00f3n anterior recibir\u00e1n posteriormente el SID del grupo protegido principal en sus tokens de acceso en el siguiente inicio de sesi\u00f3n.<\/p>\n
La siguiente tabla enumera las cuentas y grupos protegidos predeterminados en Active Directory por versi\u00f3n de sistema operativo y nivel de paquete de servicio.<\/p>\n
Cuentas y grupos protegidos predeterminados en Active Directory mediante el sistema operativo y la versi\u00f3n del Service Pack (SP)<\/h4>\n![\"www.radians.com.ar\"](\"http:\/\/www.radians.com.ar\/Articulos\/Images2018\/Reducir-la-superficie-de-ataque-de-Activ_A3A2\/a001_thumb.png\" "\\"www.radians.com.ar\\"")
<\/a><\/h4>\nAdminSDHolder y SDProp <\/h4>\n
En el contenedor Sistema de cada dominio de Active Directory, se crea autom\u00e1ticamente un objeto llamado AdminSDHolder. El objetivo del objeto AdminSDHolder es garantizar que los permisos en las cuentas y grupos protegidos se apliquen sistem\u00e1ticamente, independientemente de d\u00f3nde est\u00e9n ubicados los grupos protegidos y las cuentas en el dominio.<\/p>\n
Cada 60 minutos (de forma predeterminada), se ejecuta un proceso conocido como Propagador de descriptores de seguridad (SDProp) en el controlador de dominio que contiene la funci\u00f3n Emulador de PDC del dominio. SDProp compara los permisos en el objeto AdminSDHolder del dominio con los permisos en las cuentas y grupos protegidos en el dominio. Si los permisos en cualquiera de las cuentas y grupos protegidos no coinciden con los permisos del objeto AdminSDHolder, los permisos en las cuentas y grupos protegidos se restablecen para que coincidan con los del objeto AdminSDHolder del dominio.<\/p>\n
La herencia de permisos est\u00e1 deshabilitada en grupos y cuentas protegidas, lo que significa que incluso si las cuentas o grupos se mueven a diferentes ubicaciones en el directorio, no heredan los permisos de sus nuevos objetos principales. La herencia tambi\u00e9n est\u00e1 deshabilitada en el objeto AdminSDHolder para que los permisos cambien a los objetos principales no cambien los permisos de AdminSDHolder.<\/p>\n
Nota: Cuando se elimina una cuenta de un grupo protegido, ya no se considera una cuenta protegida, pero su atributo adminCount permanece establecido en 1 si no se cambia manualmente. El resultado de esta configuraci\u00f3n es que SDProp ya no actualiza las ACL del objeto, pero el objeto a\u00fan no hereda los permisos de su objeto principal. Por lo tanto, el objeto puede residir en una unidad organizativa (OU) a la que se han delegado permisos, pero el objeto anteriormente protegido no heredar\u00e1 estos permisos delegados. <\/p>\n
Propiedad de AdminSDHolder <\/h4>\n
La mayor\u00eda de los objetos en Active Directory son propiedad del grupo BA del dominio. Sin embargo, el objeto AdminSDHolder es, de forma predeterminada, propiedad del grupo DA del dominio. (Esta es una circunstancia en la que los DA no derivan sus derechos y permisos a trav\u00e9s de la membres\u00eda en el grupo Administradores para el dominio).<\/p>\n
En las versiones de Windows anteriores a Windows Server 2008, los propietarios de un objeto pueden cambiar los permisos del objeto, lo que incluye otorgarse permisos que originalmente no ten\u00edan. Por lo tanto, los permisos predeterminados en el objeto AdminSDHolder de un dominio impiden que los usuarios que son miembros de grupos BA o EA cambien los permisos para el objeto AdminSDHolder de un dominio. Sin embargo, los miembros del grupo Administradores para el dominio pueden tomar posesi\u00f3n del objeto y otorgarse permisos adicionales, lo que significa que esta protecci\u00f3n es rudimentaria y solo protege el objeto contra modificaciones accidentales por usuarios que no son miembros del grupo DA en el dominio . Adem\u00e1s, los grupos BA y EA (cuando corresponda) tienen permiso para cambiar los atributos del objeto AdminSDHolder en el dominio local (dominio ra\u00edz para EA).<\/p>\n
Nota: Un atributo en el objeto AdminSDHolder, dSHeuristics, permite la personalizaci\u00f3n (eliminaci\u00f3n) limitada de grupos que se consideran grupos protegidos y se ven afectados por AdminSDHolder y SDProp. Esta personalizaci\u00f3n debe considerarse cuidadosamente si se implementa, aunque existen circunstancias v\u00e1lidas en las cuales la modificaci\u00f3n de dSHeuristics en AdminSDHolder es \u00fatil. <\/p>\n
![\"www.radians.com.ar\"](\"http:\/\/www.radians.com.ar\/Articulos\/Images2018\/Reducir-la-superficie-de-ataque-de-Activ_A3A2\/a001.png\" "\\"www.radians.com.ar\\"")
<\/a><\/h4>\nAdminSDHolder y SDProp <\/h4>\n
En el contenedor Sistema de cada dominio de Active Directory, se crea autom\u00e1ticamente un objeto llamado AdminSDHolder. El objetivo del objeto AdminSDHolder es garantizar que los permisos en las cuentas y grupos protegidos se apliquen sistem\u00e1ticamente, independientemente de d\u00f3nde est\u00e9n ubicados los grupos protegidos y las cuentas en el dominio.<\/p>\n
Cada 60 minutos (de forma predeterminada), se ejecuta un proceso conocido como Propagador de descriptores de seguridad (SDProp) en el controlador de dominio que contiene la funci\u00f3n Emulador de PDC del dominio. SDProp compara los permisos en el objeto AdminSDHolder del dominio con los permisos en las cuentas y grupos protegidos en el dominio. Si los permisos en cualquiera de las cuentas y grupos protegidos no coinciden con los permisos del objeto AdminSDHolder, los permisos en las cuentas y grupos protegidos se restablecen para que coincidan con los del objeto AdminSDHolder del dominio.<\/p>\n
La herencia de permisos est\u00e1 deshabilitada en grupos y cuentas protegidas, lo que significa que incluso si las cuentas o grupos se mueven a diferentes ubicaciones en el directorio, no heredan los permisos de sus nuevos objetos principales. La herencia tambi\u00e9n est\u00e1 deshabilitada en el objeto AdminSDHolder para que los permisos cambien a los objetos principales no cambien los permisos de AdminSDHolder.<\/p>\n
Nota: Cuando se elimina una cuenta de un grupo protegido, ya no se considera una cuenta protegida, pero su atributo adminCount permanece establecido en 1 si no se cambia manualmente. El resultado de esta configuraci\u00f3n es que SDProp ya no actualiza las ACL del objeto, pero el objeto a\u00fan no hereda los permisos de su objeto principal. Por lo tanto, el objeto puede residir en una unidad organizativa (OU) a la que se han delegado permisos, pero el objeto anteriormente protegido no heredar\u00e1 estos permisos delegados. <\/p>\n
Propiedad de AdminSDHolder <\/h4>\n
La mayor\u00eda de los objetos en Active Directory son propiedad del grupo BA del dominio. Sin embargo, el objeto AdminSDHolder es, de forma predeterminada, propiedad del grupo DA del dominio. (Esta es una circunstancia en la que los DA no derivan sus derechos y permisos a trav\u00e9s de la membres\u00eda en el grupo Administradores para el dominio).<\/p>\n
En las versiones de Windows anteriores a Windows Server 2008, los propietarios de un objeto pueden cambiar los permisos del objeto, lo que incluye otorgarse permisos que originalmente no ten\u00edan. Por lo tanto, los permisos predeterminados en el objeto AdminSDHolder de un dominio impiden que los usuarios que son miembros de grupos BA o EA cambien los permisos para el objeto AdminSDHolder de un dominio. Sin embargo, los miembros del grupo Administradores para el dominio pueden tomar posesi\u00f3n del objeto y otorgarse permisos adicionales, lo que significa que esta protecci\u00f3n es rudimentaria y solo protege el objeto contra modificaciones accidentales por usuarios que no son miembros del grupo DA en el dominio . Adem\u00e1s, los grupos BA y EA (cuando corresponda) tienen permiso para cambiar los atributos del objeto AdminSDHolder en el dominio local (dominio ra\u00edz para EA).<\/p>\n
Nota: Un atributo en el objeto AdminSDHolder, dSHeuristics, permite la personalizaci\u00f3n (eliminaci\u00f3n) limitada de grupos que se consideran grupos protegidos y se ven afectados por AdminSDHolder y SDProp. Esta personalizaci\u00f3n debe considerarse cuidadosamente si se implementa, aunque existen circunstancias v\u00e1lidas en las cuales la modificaci\u00f3n de dSHeuristics en AdminSDHolder es \u00fatil. <\/p>\n