Los problemas de cliente, servicio y programa pueden producirse si cambia la configuración de seguridad y las asignaciones de derechos de usuario

Resumen

La configuración de seguridad y las asignaciones de derechos de usuario se pueden cambiar en las directivas locales y en las directivas de grupo para ayudar a aumentar la seguridad de los controladores de dominio y los equipos miembros. Sin embargo, la desventaja del aumento de la seguridad es la introducción de incompatibilidades con clientes, servicios y programas.

En este artículo se describen las incompatibilidades que pueden producirse en equipos cliente que ejecutan Windows XP o una versión anterior de Windows al cambiar configuraciones de seguridad específicas y asignaciones de derechos de usuario en un dominio de Windows Server 2003 o en un dominio de Windows Server anterior.

Para obtener información sobre directiva de grupo para Windows 7, Windows Server 2008 R2 y Windows Server 2008, vea los artículos siguientes:

Para Windows 7, consulta administración de directiva de grupo para profesionales de TI
Para Windows 7 y Windows Server 2008 R2, consulte Novedades de directiva de grupo

Nota: El contenido restante de este artículo es específico de Windows XP, Windows Server 2003 y versiones anteriores de Windows.

Windows XP

Para aumentar el conocimiento de la configuración de seguridad mal configurada, usa la herramienta Editor de objetos directiva de grupo para cambiar la configuración de seguridad. Al usar directiva de grupo Editor de objetos, las asignaciones de derechos de usuario se mejoran en los siguientes sistemas operativos:

Windows XP Professional Service Pack 2 (SP2)
Windows Server 2003 Service Pack 1 (SP1)

La característica mejorada es un cuadro de diálogo que contiene un vínculo a este artículo. El cuadro de diálogo aparece al cambiar una configuración de seguridad o una asignación de derechos de usuario a una configuración que ofrece menos compatibilidad y es más restrictiva. Si cambia directamente la misma configuración de seguridad o asignación de derechos de usuario mediante el Registro o mediante plantillas de seguridad, el efecto es el mismo que cambiar la configuración en directiva de grupo Editor de objetos. Sin embargo, el cuadro de diálogo que contiene el vínculo a este artículo no aparece.

Este artículo contiene ejemplos de clientes, programas y operaciones que se ven afectados por configuraciones de seguridad específicas o asignaciones de derechos de usuario. Sin embargo, los ejemplos no son relevantes para todos los sistemas operativos de Microsoft, para todos los sistemas operativos de terceros o para todas las versiones de programa afectadas. No todas las asignaciones de derechos de usuario y configuración de seguridad se incluyen en este artículo.

Se recomienda validar la compatibilidad de todos los cambios de configuración relacionados con la seguridad en un bosque de prueba antes de introducirlos en un entorno de producción. El bosque de prueba debe reflejar el bosque de producción de las siguientes maneras:

Versiones del sistema operativo cliente y servidor, programas de cliente y servidor, versiones de Service Pack, revisiones, cambios de esquema, grupos de seguridad, pertenencias a grupos, permisos sobre objetos en el sistema de archivos, carpetas compartidas, registro, servicio de directorio de Active Directory, configuración de directiva de grupo y local, y tipo y ubicación de recuento de objetos
Tareas administrativas que se realizan, herramientas administrativas que se usan y sistemas operativos que se usan para realizar tareas administrativas
Operaciones que se realizan, como las siguientes:
- Autenticación de inicio de sesión de usuario y equipo
- La contraseña la restablecen los usuarios, los equipos y los administradores
- Navegación
- Establecer permisos para el sistema de archivos, para las carpetas compartidas, para el Registro y para los recursos de Active Directory mediante el uso del Editor ACL en todos los sistemas operativos cliente en todos los dominios de cuentas o recursos de todos los sistemas operativos de cliente de todos los dominios de cuentas o recursos
- Impresión desde cuentas administrativas y no administrativas

Windows Server 2003 SP1

Advertencias en Gpedit.msc

Para ayudar a que los clientes sean conscientes de que están editando una opción de seguridad o derecha de usuario que podría haber afectado negativamente a su red, se agregaron dos mecanismos de advertencia a gpedit.msc. Cuando los administradores editen un derecho de usuario que puede afectar negativamente a toda la empresa, verán un nuevo icono que se parece a un signo de rendimiento. También recibirán un mensaje de advertencia con un vínculo al artículo de Microsoft Knowledge Base 823659. El texto de este mensaje es el siguiente:

La modificación de esta configuración puede afectar a la compatibilidad con clientes, servicios y aplicaciones. Para obtener más información, consulte <opción de seguridad o derecho del usuario modificada> (Q823659) Si se le indicó este artículo de Knowledge Base desde un vínculo de Gpedit.msc, asegúrese de leer y comprender la explicación proporcionada y el posible efecto de cambiar esta configuración. A continuación se enumeran los derechos de usuario que contienen el texto de advertencia:

Obtener acceso a este equipo desde la red
Iniciar sesión localmente
Omitir la comprobación de poligonal
Habilitar equipos y usuarios para la delegación de confianza

A continuación se enumeran las opciones de seguridad que tienen la advertencia y un mensaje emergente:

Miembro del dominio: cifrar digitalmente o firmar datos de canal seguro (siempre)
Miembro del dominio: Requerir una clave de sesión segura (Windows 2000 o una versión posterior)
Controlador de dominio: Requisitos de firma de servidor LDAP
Servidor de red de Microsoft: Comunicaciones de firma digital (siempre)
Acceso de red: permite la traducción de nombres o sid anónimos
Acceso de red: No permitir la enumeración anónima de cuentas y recursos compartidos SAM
Seguridad de red: nivel de autenticación de LAN Manager
Auditoría: Apagar el sistema inmediatamente si no se pueden registrar las auditorías de seguridad
Acceso de red: Requisitos de firma de cliente LDAP

Más información

Las siguientes secciones describen incompatibilidades que pueden producirse al cambiar la configuración específica en dominios de Windows NT 4.0, dominios de Windows 2000 y dominios de Windows Server 2003.

Derechos de usuario

La siguiente lista describe un derecho de usuario, identifica las opciones de configuración que pueden causar problemas, describe por qué debe aplicar el derecho de usuario y por qué desea quitar el derecho de usuario, y proporciona ejemplos de problemas de compatibilidad que pueden producirse cuando se configura el derecho del usuario.

Obtener acceso a este equipo desde la red
1. Fondo
  
  La capacidad de interactuar con equipos remotos basados en Windows requiere tener acceso a este equipo desde el usuario de red. Algunos ejemplos de estas operaciones de red son los siguientes:
  - Replicación de Active Directory entre controladores de dominio en un dominio o bosque común
  - Solicitudes de autenticación a controladores de dominio de usuarios y equipos
  - Acceso a carpetas compartidas, impresoras y otros servicios del sistema ubicados en equipos remotos de la red
  Los usuarios, los equipos y las cuentas de servicio obtienen o pierden el acceso a este equipo del usuario de red al agregarse o quitarse explícita o implícitamente de un grupo de seguridad al que se le ha concedido el derecho de usuario. Por ejemplo, una cuenta de usuario o una cuenta de equipo se puede agregar explícitamente a un grupo de seguridad personalizado o a un grupo de seguridad integrado por un administrador, o puede que el sistema operativo lo agregue implícitamente a un grupo de seguridad calculado, como Usuarios de dominio, Usuarios autenticados o Controladores de dominio empresarial.
  
  De forma predeterminada, las cuentas de usuario y las cuentas de equipo tienen acceso a este equipo desde el usuario de red directamente cuando los grupos calculados, como Todos o, preferiblemente, Usuarios autenticados y, para los controladores de dominio, el grupo Controladores de dominio de empresa, se definen en los controladores de dominio predeterminados directiva de grupo Object (GPO).
2. Configuraciones arriesgadas
  
  A continuación se muestran las opciones de configuración perjudiciales:
  - Quitar el grupo de seguridad Controladores de dominio de empresa de este usuario
  - Quitar el grupo Usuarios autenticados o un grupo explícito que permita a los usuarios, equipos y cuentas de servicio al usuario conectarse a equipos a través de la red
  - Derecho de quitar todos los usuarios y equipos de este usuario
3. Razones para conceder a este usuario el derecho
  - Conceder el acceso a este equipo desde el usuario de red al grupo Controladores de dominio de empresa cumple los requisitos de autenticación que la replicación de Active Directory debe tener para que la replicación se produzca entre controladores de dominio en el mismo bosque.
  - Este derecho de usuario permite a los usuarios y equipos acceder a archivos compartidos, impresoras y servicios del sistema, incluido Active Directory.
  - Este derecho de usuario es necesario para que los usuarios tengan acceso al correo mediante versiones anteriores de Microsoft Outlook Web Access (OWA).
4. Motivos para quitar este derecho de usuario
  - Los usuarios que pueden conectar sus equipos a la red pueden acceder a recursos de equipos remotos para los que tienen permisos. Por ejemplo, este derecho de usuario es necesario para que un usuario se conecte a impresoras compartidas y carpetas. Si este derecho de usuario se concede al grupo Todos y algunas carpetas compartidas tienen permisos de sistema de archivos NTFS y de uso compartido configurados para que el mismo grupo tenga acceso de lectura, cualquiera puede ver los archivos en esas carpetas compartidas. Sin embargo, esta es una situación poco probable para las instalaciones nuevas de Windows Server 2003 porque el recurso compartido predeterminado y los permisos NTFS de Windows Server 2003 no incluyen el grupo Todos los usuarios. Para los sistemas que se actualizan desde Microsoft Windows NT 4.0 o Windows 2000, esta vulnerabilidad puede tener un mayor nivel de riesgo porque el recurso compartido predeterminado y los permisos del sistema de archivos para estos sistemas operativos no son tan restrictivos como los permisos predeterminados en Windows Server 2003.
  - No hay ningún motivo válido para quitar el grupo Controladores de dominio de empresa de este derecho de usuario.
  - El grupo Todos se elimina generalmente a favor del grupo Usuarios autenticados. Si se quita el grupo Todos, el grupo Usuarios autenticados debe tener este derecho de usuario.
  - Los dominios de Windows NT 4.0 actualizados a Windows 2000 no conceden explícitamente el acceso a este equipo desde el usuario de red al grupo Todos, al grupo Usuarios autenticados o al grupo Controladores de dominio de empresa. Por lo tanto, al quitar el grupo Todos de la directiva de dominio de Windows NT 4.0, la replicación de Active Directory producirá un error con un mensaje de error "Acceso denegado" después de actualizar a Windows 2000. Winnt32.exe en Windows Server 2003 evita este error de configuración al conceder a este usuario el grupo Controladores de dominio de empresa al actualizar los controladores de dominio principales (PDC) de Windows NT 4.0. Conceda derecho al grupo Controladores de dominio de empresa a este usuario si no está presente en el Editor de objetos de directiva de grupo.
5. Ejemplos de problemas de compatibilidad
  - Windows 2000 y Windows Server 2003: se producirá un error en la replicación de las particiones siguientes con errores de "Acceso denegado", según han informado las herramientas de supervisión, como REPLMON y REPADMIN, o los eventos de replicación en el registro de eventos.
    - Partición de esquema de Active Directory
    - Partición de configuración
    - Partición de dominio
    - Partición del catálogo global
    - Partición de aplicación
  - Todos los sistemas operativos de red de Microsoft: se producirá un error en la autenticación de cuentas de usuario de equipos cliente de red remota, a menos que el usuario o un grupo de seguridad del que sea miembro se le haya concedido este derecho de usuario.
  - Todos los sistemas operativos de la red de Microsoft: se producirá un error en la autenticación de la cuenta de los clientes de red remota, a menos que la cuenta o un grupo de seguridad del que sea miembro se le haya concedido este derecho de usuario. Este escenario se aplica a cuentas de usuario, cuentas de equipo y cuentas de servicio.
  - Todos los sistemas operativos de red de Microsoft: quitar todas las cuentas de este derecho de usuario impedirá que cualquier cuenta inicie sesión en el dominio o acceda a los recursos de red. Si se quitan grupos calculados como Controladores de dominio de empresa, Todos o Usuarios autenticados, debe conceder explícitamente a este usuario el derecho a cuentas o a grupos de seguridad a los que pertenece la cuenta para tener acceso a equipos remotos a través de la red. Este escenario se aplica a todas las cuentas de usuario, a todas las cuentas de equipo y a todas las cuentas de servicio.
  - Todos los sistemas operativos de la red de Microsoft: la cuenta de administrador local usa una contraseña "en blanco". La conectividad de red con contraseñas en blanco no está permitida para las cuentas de administrador en un entorno de dominio. Con esta configuración, recibirá un mensaje de error "Acceso denegado".
Permitir iniciar sesión localmente
1. Fondo
  
  Los usuarios que intentan iniciar sesión en la consola de un equipo basado en Windows (mediante el método abreviado de teclado CTRL+ALT+SUPRIMIR) y las cuentas que intentan iniciar un servicio deben tener privilegios de inicio de sesión local en el equipo de hospedaje. Algunos ejemplos de operaciones de inicio de sesión local son los administradores que inician sesión en las consolas de los equipos miembros o los controladores de dominio en toda la empresa y los usuarios de dominio que inician sesión en equipos miembros para acceder a sus escritorios con cuentas sin privilegios. Los usuarios que usan una conexión a Escritorio remoto o Terminal Services deben tener la opción Permitir el inicio de sesión local en equipos de destino que ejecuten Windows 2000 o Windows XP porque estos modos de inicio de sesión se consideran locales en el equipo de hospedaje. Los usuarios que inician sesión en un servidor que tiene Terminal Server habilitado y que no tienen este derecho de usuario pueden iniciar una sesión remota interactiva en dominios de Windows Server 2003 si tienen el derecho Permitir el inicio de sesión a través de Terminal Services.
2. Configuraciones arriesgadas
  
  A continuación se muestran las opciones de configuración perjudiciales:
  - Se quitan los grupos de seguridad administrativos, incluidos los operadores de cuenta, los operadores de copia de seguridad, los operadores de impresión o los operadores de servidor, y el grupo integrado Administradores de la directiva predeterminada del controlador de dominio.
  - Quitar las cuentas de servicio que usan los componentes y programas en equipos miembros y en controladores de dominio del dominio de la directiva predeterminada del controlador de dominio.
  - Quitar usuarios o grupos de seguridad que inician sesión en la consola de equipos miembros del dominio.
  - Quitar cuentas de servicio definidas en la base de datos local del Administrador de cuentas de seguridad (SAM) de equipos miembros o de equipos de grupo de trabajo.
  - Quitar cuentas administrativas no integradas que se autentican a través de Terminal Services que se ejecuta en un controlador de dominio.
  - Agregar todas las cuentas de usuario en el dominio explícita o implícitamente a través del grupo Todos a la derecha denegar el inicio de sesión local de inicio de sesión local. Esta configuración impedirá que los usuarios inicien sesión en cualquier equipo miembro o en cualquier controlador de dominio del dominio.
3. Razones para conceder a este usuario el derecho
  - Los usuarios deben tener el derecho Permitir el inicio de sesión local para acceder a la consola o al escritorio de un equipo de grupo de trabajo, un equipo miembro o un controlador de dominio.
  - Los usuarios deben tener este derecho de usuario para iniciar sesión en una sesión de Terminal Services que se ejecute en un equipo miembro o controlador de dominio basado en Windows 2000.
4. Motivos para quitar este derecho de usuario
  - Si no se restringe el acceso de la consola a cuentas de usuario legítimas, es posible que los usuarios no autorizados descarguen y ejecuten código malintencionado para cambiar sus derechos de usuario.
  - La eliminación del derecho Permitir el inicio de sesión local evita inicios de sesión no autorizados en las consolas de equipos, como controladores de dominio o servidores de aplicaciones.
  - La eliminación de este derecho de inicio de sesión impide que las cuentas que no son de dominio inicien sesión en la consola de los equipos miembros del dominio.
5. Ejemplos de problemas de compatibilidad
  - Servidores de terminales de Windows 2000: el derecho Permitir inicio de sesión local es necesario para que los usuarios inicien sesión en los servidores terminales de Windows 2000.
  - Windows NT 4.0, Windows 2000, Windows XP o Windows Server 2003: Se debe conceder a las cuentas de usuario el derecho de este usuario a iniciar sesión en la consola de los equipos que ejecutan Windows NT 4.0, Windows 2000, Windows XP o Windows Server 2003.
  - Windows NT 4.0 y versiones posteriores: en equipos que ejecutan Windows NT 4.0 y versiones posteriores, si agrega el derecho Permitir inicio de sesión en el usuario local, pero también concede de forma implícita o explícita el derecho de inicio de sesión denegar inicio de sesión local, las cuentas no podrán iniciar sesión en la consola de los controladores de dominio.
Omitir la comprobación de poligonal
1. Fondo
  
  La derecha de comprobación de poligonal de derivación permite al usuario examinar las carpetas en el sistema de archivos NTFS o en el Registro sin comprobar el permiso de acceso especial de la carpeta Traverse. La derecha omitir la comprobación de la poligonal del usuario no permite que el usuario enume el contenido de una carpeta. Permite al usuario atravesar solo sus carpetas.
2. Configuraciones arriesgadas
  
  A continuación se muestran las opciones de configuración perjudiciales:
  - Eliminación de cuentas no administrativas que inician sesión en equipos de Terminal Services basados en Windows 2000 o en equipos de Terminal Services basados en Windows Server 2003 que no tienen permisos de acceso a archivos y carpetas en el sistema de archivos.
  - Quitar el grupo Todos de la lista de entidades de seguridad que tienen este usuario derecho de forma predeterminada. Los sistemas operativos Windows, así como muchos programas, están diseñados con la expectativa de que cualquier persona que pueda acceder legítimamente al equipo tendrá derecho a omitir la comprobación de paso a través del usuario. Por lo tanto, quitar el grupo Todos de la lista de entidades de seguridad que tienen este derecho de usuario de forma predeterminada podría provocar inestabilidad del sistema operativo o errores del programa. Es mejor que deje esta configuración en su valor predeterminado.
3. Razones para conceder a este usuario el derecho
  
  La configuración predeterminada para la derecha del usuario de la comprobación de poligonal de omisión es permitir que cualquier usuario omita la comprobación de la poligonal. Para los administradores experimentados del sistema de Windows, este es el comportamiento esperado y configuran las listas de control de acceso (SACL) del sistema de archivos en consecuencia. El único escenario en el que la configuración predeterminada puede dar lugar a un contratiempo es si el administrador que configura permisos no comprende el comportamiento y espera que los usuarios que no pueden tener acceso a una carpeta principal no puedan acceder al contenido de las carpetas secundarias.
4. Motivos para quitar este derecho
  
  de usuario Para intentar impedir el acceso a los archivos o a las carpetas del sistema de archivos, las organizaciones que están muy preocupadas por la seguridad pueden sentir la tentación de quitar el grupo Todos, o incluso el grupo Usuarios, de la lista de grupos que tienen derecho de comprobación de paso de derivación del usuario.
5. Ejemplos de problemas de compatibilidad
  - Windows 2000, Windows Server 2003: si se quita el derecho de comprobación de paso de derivación del usuario o se configura incorrectamente en equipos que ejecutan Windows 2000 o Windows Server 2003, directiva de grupo configuración en la carpeta SYVOL no se replicará entre los controladores de dominio del dominio.
  - Windows 2000, Windows XP Professional, Windows Server 2003: los equipos que ejecuten Windows 2000, Windows XP Professional o Windows Server 2003 registrarán los eventos 1000 y 1202 y no podrán aplicar directivas de usuario y directivas de usuario cuando los permisos del sistema de archivos requeridos se quiten del árbol SYSVOL si se quita el derecho de comprobación de paso de derivación del usuario o si se configura incorrectamente.
  - Windows 2000, Windows Server 2003: en equipos que ejecutan Windows 2000 o Windows Server 2003, la pestaña Cuota del Explorador de Windows desaparecerá al ver las propiedades de un volumen.
  - Windows 2000: Es posible que los usuarios que no sean administradores que inicien sesión en un servidor terminal de Windows 2000 reciban el siguiente mensaje de error:
    
    Userinit.exe error de aplicación. La aplicación no se pudo inicializar correctamente 0xc0000142 haga clic en Aceptar para finalizar la aplicación.
  - Windows NT 4.0, Windows 2000, Windows XP y Windows Server 2003: es posible que los usuarios cuyos equipos ejecuten Windows NT 4.0, Windows 2000, Windows XP o Windows Server 2003 no puedan acceder a carpetas o archivos compartidos en carpetas compartidas y que reciban mensajes de error "Acceso denegado" si no se les concede el derecho de comprobación de paso de derivación del usuario.
  - Windows NT 4.0: En equipos basados en Windows NT 4.0, la eliminación de la derecha del usuario de comprobación de la cruz de derivación provocará que una copia de archivo deje de recibir secuencias de archivos. Si quita este derecho de usuario, cuando se copia un archivo de un cliente de Windows o de un cliente de Macintosh a un controlador de dominio de Windows NT 4.0 que ejecuta Servicios para Macintosh, la secuencia de archivos de destino se pierde y el archivo aparece como un archivo de solo texto.
  - Microsoft Windows 95, Microsoft Windows 98: en un equipo cliente que ejecuta Windows 95 o Windows 98, el uso neto * /home comando producirá un error con un mensaje de error "Acceso denegado" si el grupo Usuarios autenticados no se concede el derecho de comprobación de paso de derivación del usuario de comprobación.
  - Outlook Web Access: Los usuarios que no sean administradores no podrán iniciar sesión en Microsoft Outlook Web Access y recibirán un mensaje de error "Acceso denegado" si no se les concede la derecha de comprobación de la poligonal de omisión del usuario.

Configuración de seguridad

La siguiente lista identifica una configuración de seguridad y la lista anidada proporciona una descripción sobre la configuración de seguridad, identifica las opciones de configuración que pueden causar problemas, describe los motivos por los que debe aplicar la configuración de seguridad y, a continuación, describe los motivos por los que puede querer quitar la configuración de seguridad. A continuación, la lista anidada proporciona un nombre simbólico para la configuración de seguridad y la ruta de acceso del Registro de la configuración de seguridad. Por último, se proporcionan ejemplos de problemas de compatibilidad que pueden producirse cuando se configura la configuración de seguridad.

Auditoría: Apagar el sistema inmediatamente si no se pueden registrar las auditorías de seguridad
1. Fondo
  - Auditoría: Apagar el sistema inmediatamente si no se puede registrar la configuración de auditorías de seguridad determina si el sistema se apaga si no se pueden registrar eventos de seguridad. Esta configuración es necesaria para la evaluación C2 del programa Criterios de evaluación de seguridad en equipos de confianza (TCSEC) y para los criterios comunes de evaluación de seguridad de las tecnologías de la información para evitar eventos auditables si el sistema de auditoría no puede registrar esos eventos. Si se produce un error en el sistema de auditoría, el sistema se apaga y aparece un mensaje de error de detención.
  - Si el equipo no puede registrar eventos en el registro de seguridad, es posible que la evidencia crítica o la información importante de solución de problemas no estén disponibles para su revisión después de un incidente de seguridad.
2. Configuración arriesgada
  
  La siguiente es una configuración perjudicial: La opción Auditoría: Apagar el sistema inmediatamente si no se pueden registrar auditorías de seguridad está activada y el tamaño del registro de eventos de seguridad está restringido por la opción No sobrescribir eventos (borrar registro manualmente), la opción Sobrescribir eventos según sea necesario o la opción Sobrescribir eventos con más de días de número en Visor de eventos. Consulta la sección "Ejemplos de problemas de compatibilidad" para obtener información sobre riesgos específicos para equipos que ejecutan la versión publicada original de Windows 2000, Windows 2000 Service Pack 1 (SP1), Windows 2000 SP2 o Windows 2000 SP3.
3. Razones para habilitar esta configuración
  
  Si el equipo no puede registrar eventos en el registro de seguridad, es posible que la evidencia crítica o la información importante de solución de problemas no estén disponibles para su revisión después de un incidente de seguridad.
4. Motivos para deshabilitar esta configuración
  - Habilitación de la auditoría: apaga el sistema inmediatamente si no se puede registrar la configuración de auditorías de seguridad detiene el sistema si no se puede registrar una auditoría de seguridad por cualquier motivo. Normalmente, no se puede registrar un evento cuando el registro de auditoría de seguridad está lleno y cuando su método de retención especificado es la opción No sobrescribir eventos (borrar registro manualmente) o la opción Sobrescribir eventos con más de días de número .
  - La carga administrativa de habilitar la auditoría: apagar el sistema inmediatamente si no se puede registrar la configuración de auditorías de seguridad puede ser muy alta, especialmente si también activa la opción No sobrescribir eventos (borrar registro manualmente) para el registro de seguridad. Esta configuración proporciona responsabilidad individual de las acciones de los operadores. Por ejemplo, un administrador podría restablecer los permisos de todos los usuarios, equipos y grupos de una unidad organizativa (UO) en la que la auditoría se habilitaba mediante la cuenta de administrador integrada u otra cuenta compartida y, a continuación, denegar que restableciera dichos permisos. Sin embargo, habilitar la configuración reduce la solidez del sistema porque un servidor puede verse obligado a apagarse abrumandolo con eventos de inicio de sesión y con otros eventos de seguridad que se escriben en el registro de seguridad. Además, debido a que el apagado no es correcto, puede resultar un daño irreparable al sistema operativo, los programas o los datos. Aunque NTFS garantiza que la integridad del sistema de archivos se mantiene durante un apagado incorrecto del sistema, no puede garantizar que todos los archivos de datos de cada programa sigan estando en un formulario utilizable cuando se reinicie el sistema.
5. Nombre simbólico:
  
  Crashonauditfail
6. Ruta del Registro:
  
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\CrashOnAuditFail (Reg_DWORD)
7. Ejemplos de problemas de compatibilidad
  - Windows 2000: debido a un error, los equipos que ejecutan la versión original publicada de Windows 2000, Windows 2000 SP1, Windows 2000 SP2 o Windows Server SP3 pueden detener el registro de eventos antes de que se alcance el tamaño especificado en la opción Tamaño máximo de registro para el registro de eventos de seguridad. Este error se ha corregido en Windows 2000 Service Pack 4 (SP4). Asegúrate de que los controladores de dominio de Windows 2000 tengan instalado Windows 2000 Service Pack 4 antes de considerar la posibilidad de habilitar esta configuración.
  - Windows 2000, Windows Server 2003: los equipos que ejecutan Windows 2000 o Windows Server 2003 pueden dejar de responder y reiniciarse espontáneamente si la opción Auditoría: Apagar el sistema inmediatamente si no se puede registrar la configuración de auditorías de seguridad está activada, el registro de seguridad está lleno y no se puede sobrescribir una entrada del registro de eventos existente. Cuando se reinicie el equipo, aparecerá el siguiente mensaje de Error de detención:
    
    STOP: C0000244 {Error de auditoría}
    Error al intentar generar una auditoría de seguridad.
    
    Para recuperarlo, un administrador debe iniciar sesión, archivar el registro de seguridad (opcional), borrar el registro de seguridad y, a continuación, restablecer esta opción (opcional y según sea necesario).
  - Cliente de red de Microsoft para MS-DOS, Windows 95, Windows 98, Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003: los usuarios que no intenten iniciar sesión en un dominio recibirán el siguiente mensaje de error:
    
    Tu cuenta está configurada para impedir que uses este equipo. Prueba con otro equipo.
  - Windows 2000: en equipos basados en Windows 2000, los usuarios que no sean administradores no podrán iniciar sesión en servidores de acceso remoto y recibirán un mensaje de error similar al siguiente:
    
    Usuario desconocido o contraseña incorrecta
  - Windows 2000: en los controladores de dominio de Windows 2000, el servicio de mensajería entre sitios (Ismserv.exe) se detendrá y no se podrá reiniciar. DCDIAG notificará el error como "Error en los servicios de prueba ISMserv" y el id. de evento 1083 se registrará en el registro de eventos.
  - Windows 2000: en los controladores de dominio de Windows 2000, se producirá un error en la replicación de Active Directory y aparecerá un mensaje "Acceso denegado" si el registro de eventos de seguridad está completo.
  - Microsoft Exchange 2000: los servidores que ejecutan Exchange 2000 no podrán montar la base de datos del almacén de información y el evento 2102 se registrará en el registro de eventos.
  - Outlook, Outlook Web Access: los usuarios que no sean administradores no podrán acceder a su correo a través de Microsoft Outlook o de Microsoft Outlook Web Access, y recibirán un error 503.
Controlador de dominio: Requisitos de firma de servidor LDAP
1. Fondo
  
  El controlador de dominio: La configuración de seguridad de los requisitos de firma del servidor LDAP determina si el servidor ldap (Protocolo ligero de acceso a directorios) requiere que los clientes LDAP negocien la firma de datos. Los valores posibles para esta configuración de directiva son los siguientes:
  - Ninguno: la firma de datos no es necesaria para enlazar con el servidor. Si el cliente solicita la firma de datos, el servidor lo admite.
  - Requerir firma: la opción de firma de datos LDAP debe negociarse a menos que se esté usando seguridad de la capa de transporte/capa de sockets seguros (TLS/SSL).
  - no definido: esta configuración no está habilitada o deshabilitada.
2. Configuraciones arriesgadas
  
  A continuación se muestran las opciones de configuración perjudiciales:
  - Habilitar Requerir inicio de sesión en entornos en los que los clientes no admiten la firma LDAP o donde la firma LDAP del lado del cliente no está habilitada en el cliente
  - Aplicar la plantilla de seguridad Windows 2000 o Windows Server 2003 Hisecdc.inf en entornos donde los clientes no admiten la firma LDAP o donde no está habilitada la firma LDAP del lado cliente
  - Aplicar la plantilla de seguridad Windows 2000 o Windows Server 2003 Hisecws.inf en entornos donde los clientes no admiten la firma LDAP o donde la firma LDAP del lado cliente no está habilitada
3. Razones para habilitar esta configuración
  
  El tráfico de red sin firmar es susceptible a ataques man-in-the-middle donde un intruso captura paquetes entre el cliente y el servidor, modifica los paquetes y, a continuación, los reenvía al servidor. Cuando se produce este comportamiento en un servidor LDAP, un atacante podría hacer que un servidor tome decisiones basadas en consultas falsas del cliente LDAP. Puede reducir este riesgo en una red corporativa implementando fuertes medidas de seguridad física para ayudar a proteger la infraestructura de red. El modo de encabezado de autenticación de seguridad de protocolo de Internet (IPSec) puede ayudar a evitar ataques de tipo man-in-the-middle. El modo de encabezado de autenticación realiza la autenticación mutua y la integridad de paquetes para el tráfico IP.
4. Motivos para deshabilitar esta configuración
  - Los clientes que no admitan la firma LDAP no podrán realizar consultas LDAP con controladores de dominio y con catálogos globales si se negocia la autenticación NTLM y si los Service Pack correctos no están instalados en controladores de dominio de Windows 2000.
  - Los seguimientos de red del tráfico LDAP entre clientes y servidores se cifrarán. Esto dificulta examinar las conversaciones LDAP.
  - Los servidores basados en Windows 2000 deben tener Windows 2000 Service Pack 3 (SP3) o instalado cuando se administran con programas que admiten la firma LDAP que se ejecutan desde equipos cliente que ejecutan Windows 2000 SP4, Windows XP o Windows Server 2003.
5. Nombre simbólico:
  
  LDAPServerIntegrity
6. Ruta del Registro:
  
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LDAPServerIntegrity (Reg_DWORD)
7. Ejemplos de problemas de compatibilidad
  - Se producirá un error en los enlaces sencillos y recibirá el siguiente mensaje de error:
    
    error en Ldap_simple_bind_s(): se requiere autenticación segura.
  - Windows 2000 Service Pack 4, Windows XP y Windows Server 2003: En los clientes que ejecutan Windows 2000 SP4, Windows XP o Windows Server 2003, algunas herramientas de administración de Active Directory no funcionarán correctamente con controladores de dominio que ejecuten versiones de Windows 2000 anteriores a SP3 cuando se negocie la autenticación NTLM.
  - Windows 2000 Service Pack 4, Windows XP y Windows Server 2003: En los clientes que ejecutan Windows 2000 SP4, Windows XP o Windows Server 2003, algunas herramientas de administración de Active Directory que se dirigen a controladores de dominio que ejecutan versiones de Windows 2000 anteriores a SP3 no funcionarán correctamente si usan direcciones IP (por ejemplo, "dsa.msc /server=x.x.x.x" donde
    x.x.x.x es una dirección IP).
  - Windows 2000 Service Pack 4, Windows XP y Windows Server 2003: en los clientes que ejecutan Windows 2000 SP4, Windows XP o Windows Server 2003, algunas herramientas de administración de Active Directory que se dirigen a controladores de dominio que ejecutan versiones de Windows 2000 anteriores a SP3 no funcionarán correctamente.
Miembro de dominio: Requerir una clave de sesión segura (Windows 2000 o posterior)
1. Fondo
  - La configuración de clave de sesión Requerir una sesión segura (Windows 2000 o posterior) del miembro del dominio determina si se puede establecer un canal seguro con un controlador de dominio que no puede cifrar el tráfico de canal seguro con una clave de sesión segura de 128 bits. Habilitar esta configuración impide establecer un canal seguro con cualquier controlador de dominio que no pueda cifrar los datos del canal seguro con una clave segura. Deshabilitar esta configuración permite teclas de sesión de 64 bits.
  - Antes de habilitar esta configuración en una estación de trabajo miembro o en un servidor, todos los controladores de dominio del dominio al que pertenece el miembro deben poder cifrar los datos del canal seguro con una clave segura de 128 bits. Esto significa que todos estos controladores de dominio deben ejecutar Windows 2000 o posterior.
2. Configuración arriesgada
  
  Habilitar el miembro del dominio: requerir una configuración de clave de sesión segura (Windows 2000 o posterior) es una configuración perjudicial.
3. Razones para habilitar esta configuración
  - Las claves de sesión que se usan para establecer comunicaciones de canal seguro entre equipos miembros y controladores de dominio son mucho más seguras en Windows 2000 que en versiones anteriores de sistemas operativos de Microsoft.
  - Cuando es posible, es una buena idea aprovechar estas claves de sesión más seguras para ayudar a proteger las comunicaciones de canal seguras de escuchas y de ataques de red de secuestro de sesión. Eavesdropping es una forma de ataque malintencionado donde los datos de red se leen o se alteran durante el tránsito. Los datos se pueden modificar para ocultar, cambiar el remitente o redirigirlos.
  Importante Un equipo que ejecute Windows Server 2008 R2 o Windows 7 solo admite claves seguras cuando se usan canales seguros. Esta restricción impide una confianza entre cualquier dominio basado en Windows NT 4.0 y cualquier dominio basado en Windows Server 2008 R2. Además, esta restricción bloquea la pertenencia a dominio basada en Windows NT 4.0 de los equipos que ejecutan Windows 7 o Windows Server 2008 R2 y viceversa.
4. Motivos para deshabilitar esta configuración
  
  El dominio contiene equipos miembros que ejecutan sistemas operativos distintos de Windows 2000, Windows XP o Windows Server 2003.
5. Nombre simbólico:
  
  StrongKey
6. Ruta del Registro:
  
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\RequireStrongKey (Reg_DWORD)
7. Ejemplos de problemas
  
  de compatibilidad Windows NT 4.0: en equipos basados en Windows NT 4.0, se produce un error al restablecer los canales seguros de relaciones de confianza entre Windows NT 4.0 y los dominios de Windows 2000 con NLTEST. Aparece un mensaje de error "Acceso denegado":
  
  Error en la relación de confianza entre el dominio principal y el dominio de confianza.
  
  Windows 7 y Server 2008 R2: para Windows 7 y versiones posteriores y Windows Server 2008 R2 y versiones posteriores, esta configuración ya no se respeta y siempre se usa la clave segura. Por este motivo, la confianza en los dominios de Windows NT 4.0 ya no funciona.
Miembro del dominio: cifrar digitalmente o firmar datos de canal seguro (siempre)
1. Fondo
  - Habilitación del miembro del dominio: cifrar digitalmente o firmar datos de canal seguro (siempre) impide establecer un canal seguro con cualquier controlador de dominio que no pueda firmar o cifrar todos los datos de canal seguro. Para ayudar a proteger el tráfico de autenticación contra ataques de tipo man-in-the-middle, ataques de repetición y otros tipos de ataques de red, los equipos basados en Windows crean un canal de comunicación que se conoce como canal seguro a través del servicio Net Logon para autenticar cuentas de equipo. Los canales seguros también se usan cuando un usuario de un dominio se conecta a un recurso de red en un dominio remoto. Esta autenticación multidominio, o autenticación de paso a través, permite que un equipo basado en Windows que se haya unido a un dominio tenga acceso a la base de datos de cuentas de usuario en su dominio y en cualquier dominio de confianza.
  - Para habilitar el miembro del dominio: la configuración de cifrar o firmar digitalmente los datos de canal seguro (siempre) en un equipo miembro, todos los controladores de dominio del dominio al que pertenece el miembro deben poder firmar o cifrar todos los datos del canal seguro. Esto significa que todos estos controladores de dominio deben ejecutar Windows NT 4.0 con Service Pack 6a (SP6a) o posterior.
  - Habilitación del miembro del dominio: la configuración de cifrar o firmar digitalmente los datos del canal seguro (siempre) habilita automáticamente al miembro del dominio: cifrar o firmar digitalmente los datos de canal seguro (cuando sea posible).
2. Configuración arriesgada
  
  Habilitación del miembro del dominio: la configuración de cifrar o firmar digitalmente los datos de canal seguro (siempre) en dominios donde no todos los controladores de dominio pueden firmar o cifrar datos de canal seguro es una configuración perjudicial.
3. Razones para habilitar esta configuración
  
  El tráfico de red sin firmar es susceptible a ataques de tipo man-in-the-middle, donde un intruso captura paquetes entre el servidor y el cliente y luego los modifica antes de reenviarlos al cliente. Cuando se produce este comportamiento en un servidor ldap (Protocolo ligero de acceso a directorios), el intruso podría hacer que un cliente tome decisiones basadas en registros falsos del directorio LDAP. Puede reducir el riesgo de un ataque de este tipo en una red corporativa implementando fuertes medidas de seguridad física para ayudar a proteger la infraestructura de red. Además, implementar el modo de encabezado de autenticación de seguridad de protocolo de Internet (IPSec) puede ayudar a evitar ataques de tipo man-in-the-middle. Este modo realiza la autenticación mutua y la integridad de paquetes para el tráfico IP.
4. Motivos para deshabilitar esta configuración
  - Los equipos de dominios locales o externos admiten canales seguros cifrados.
  - No todos los controladores de dominio del dominio tienen los niveles de revisión de Service Pack adecuados para admitir canales seguros cifrados.
5. Nombre simbólico:
  
  StrongKey
6. Ruta del Registro:
  
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\RequireSignOrSeal (REG_DWORD)
7. Ejemplos de problemas de compatibilidad
  - Windows NT 4.0: Los equipos miembros basados en Windows 2000 no podrán unirse a dominios de Windows NT 4.0 y recibirán el siguiente mensaje de error:
    
    La cuenta no está autorizada para iniciar sesión desde esta estación.
    
    Para obtener más información, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
    
    281648 Mensaje de error: La cuenta no está autorizada para iniciar sesión desde esta estación
  - Windows NT 4.0: Los dominios de Windows NT 4.0 no podrán establecer una confianza de nivel inferior con un dominio de Windows 2000 y recibirán el siguiente mensaje de error:
    
    La cuenta no está autorizada para iniciar sesión desde esta estación.
    
    Es posible que las confianzas de nivel inferior existentes tampoco autentiquen a los usuarios del dominio de confianza. Algunos usuarios pueden tener problemas para iniciar sesión en el dominio y pueden recibir un mensaje de error que indica que el cliente no puede encontrar el dominio.
  - Windows XP: los clientes de Windows XP unidos a dominios de Windows NT 4.0 no podrán autenticar intentos de inicio de sesión y pueden recibir el siguiente mensaje de error, o pueden registrarse los siguientes eventos en el registro de eventos:
    
    Windows no puede conectarse al dominio porque el controlador de dominio no está disponible o porque no se encontró su cuenta de equipo
  - Microsoft Network: Los clientes de Microsoft Network recibirán uno de los siguientes mensajes de error:
    
    Error de inicio de sesión: nombre de usuario desconocido o contraseña incorrecta.
    
    No hay ninguna clave de sesión de usuario para la sesión de inicio de sesión especificada.
Cliente de red de Microsoft: Comunicaciones de firma digital (siempre)
1. Fondo
  
  Bloque de mensajes de servidor (SMB) es el protocolo de uso compartido de recursos que son compatibles con muchos sistemas operativos de Microsoft. Es la base del sistema básico de entrada y salida de red (NetBIOS) y de muchos otros protocolos. La firma SMB autentica tanto al usuario como al servidor que hospeda los datos. Si alguno de los lados produce errores en el proceso de autenticación, no se producirá la transmisión de datos.
  
  La habilitación de la firma SMB comienza durante la negociación del protocolo SMB. Las directivas de firma de SMB determinan si el equipo siempre firma digitalmente las comunicaciones del cliente.
  
  El protocolo de autenticación SMB de Windows 2000 admite la autenticación mutua. La autenticación mutua cierra un ataque de "hombre en el medio". El protocolo de autenticación SMB de Windows 2000 también admite la autenticación de mensajes. La autenticación de mensajes ayuda a evitar ataques de mensajes activos. Para proporcionarte esta autenticación, la firma SMB coloca una firma digital en cada SMB. El cliente y el servidor comprueban cada uno la firma digital.
  
  Para usar la firma de SMB, debe habilitar la firma smb o requerir la firma SMB en el cliente smb y el servidor SMB. Si la firma smb está habilitada en un servidor, los clientes que también están habilitados para la firma SMB usan el protocolo de firma de paquetes durante todas las sesiones posteriores. Si se requiere la firma smb en un servidor, un cliente no puede establecer una sesión a menos que el cliente esté habilitado o sea necesario para la firma smb.
  
  Habilitar la firma digital en redes de alta seguridad ayuda a evitar la suplantación de clientes y de servidores. Este tipo de suplantación se conoce como secuestro de sesiones. Un atacante que tiene acceso a la misma red que el cliente o el servidor usa herramientas de secuestro de sesión para interrumpir, finalizar o robar una sesión en curso. Un atacante podría interceptar y modificar paquetes SMB sin firmar, modificar el tráfico y, a continuación, reenviarlo para que el servidor pudiera realizar acciones no deseadas. O bien, el atacante podría hacerse pasar por el servidor o como el cliente después de una autenticación legítima y, a continuación, obtener acceso no autorizado a los datos.
  
  El protocolo SMB que se usa para el uso compartido de archivos y para el uso compartido de impresión en equipos que ejecutan Windows 2000 Server, Windows 2000 Professional, Windows XP Professional o Windows Server 2003 admite autenticación mutua. La autenticación mutua cierra los ataques de secuestro de sesión y admite la autenticación de mensajes. Por lo tanto, evita ataques de hombre en el medio. La firma SMB proporciona esta autenticación colocando una firma digital en cada PROTOCOLO SMB. Después, el cliente y el servidor verifican la firma.
  
  Notas
  - Como contramedidas alternativas, puede habilitar firmas digitales con IPSec para ayudar a proteger todo el tráfico de red. Existen aceleradores basados en hardware para cifrado IPSec y firma que puede usar para minimizar el impacto en el rendimiento de la CPU del servidor. No hay aceleradores de este tipo que estén disponibles para la firma smb.
    
    Para obtener más información, consulta el capítulo Firmar digitalmente las comunicaciones del servidor en el sitio web de Microsoft MSDN.
    
    Configure el inicio de sesión SMB a través de directiva de grupo Editor de objetos porque un cambio en un valor de registro local no tiene ningún efecto si hay una directiva de dominio reemplazante.
  - En Windows 95, Windows 98 y Windows 98 Second Edition, el cliente de servicios de directorio usa la firma SMB cuando se autentica con servidores de Windows Server 2003 mediante la autenticación NTLM. Sin embargo, estos clientes no usan la firma SMB cuando se autentican con estos servidores mediante la autenticación NTLMv2. Además, los servidores de Windows 2000 no responden a las solicitudes de firma smb de estos clientes. Para obtener más información, consulte el elemento 10: "Seguridad de red: nivel de autenticación de Lan Manager".
2. Configuración arriesgada
  
  El siguiente es un ajuste de configuración perjudicial: dejando el cliente de red de Microsoft: configuración de comunicaciones de firma digital (siempre) y el cliente de red de Microsoft: Comunicaciones de firma digital (si el servidor está de acuerdo) establecida en "No definido" o deshabilitado. Esta configuración permite al redirector enviar contraseñas de texto sin formato a servidores SMB que no son compatibles con el cifrado de contraseñas durante la autenticación.
3. Razones para habilitar esta configuración
  
  Habilitar el cliente de red de Microsoft: las comunicaciones de firma digital (siempre) requieren que los clientes firmen tráfico SMB cuando se pongan en contacto con servidores que no requieran firma SMB. Esto hace que los clientes sean menos vulnerables a los ataques de secuestro de sesiones.
4. Motivos para deshabilitar esta configuración
  - Habilitación del cliente de red de Microsoft: las comunicaciones de firma digital (siempre) impiden que los clientes se comuniquen con servidores de destino que no admitan la firma SMB.
  - La configuración de equipos para omitir todas las comunicaciones SMB sin firmar impide que se conecten programas y sistemas operativos anteriores.
5. Nombre simbólico:
  
  RequireSMBSignRdr
6. Ruta del Registro:
  
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\RequireSecuritySignature
7. Ejemplos de problemas de compatibilidad
  - Windows NT 4.0: No podrá restablecer el canal seguro de una confianza entre un dominio de Windows Server 2003 y un dominio de Windows NT 4.0 mediante NLTEST o NETDOM, y recibirá un mensaje de error "Acceso denegado".
  - Windows XP: copiar archivos de clientes de Windows XP a servidores basados en Windows 2000 y a servidores basados en Windows Server 2003 puede tardar más tiempo.
  - No podrás asignar una unidad de red desde un cliente con esta configuración habilitada y recibirás el siguiente mensaje de error:
    
    La cuenta no está autorizada para iniciar sesión desde esta estación.
8. Requisitos
  
  para reiniciar Reinicie el equipo o reinicie el servicio Estación de trabajo. Para ello, escribe los siguientes comandos en un símbolo del sistema. Presione Entrar después de escribir cada comando.
  
  estación de trabajo
  net stop net start workstation
Servidor de red de Microsoft: Comunicaciones de firma digital (siempre)
1. Fondo
  - Server Messenger Block (SMB) es el protocolo de uso compartido de recursos que son compatibles con muchos sistemas operativos de Microsoft. Es la base del sistema básico de entrada y salida de red (NetBIOS) y de muchos otros protocolos. La firma SMB autentica tanto al usuario como al servidor que hospeda los datos. Si alguno de los lados produce errores en el proceso de autenticación, no se producirá la transmisión de datos.
    
    La habilitación de la firma SMB comienza durante la negociación del protocolo SMB. Las directivas de firma de SMB determinan si el equipo siempre firma digitalmente las comunicaciones del cliente.
    
    El protocolo de autenticación SMB de Windows 2000 admite la autenticación mutua. La autenticación mutua cierra un ataque de "hombre en el medio". El protocolo de autenticación SMB de Windows 2000 también admite la autenticación de mensajes. La autenticación de mensajes ayuda a evitar ataques de mensajes activos. Para proporcionarte esta autenticación, la firma SMB coloca una firma digital en cada SMB. El cliente y el servidor comprueban cada uno la firma digital.
    
    Para usar la firma de SMB, debe habilitar la firma smb o requerir la firma SMB en el cliente smb y el servidor SMB. Si la firma smb está habilitada en un servidor, los clientes que también están habilitados para la firma SMB usan el protocolo de firma de paquetes durante todas las sesiones posteriores. Si se requiere la firma smb en un servidor, un cliente no puede establecer una sesión a menos que el cliente esté habilitado o sea necesario para la firma smb.
    
    Habilitar la firma digital en redes de alta seguridad ayuda a evitar la suplantación de clientes y de servidores. Este tipo de suplantación se conoce como secuestro de sesiones. Un atacante que tiene acceso a la misma red que el cliente o el servidor usa herramientas de secuestro de sesión para interrumpir, finalizar o robar una sesión en curso. Un atacante podría interceptar y modificar paquetes sin firmar del Administrador de ancho de banda de subred (SBM), modificar el tráfico y, a continuación, reenviarlo para que el servidor pudiera realizar acciones no deseadas. O bien, el atacante podría hacerse pasar por el servidor o como el cliente después de una autenticación legítima y, a continuación, obtener acceso no autorizado a los datos.
    
    El protocolo SMB que se usa para el uso compartido de archivos y para el uso compartido de impresión en equipos que ejecutan Windows 2000 Server, Windows 2000 Professional, Windows XP Professional o Windows Server 2003 admite autenticación mutua. La autenticación mutua cierra los ataques de secuestro de sesión y admite la autenticación de mensajes. Por lo tanto, evita ataques de hombre en el medio. La firma SMB proporciona esta autenticación colocando una firma digital en cada PROTOCOLO SMB. Después, el cliente y el servidor verifican la firma.
  - Como contramedidas alternativas, puede habilitar firmas digitales con IPSec para ayudar a proteger todo el tráfico de red. Existen aceleradores basados en hardware para cifrado IPSec y firma que puede usar para minimizar el impacto en el rendimiento de la CPU del servidor. No hay aceleradores de este tipo que estén disponibles para la firma smb.
  - En Windows 95, Windows 98 y Windows 98 Second Edition, el cliente de servicios de directorio usa la firma SMB cuando se autentica con servidores de Windows Server 2003 mediante la autenticación NTLM. Sin embargo, estos clientes no usan la firma SMB cuando se autentican con estos servidores mediante la autenticación NTLMv2. Además, los servidores de Windows 2000 no responden a las solicitudes de firma smb de estos clientes. Para obtener más información, consulte el elemento 10: "Seguridad de red: nivel de autenticación de Lan Manager".
2. Configuración arriesgada
  
  La siguiente es una configuración perjudicial: Habilitar el servidor de red de Microsoft: configuración de comunicaciones de firma digital (siempre) en servidores y en controladores de dominio a los que acceden equipos basados en Windows incompatibles y equipos cliente basados en sistemas operativos de terceros en dominios locales o externos.
3. Razones para habilitar esta configuración
  - Todos los equipos cliente que habilitan esta configuración directamente a través del Registro o a través de la configuración de directiva de grupo admiten la firma SMB. Es decir, todos los equipos cliente que tengan habilitada esta configuración ejecutan Windows 95 con el cliente DS instalado, Windows 98, Windows NT 4.0, Windows 2000, Windows XP Professional o Windows Server 2003.
  - Si el servidor de red de Microsoft: las comunicaciones de firma digital (siempre) están deshabilitadas, la firma de SMB está completamente deshabilitada. Deshabilitar completamente todas las firmas SMB deja los equipos más vulnerables a los ataques de secuestro de sesión.
4. Motivos para deshabilitar esta configuración
  - Habilitar esta configuración puede ralentizar el rendimiento de la copia de archivos y la red en los equipos cliente.
  - Si habilita esta configuración, evitará que los clientes que no puedan negociar la firma SMB se comuniquen con servidores y con controladores de dominio. Esto provoca errores en las operaciones como las combinaciones de dominios, la autenticación de usuarios y equipos o el acceso a la red por parte de los programas.
5. Nombre simbólico:
  
  RequireSMBSignServer
6. Ruta del Registro:
  
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters\RequireSecuritySignature (REG_DWORD)
7. Ejemplos de problemas de compatibilidad
  - Windows 95: los clientes de Windows 95 que no tengan instalado el cliente de servicios de directorio (DS) producirán un error de autenticación de inicio de sesión y recibirán el siguiente mensaje de error:
    
    La contraseña de dominio que ha proporcionado no es correcta o se ha denegado el acceso a su servidor de inicio de sesión.
  - Windows NT 4.0: Los equipos cliente que ejecutan versiones de Windows NT 4.0 anteriores a Service Pack 3 (SP3) no recibirán la autenticación de inicio de sesión y recibirán el siguiente mensaje de error:
    
    El sistema no pudo iniciar sesión. Asegúrese de que el nombre de usuario y el dominio son correctos y, a continuación, vuelva a escribir la contraseña.
    
    Algunos servidores SMB que no son de Microsoft admiten solo intercambios de contraseñas no cifradas durante la autenticación. (Estos intercambios también se conocen como intercambios de "texto sin formato"). Para Windows NT 4.0 SP3 y versiones posteriores, el redirector SMB no envía una contraseña no cifrada durante la autenticación a un servidor SMB a menos que agregue una entrada específica del Registro.
    Para habilitar contraseñas no cifradas para el cliente SMB en Windows NT 4.0 SP 3 y sistemas más recientes, modifique el Registro de la siguiente manera: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Rdr\Parameters
    
    Nombre del valor: EnablePlainTextPassword
    
    Tipo de datos: REG_DWORD
    
    Datos: 1
  - Windows Server 2003: de forma predeterminada, la configuración de seguridad de los controladores de dominio que ejecutan Windows Server 2003 se configura para ayudar a evitar que las comunicaciones del controlador de dominio sean interceptadas o manipuladas por usuarios malintencionados. Para que los usuarios se comuniquen correctamente con un controlador de dominio que ejecute Windows Server 2003, los equipos cliente deben usar la firma SMB y el cifrado o la firma de tráfico de canal seguro. De forma predeterminada, los clientes que ejecutan Windows NT 4.0 con Service Pack 2 (SP2) o una versión anterior instalada y los clientes que ejecutan Windows 95 no tienen habilitada la firma de paquetes SMB. Por lo tanto, es posible que estos clientes no puedan autenticarse con un controlador de dominio basado en Windows Server 2003.
  - Configuración de directivas de Windows 2000 y Windows Server 2003: según sus necesidades y configuración de instalación específicas, le recomendamos que establezca las siguientes opciones de directiva en la entidad más baja del ámbito necesario en la jerarquía del complemento Editor directiva de grupo Microsoft Management Console:
    - Configuración del equipo\Seguridad de Windows Configuración\Opciones de seguridad
    - Enviar contraseña no cifrada para conectarse a servidores SMB de terceros (esta configuración es para Windows 2000)
    - Cliente de red de Microsoft: Enviar contraseña no cifrada a servidores SMB de terceros (esta configuración es para Windows Server 2003)
    Nota En algunos servidores CIFS de terceros, como versiones anteriores de Samba, no puede usar contraseñas cifradas.
  - Los siguientes clientes no son compatibles con el servidor de red de Microsoft: configuración de comunicaciones de firma digital (siempre):
    - Clientes de Apple Computer, Inc., Mac OS X
    - Clientes de red de Microsoft MS-DOS (por ejemplo, Microsoft LAN Manager)
    - Clientes de Microsoft Windows para grupos de trabajo
    - Clientes de Microsoft Windows 95 sin el cliente DS instalado
    - Equipos basados en Microsoft Windows NT 4.0 sin SP3 o posterior instalado
    - Clientes CIFS de Novell Netware 6
    - Clientes SMB de SAMBA que no son compatibles con la firma SMB
8. Requisitos
  
  para reiniciar Reinicie el equipo o reinicie el servicio Servidor. Para ello, escribe los siguientes comandos en un símbolo del sistema. Presione Entrar después de escribir cada comando.
  
  net stop server
  net start server
Acceso de red: permitir la traducción de nombres o SID anónimos
1. Fondo
  
  El acceso de red: permitir la configuración de seguridad de traducción de nombres o SID anónimo determina si un usuario anónimo puede solicitar atributos de número de identificación de seguridad (SID) para otro usuario.
2. Configuración arriesgada
  
  Habilitar el acceso de red: permitir la configuración de traducción de nombres o SID anónimo es una configuración perjudicial.
3. Razones para habilitar esta configuración
  
  Si la opción Acceso de red: permitir la configuración de traducción de nombres o SID anónimo está deshabilitada, es posible que los sistemas operativos o aplicaciones anteriores no puedan comunicarse con dominios de Windows Server 2003. Por ejemplo, es posible que los siguientes sistemas operativos, servicios o aplicaciones no funcionen:
  - Servidores de servicios de acceso remoto basados en Windows NT 4.0
  - Microsoft SQL Server que se ejecutan en equipos basados en Windows NT 3.x o equipos basados en Windows NT 4.0
  - Servicio de acceso remoto que se ejecuta en equipos basados en Windows 2000 ubicados en dominios de Windows NT 3.x o dominios de Windows NT 4.0
  - SQL Server que se ejecuta en equipos basados en Windows 2000 ubicados en dominios de Windows NT 3.x o en dominios de Windows NT 4.0
  - Usuarios del dominio de recursos de Windows NT 4.0 que quieran conceder permisos para acceder a archivos, carpetas compartidas y objetos del Registro a cuentas de usuario de dominios de cuenta que contienen controladores de dominio de Windows Server 2003
4. Motivos para deshabilitar esta configuración
  
  Si esta configuración está habilitada, un usuario malintencionado podría usar el CONOCIDO SID para administradores para obtener el nombre real de la cuenta predefinida de administrador, incluso si se ha cambiado el nombre de la cuenta. Esa persona podría usar el nombre de cuenta para iniciar un ataque de adivinanza de contraseñas.
5. Nombre simbólico: N/D
6. Ruta de acceso del Registro: Ninguna. La ruta de acceso se especifica en el código de la interfaz de usuario.
7. Ejemplos de problemas
  
  de compatibilidad Windows NT 4.0: Los equipos en dominios de recursos de Windows NT 4.0 mostrarán el mensaje de error "Cuenta desconocida" en el Editor ACL si los recursos, incluidas las carpetas compartidas, los archivos compartidos y los objetos del Registro, están protegidos con entidades de seguridad que residen en dominios de cuenta que contienen controladores de dominio de Windows Server 2003.
Acceso de red: No permitir la enumeración anónima de cuentas SAM
1. Fondo
  - La configuración Acceso de red: No permitir enumeración anónima de cuentas SAM determina qué permisos adicionales se concederán para las conexiones anónimas al equipo. Windows permite a los usuarios anónimos realizar determinadas actividades, como enumerar los nombres de las cuentas del Administrador de cuentas de seguridad (SAM) y de los recursos compartidos de red de la estación de trabajo y del servidor. Por ejemplo, un administrador puede usarlo para conceder acceso a los usuarios de un dominio de confianza que no mantiene una confianza recíproca. Una vez que se realiza una sesión, un usuario anónimo puede tener el mismo acceso que se concede al grupo Todos en función de la configuración del acceso a la red: permitir que todos los permisos se apliquen a la configuración de usuarios anónimos o a la lista de control de acceso discrecional (DACL) del objeto.
    
    Normalmente, las conexiones anónimas las solicitan versiones anteriores de clientes (clientes de nivel inferior) durante la configuración de la sesión SMB. En estos casos, un seguimiento de red muestra que el Id. del proceso SMB (PID) es el redirector del cliente tal como 0xFEFF en Windows 2000 o 0xCAFE en Windows NT. RPC también puede intentar realizar conexiones anónimas.
  - Importante Esta configuración no afecta a los controladores de dominio. En los controladores de dominio, este comportamiento se controla mediante la presencia de "NT AUTHORITY\ANONYMOUS LOGON" en "Acceso compatible con Pre-Windows 2000".
  - En Windows 2000, una configuración similar denominada Restricciones adicionales para conexiones anónimas administra el valor del Registro RestrictAnonymous . La ubicación de este valor es la siguiente:
    
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA
2. Configuraciones arriesgadas
  
  Habilitar el acceso de red: no permitir la enumeración anónima de la configuración de cuentas SAM es una configuración perjudicial desde una perspectiva de compatibilidad. Deshabilitarla es una configuración perjudicial desde el punto de vista de la seguridad.
3. Razones para habilitar esta configuración
  
  Un usuario no autorizado podría enumerar de forma anónima los nombres de las cuentas y, a continuación, usar la información para intentar adivinar contraseñas o realizar ataques de ingeniería social. La ingeniería social es una jerga que implica engañar a la gente para que revele sus contraseñas o algún tipo de información de seguridad.
4. Motivos para deshabilitar esta configuración
  
  Si esta configuración está habilitada, es imposible establecer confianzas con dominios de Windows NT 4.0. Esta configuración también causa problemas con los clientes de nivel inferior (como clientes de Windows NT 3.51 y clientes de Windows 95) que intentan usar recursos en el servidor.
5. Nombre simbólico:
  
  RestrictAnonymousSAM
6. Ruta del Registro:
  
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RestrictAnonymousSAM (Reg_DWORD)
7. Ejemplos de problemas de compatibilidad
- SMS Network Discovery no podrá obtener información del sistema operativo y escribirá "Desconocido" en la propiedad OperatingSystemNameandVersion.
- Windows 95, Windows 98: los clientes de Windows 95 y los clientes de Windows 98 no podrán cambiar sus contraseñas.
- Windows NT 4.0: los equipos miembros basados en Windows NT 4.0 no se podrán autenticar.
- Windows 95, Windows 98: los equipos basados en Windows 95 y Windows 98 no podrán autenticarse mediante controladores de dominio de Microsoft.
- Windows 95, Windows 98: los usuarios de equipos basados en Windows 95 y Windows 98 no podrán cambiar las contraseñas de sus cuentas de usuario.
Acceso a la red: No permitir la enumeración anónima de cuentas y recursos compartidos SAM
1. Fondo
  - El acceso de red: no permitir la enumeración anónima de cuentas SAM y recursos compartidos configuración (también conocido como RestrictAnonymous) determina si se permite la enumeración anónima de cuentas y recursos compartidos del Administrador de cuentas de seguridad (SAM). Windows permite a los usuarios anónimos realizar determinadas actividades, como enumerar los nombres de cuentas de dominio (usuarios, equipos y grupos) y de recursos compartidos de red. Esto resulta cómodo, por ejemplo, cuando un administrador quiere conceder acceso a usuarios de un dominio de confianza que no mantiene una confianza recíproca. Si no desea permitir la enumeración anónima de cuentas SAM y de recursos compartidos, habilite esta configuración.
  - En Windows 2000, una configuración similar denominada Restricciones adicionales para conexiones anónimas administra el valor del Registro RestrictAnonymous . La ubicación de este valor es la siguiente:
    
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA
2. Configuración arriesgada
  
  Habilitar el acceso de red: no permitir la enumeración anónima de cuentas SAM y recursos compartidos es una configuración perjudicial.
3. Razones para habilitar esta configuración
  - Habilitar el acceso de red: no permitir la enumeración anónima de cuentas SAM y recursos compartidos impide la enumeración de cuentas y recursos compartidos de SAM por parte de usuarios y equipos que usan cuentas anónimas.
4. Motivos para deshabilitar esta configuración
  - Si esta configuración está habilitada, un usuario no autorizado podría enumerar nombres de cuenta de forma anónima y, a continuación, usar la información para intentar adivinar contraseñas o realizar ataques de ingeniería social. La ingeniería social es una jerga que implica engañar a la gente para que revele su contraseña o algún tipo de información de seguridad.
  - Si esta configuración está habilitada, será imposible establecer confianzas con dominios de Windows NT 4.0. Esta configuración también causará problemas con clientes de nivel inferior como Windows NT 3.51 y clientes de Windows 95 que intentan usar recursos en el servidor.
  - Será imposible conceder acceso a los usuarios de dominios de recursos porque los administradores del dominio de confianza no podrán enumerar listas de cuentas en el otro dominio. Los usuarios que tengan acceso anónimo a los servidores de archivos e impresión no podrán enumerar los recursos de red compartidos en esos servidores. Los usuarios deben autenticarse para poder ver las listas de impresoras y carpetas compartidas.
5. Nombre simbólico:
  
  Restrictanonymous
6. Ruta del Registro:
  
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RestrictAnonymous
7. Ejemplos de problemas de compatibilidad
  - Windows NT 4.0: Los usuarios no podrán cambiar sus contraseñas de estaciones de trabajo de Windows NT 4.0 cuando RestrictAnonymous esté habilitado en los controladores de dominio del dominio de los usuarios.
  - Windows NT 4.0: Se producirá un error al agregar usuarios o grupos globales de dominios de Confianza de Windows 2000 a grupos locales de Windows NT 4.0 en el Administrador de usuarios y aparecerá el siguiente mensaje de error:
    
    Actualmente no hay servidores de inicio de sesión disponibles para atender la solicitud de inicio de sesión.
  - Windows NT 4.0: los equipos basados en Windows NT 4.0 no podrán unirse a dominios durante la instalación ni mediante la interfaz de usuario para unirse a un dominio.
  - Windows NT 4.0: Se producirá un error al establecer una confianza de nivel inferior con los dominios de recursos de Windows NT 4.0. Aparecerá el siguiente mensaje de error cuando RestrictAnonymous esté habilitado en el dominio de confianza:
    
    No se pudo encontrar el controlador de dominio para este dominio.
  - Windows NT 4.0: Los usuarios que inicien sesión en equipos de Terminal Server basados en Windows NT 4.0 se asignarán al directorio principal predeterminado en lugar del directorio principal definido en el Administrador de usuarios para dominios.
  - Windows NT 4.0: Los controladores de dominio de copia de seguridad (BDCs) de Windows NT 4.0 no podrán iniciar el servicio net logon, obtener una lista de exploradores de copia de seguridad ni sincronizar la base de datos SAM de Windows 2000 o de controladores de dominio de Windows Server 2003 en el mismo dominio.
  - Windows 2000: los equipos miembros basados en Windows 2000 en dominios de Windows NT 4.0 no podrán ver impresoras en dominios externos si la configuración No hay acceso sin permisos explícitamente anónimos está habilitada en la directiva de seguridad local del equipo cliente.
  - Windows 2000: los usuarios del dominio de Windows 2000 no podrán agregar impresoras de red desde Active Directory; sin embargo, podrán agregar impresoras después de seleccionarlas en la vista de árbol.
  - Windows 2000: En equipos basados en Windows 2000, el Editor ACL no podrá agregar usuarios ni grupos globales de dominios de Confianza de Windows NT 4.0.
  - ADMT versión 2: Se producirá un error en la migración de contraseñas para las cuentas de usuario que se migran entre bosques con la versión 2 de la Herramienta de migración de Active Directory (ADMT).
    
    Para obtener más información, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
    
    322981 Cómo solucionar problemas de migración de contraseñas entre bosques con ADMTv2
  - Clientes de Outlook: la lista global de direcciones aparecerá vacía para los clientes de Microsoft Exchange Outlook.
  - SMS: La detección de redes de Microsoft Systems Management Server (SMS) no podrá obtener la información del sistema operativo. Por lo tanto, escribirá "Desconocido" en la propiedad OperatingSystemNameandVersion de la propiedad DDR de SMS del registro de datos de detección (DDR).
  - SMS: al usar el Asistente para usuarios de administrador de SMS para buscar usuarios y grupos, no se mostrará ningún usuario o grupo. Además, los clientes avanzados no pueden comunicarse con el punto de administración. Se requiere acceso anónimo en el punto de administración.
  - SMS: Si usa la característica de detección de redes en SMS 2.0 y en la instalación de cliente remoto con la opción de detección de red de topología, cliente y cliente activada, es posible que se detecten equipos, pero que no estén instalados.

Seguridad de red: nivel de autenticación de Lan Manager

Fondo

Autenticación LAN Manager (LM) es el protocolo que se usa para autenticar clientes Windows para operaciones de red, incluidas las combinaciones de dominios, el acceso a recursos de red y la autenticación de usuarios o equipos. El nivel de autenticación LM determina qué protocolo de autenticación de desafío/respuesta se negocia entre el cliente y los equipos del servidor. En concreto, el nivel de autenticación LM determina qué protocolos de autenticación intentará negociar el cliente o que aceptará el servidor. El valor que se establece para LmCompatibilityLevel determina qué protocolo de autenticación de desafío/respuesta se usa para los inicios de sesión de red. Este valor afecta al nivel de protocolo de autenticación que usan los clientes, al nivel de seguridad de sesión negociado y al nivel de autenticación aceptado por los servidores.

Entre las posibles opciones de configuración se incluyen las siguientes:

Valor	Opción	Descripción
0	Enviar respuestas de LM & NTLM	Los clientes usan autenticación LM y NTLM y nunca usan seguridad de sesión NTLMv2. Los controladores de dominio aceptan autenticación LM, NTLM y NTLMv2.
1	Enviar LM & NTLM: usar seguridad de sesión NTLMv2 si se negocia	Los clientes usan autenticación LM y NTLM, y usan seguridad de sesión NTLMv2 si el servidor lo admite. Los controladores de dominio aceptan autenticación LM, NTLM y NTLMv2.
2	Enviar solo respuesta NTLM	Los clientes usan solo autenticación NTLM y usan seguridad de sesión NTLMv2 si el servidor lo admite. Los controladores de dominio aceptan autenticación LM, NTLM y NTLMv2.
3	Enviar solo respuesta NTLMv2	Los clientes utilizan autenticación NTLMv2 solamente y utilizan seguridad de sesión NTLMv2 si el servidor lo admite. Los controladores de dominio aceptan autenticación LM, NTLM y NTLMv2.
4	Enviar solo respuesta NTLMv2/rechazar LM	Los clientes utilizan autenticación NTLMv2 solamente y utilizan seguridad de sesión NTLMv2 si el servidor lo admite. Los controladores de dominio rechazan LM y aceptan solo la autenticación NTLM y NTLMv2.
5	Enviar solo respuesta a NTLMv2/rechazar LM & NTLM	Los clientes utilizan autenticación NTLMv2 solamente y utilizan seguridad de sesión NTLMv2 si el servidor lo admite. Los controladores de dominio rechazan LM y NTLM y solo aceptan la autenticación NTLMv2.

Nota En Windows 95, Windows 98 y Windows 98 Second Edition, el cliente de servicios de directorio usa la firma SMB cuando se autentica con servidores de Windows Server 2003 mediante autenticación NTLM. Sin embargo, estos clientes no usan la firma SMB cuando se autentican con estos servidores mediante la autenticación NTLMv2. Además, los servidores de Windows 2000 no responden a las solicitudes de firma smb de estos clientes.

Comprobar el nivel de autenticación LM: Debe cambiar la directiva en el servidor para permitir NTLM o debe configurar el equipo cliente para que admita NTLMv2.

Si la directiva está establecida en (5) Enviar solo respuesta NTLMv2\rechazar LM & NTLM en el equipo de destino al que desea conectarse, debe bajar la configuración en ese equipo o establecer la seguridad en la misma configuración que se encuentra en el equipo de origen desde el que se está conectando.

Busque la ubicación correcta donde puede cambiar el nivel de autenticación del administrador de LAN para establecer el cliente y el servidor en el mismo nivel. Después de encontrar la directiva que establece el nivel de autenticación del administrador de LAN, si desea conectarse a equipos que ejecutan versiones anteriores de Windows y desde ellos, baje el valor a al menos (1) Enviar LM & NTLM: use seguridad de sesión de NTLM versión 2 si se negocia. Un efecto de la configuración incompatible es que si el servidor requiere NTLMv2 (valor 5), pero el cliente está configurado para usar LM y NTLMv1 solo (valor 0), el usuario que prueba la autenticación experimenta un error de inicio de sesión que tiene una contraseña incorrecta y que incrementa el recuento de contraseñas incorrectas. Si se configura el bloqueo de la cuenta, es posible que el usuario se bloquee con el tiempo.

Por ejemplo, puede que tenga que buscar en el controlador de dominio o puede que tenga que examinar las directivas del controlador de dominio.

Buscar en el controlador

de dominio Nota Es posible que tenga que repetir el siguiente procedimiento en todos los controladores de dominio.

Haga clic en Inicio, seleccione Programas y, a continuación, haga clic en Herramientas administrativas.
En Configuración de seguridad local, expande Directivas locales.
Haga clic en Opciones de seguridad.
Haga doble clic en Seguridad de red: nivel de autenticación del administrador LAN y, a continuación, haga clic en un valor de la lista.

Si la configuración efectiva y la configuración local son iguales, la directiva se ha cambiado en este nivel. Si la configuración es diferente, debe comprobar la directiva del controlador de dominio para determinar si la configuración de nivel de autenticación Network Security: LAN manager se define allí. Si no se define allí, examine las directivas del controlador de dominio.

Examinar las directivas del controlador de dominio

Haga clic en Inicio, seleccione Programas y, a continuación, haga clic en Herramientas administrativas.
En la directiva de seguridad del controlador de dominio , expanda Configuración de seguridad y, a continuación, expanda Directivas locales.
Haga clic en Opciones de seguridad.
Haga doble clic en Seguridad de red: nivel de autenticación del administrador LAN y, a continuación, haga clic en un valor de la lista.

Nota

Es posible que también tenga que comprobar las directivas vinculadas en el nivel de sitio, el nivel de dominio o el nivel de la unidad organizativa (OU) para determinar dónde debe configurar el nivel de autenticación del administrador de LAN.
Si implementa una configuración de directiva de grupo como directiva de dominio predeterminada, la directiva se aplica a todos los equipos del dominio.
Si implementa una configuración de directiva de grupo como directiva de controlador de dominio predeterminada, la directiva se aplica solo a los servidores de la unidad organizativa del controlador de dominio.
Es una buena idea establecer el nivel de autenticación de administrador LAN en la entidad más baja del ámbito necesario en la jerarquía de la aplicación de directivas.

Windows Server 2003 tiene una nueva configuración predeterminada para usar solo NTLMv2. De forma predeterminada, los controladores de dominio basados en Windows Server 2003 y Windows 2000 Server SP3 han habilitado la directiva "Microsoft network server: Digitally sign communications (always)". Esta configuración requiere que el servidor SMB realice la firma de paquetes SMB. Los cambios realizados en Windows Server 2003 se realizaron porque los controladores de dominio, los servidores de archivos, los servidores de infraestructura de red y los servidores web de cualquier organización requieren diferentes configuraciones para maximizar su seguridad.

Si desea implementar la autenticación NTLMv2 en su red, debe asegurarse de que todos los equipos del dominio están configurados para usar este nivel de autenticación. Si aplica extensiones de cliente de Active Directory para Windows 95 o Windows 98 y Windows NT 4.0, las extensiones de cliente usan las características de autenticación mejoradas disponibles en NTLMv2. Como los equipos cliente que ejecutan cualquiera de los siguientes sistemas operativos no se ven afectados por los objetos de directiva de grupo de Windows 2000, es posible que tenga que configurar manualmente estos clientes:

Microsoft Windows NT 4.0
Microsoft Windows Millennium Edition
Microsoft Windows 98
Microsoft Windows 95

Nota Si habilita la seguridad de red: no almacene el valor hash del administrador de LAN en la siguiente directiva de cambio de contraseña ni establezca la clave del Registro NoLMHash , los clientes basados en Windows 95 y windows 98 que no tengan instalado el cliente de servicios de directorio no podrán iniciar sesión en el dominio después de un cambio de contraseña.

Muchos servidores CIFS de terceros, como Novell Netware 6, no conocen NTLMv2 y utilizan solo NTLM. Por lo tanto, los niveles mayores que 2 no permiten la conectividad. También hay clientes SMB de terceros que no usan seguridad de sesión extendida. En estos casos, el LmCompatiblityLevel del servidor de recursos no se tiene en cuenta. A continuación, el servidor empaquete esta solicitud heredada y la envía al controlador de dominio de usuario. A continuación, la configuración del controlador de dominio decide qué hashes se utilizan para comprobar la solicitud y si cumplen los requisitos de seguridad del controlador de dominio.

299656 Cómo evitar que Windows almacene un hash de administrador de LAN de la contraseña en Active Directory y bases de datos SAM locales

2701704El evento de auditoría muestra el paquete de autenticación como NTLMv1 en lugar de NTLMv2 Para obtener más información sobre los niveles de autenticación de LM, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:

239869 Cómo habilitar la autenticación NTLM 2

Configuraciones arriesgadas

A continuación se muestran las opciones de configuración perjudiciales:
- Ajustes no laborables que envían contraseñas en texto claro y que deniegan la negociación NTLMv2
- Configuración restrictiva que impide que clientes o controladores de dominio incompatibles puedan negociar un protocolo de autenticación común
- Requerir autenticación NTLMv2 en equipos miembros y controladores de dominio que ejecutan versiones de Windows NT 4.0 anteriores a Service Pack 4 (SP4)
- Requiere autenticación NTLMv2 en clientes de Windows 95 o en clientes de Windows 98 que no tengan instalado el cliente de servicios de directorio de Windows.
- Si hace clic para activar la casilla Requerir seguridad de sesión NTLMv2 en la Consola de administración de Microsoft directiva de grupo complemento Editor en un equipo basado en Windows Server 2003 o Windows 2000 Service Pack 3, y baja el nivel de autenticación del administrador de LAN a 0, las dos configuraciones entran en conflicto y es posible que reciba el siguiente mensaje de error en el archivo Secpol.msc o en el archivo GPEdit.msc:
  
  Windows no puede abrir la base de datos de directivas local. Se produjo un error desconocido al intentar abrir la base de datos.
  
  Para obtener más información sobre la Herramienta de análisis y configuración de seguridad, consulte los archivos de ayuda de Windows 2000 o Windows Server 2003.
Razones para modificar esta configuración
- Desea aumentar el protocolo de autenticación común más bajo compatible con los clientes y controladores de dominio de su organización.
- Cuando la autenticación segura sea un requisito empresarial, desea no permitir la negociación de los protocolos LM y NTLM.
Motivos para deshabilitar esta configuración

Los requisitos de autenticación de cliente o servidor, o ambos, se han aumentado hasta el punto en que no puede producirse la autenticación a través de un protocolo común.
Nombre simbólico:

Lmcompatibilitylevel
Ruta del Registro:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel
Ejemplos de problemas de compatibilidad
- Windows Server 2003: de forma predeterminada, está habilitada la opción enviar respuestas NTLM de Windows Server 2003 NTLMv2. Por lo tanto, Windows Server 2003 recibe el mensaje de error "Acceso denegado" después de la instalación inicial cuando intenta conectarse a un clúster basado en Windows NT 4.0 o a servidores basados en LanManager V2.1, como OS/2 Lanserver. Este problema también se produce si intenta conectarse desde un cliente de una versión anterior a un servidor basado en Windows Server 2003.
- Instala el paquete acumulativo de actualizaciones de seguridad 1 (SRP1) de Windows 2000. SRP1 fuerza NTLM versión 2 (NTLMv2). Este paquete acumulativo se publicó después del lanzamiento de Windows 2000 Service Pack 2 (SP2).
- Windows 7 y Windows Server 2008 R2: Muchos servidores CIFS de terceros, como los servidores Samba basados en Novell Netware 6 o Linux, no conocen NTLMv2 y solo usan NTLM. Por lo tanto, los niveles mayores que "2" no permiten la conectividad. Ahora, en esta versión del sistema operativo, el valor predeterminado de LmCompatibilityLevel se cambió a "3". Por lo tanto, al actualizar Windows, estos filers de terceros pueden dejar de funcionar.
- Es posible que se soliciten credenciales a los clientes de Microsoft Outlook aunque ya hayan iniciado sesión en el dominio. Cuando los usuarios suministran sus credenciales, reciben el siguiente mensaje de error: Windows 7 y Windows Server 2008 R2
  
  Las credenciales de inicio de sesión suministradas eran incorrectas. Asegúrese de que el nombre de usuario y el dominio son correctos y, a continuación, vuelva a escribir la contraseña.
  
  Al iniciar Outlook, es posible que se le soliciten sus credenciales incluso si la configuración de Seguridad de red de inicio de sesión está establecida en Paso a través o en Autenticación de contraseña. Después de escribir las credenciales correctas, es posible que reciba el siguiente mensaje de error:
  
  Las credenciales de inicio de sesión suministradas eran incorrectas.
  
  Un seguimiento de monitor de red puede mostrar que el catálogo global emitió un error de llamada a procedimiento remoto (RPC) con un estado de 0x5. Un estado de 0x5 significa "Acceso denegado".
- Windows 2000: una captura de monitor de red puede mostrar los siguientes errores en la sesión de NetBIOS sobre bloque de mensajes de servidor TCP/IP (NetBT):
  
  Error de dos del directorio de búsqueda de R SMB, (5) ACCESS_DENIED (109) STATUS_LOGON_FAILURE (91) identificador de usuario no válido
- Windows 2000: Si un dominio de Windows 2000 con NTLMv2 nivel 2 o posterior es de confianza por un dominio de Windows NT 4.0, los equipos miembros basados en Windows 2000 en el dominio de recursos pueden experimentar errores de autenticación.
- Windows 2000 y Windows XP: de forma predeterminada, Windows 2000 y Windows XP establecen la opción Directiva de seguridad local a nivel de autenticación de LAN Manager en 0. Una configuración de 0 significa "Enviar respuestas DE LM y NTLM".
  
  Nota Los clústeres basados en Windows NT 4.0 deben usar LM para la administración.
- Windows 2000: la agrupación en clústeres de Windows 2000 no autentica un nodo de unión si ambos nodos forman parte de un dominio de Windows NT 4.0 Service Pack 6a (SP6a).
- La Herramienta de bloqueo de IIS (HiSecWeb) establece el valor LMCompatibilityLevel en 5 y el valor RestrictAnonymous en 2.
- Servicios para Macintosh
  
  Módulo de autenticación de usuario (UAM): Microsoft UAM (Módulo de autenticación de usuario) proporciona un método para cifrar las contraseñas que se usan para iniciar sesión en servidores AFP (Protocolo de archivado de AppleTalk) de Windows. El Módulo de autenticación de usuario (UAM) de Apple solo proporciona cifrado mínimo o ningún cifrado. Por lo tanto, su contraseña podría ser interceptada fácilmente en la LAN o en Internet. Aunque el UAM no es necesario, sí proporciona autenticación cifrada a los servidores de Windows 2000 que ejecutan Servicios para Macintosh. Esta versión incluye compatibilidad con NTLMv2 autenticación cifrada de 128 bits y una versión compatible con MacOS X 10.1.
  
  De forma predeterminada, los Servicios de Windows Server 2003 para el servidor Macintosh solo permiten la autenticación de Microsoft.
- Windows Server 2008, Windows Server 2003, Windows XP y Windows 2000: Si configura el valor LMCompatibilityLevel como 0 o 1 y configura el valor NoLMHash como 1, es posible que se deniegue el acceso a las aplicaciones y los componentes a través de NTLM. Este problema se produce porque el equipo está configurado para habilitar LM, pero no para usar contraseñas almacenadas en LM.
  
  Si configura el valor de NoLMHash como 1, debe configurar el valor LMCompatibilityLevel para que sea 2 o superior.

Seguridad de red: Requisitos de firma de cliente LDAP
1. Fondo
  
  La configuración de seguridad de red: Los requisitos de firma de cliente LDAP determinan el nivel de firma de datos que se solicita en nombre de los clientes que emiten solicitudes DE ENLACE DE PROTOCOLO ligero de acceso a directorios (LDAP), como se indica a continuación:
  - Ninguno: la solicitud de enlace LDAP se emite con las opciones especificadas por el autor de la llamada.
  - Firma de negociación: si no se ha iniciado la seguridad de capa de sockets seguros/capa de transporte (SSL/TLS), la solicitud de enlace LDAP se inicia con la opción de firma de datos LDAP establecida además de las opciones especificadas por el autor de la llamada. Si se ha iniciado SSL/TLS, la solicitud de ENLACE LDAP se inicia con las opciones especificadas por el autor de la llamada.
  - Requerir firma: esto es lo mismo que la firma de Negotiate. Sin embargo, si la respuesta de nivel intermedio saslBindInProgress del servidor LDAP no indica que la firma de tráfico LDAP sea necesaria, al autor de la llamada se le indica que la solicitud de comando LDAP BIND falló.
2. Configuración arriesgada
  
  Habilitar la seguridad de red: la configuración de requisitos de firma de cliente LDAP es una configuración perjudicial. Si configura el servidor para que requiera firmas LDAP, también debe configurar la firma LDAP en el cliente. Si no configura el cliente para que use firmas LDAP, se evitará la comunicación con el servidor. Esto provoca errores en la autenticación del usuario, la configuración de directiva de grupo, los scripts de inicio de sesión y otras características.
3. Razones para modificar esta configuración
  
  El tráfico de red sin firmar es susceptible a ataques de tipo man-in-the-middle donde un intruso captura paquetes entre el cliente y los servidores, los modifica y, a continuación, los reenvía al servidor. Cuando esto ocurre en un servidor LDAP, un atacante podría hacer que un servidor responda basado en consultas falsas del cliente LDAP. Puede reducir este riesgo en una red corporativa implementando fuertes medidas de seguridad física para ayudar a proteger la infraestructura de red. Además, puede ayudar a evitar todo tipo de ataques de tipo man-in-the-middle exigiendo firmas digitales en todos los paquetes de red mediante encabezados de autenticación IPSec.
4. Nombre simbólico:
  
  LDAPClientIntegrity
5. Ruta del Registro:
  
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LDAP\LDAPClientIntegrity
Registro de eventos: tamaño máximo del registro de seguridad
1. Fondo
  
  El registro de eventos: el valor de seguridad Tamaño máximo del registro de seguridad especifica el tamaño máximo del registro de eventos de seguridad. Este registro tiene un tamaño máximo de 4 GB. Para localizar esta configuración, expande
  Configuración de Windows y, a continuación, expande Configuración de seguridad.
2. Configuraciones arriesgadas
  
  A continuación se muestran las opciones de configuración perjudiciales:
  - Restringir el tamaño del registro de seguridad y el método de retención de registros de seguridad cuando la opción Auditoría: Cierre el sistema inmediatamente si no se puede registrar la configuración de auditorías de seguridad. Consulta la sección "Auditoría: Apagar el sistema inmediatamente si no se pueden registrar auditorías de seguridad" de este artículo para obtener más información.
  - Restringir el tamaño del registro de seguridad para que se sobrescriban los eventos de seguridad de interés.
3. Razones para aumentar esta configuración
  
  Los requisitos empresariales y de seguridad pueden dictar que aumente el tamaño del registro de seguridad para administrar detalles adicionales del registro de seguridad o para conservar registros de seguridad durante un período de tiempo más largo.
4. Las razones para reducir esta configuración
  
  Visor de eventos los registros son archivos asignados a la memoria. El tamaño máximo de un registro de eventos está limitado por la cantidad de memoria física del equipo local y por la memoria virtual disponible para el proceso del registro de eventos. Aumentar el tamaño del registro más allá de la cantidad de memoria virtual disponible para Visor de eventos no aumenta el número de entradas de registro que se mantienen.
5. Ejemplos de problemas
  
  de compatibilidad Windows 2000: los equipos que ejecutan versiones de Windows 2000 anteriores a Service Pack 4 (SP4) pueden dejar de registrar eventos en el registro de eventos antes de alcanzar el tamaño especificado en la configuración Tamaño máximo del registro en Visor de eventos si la opción No sobrescribir eventos (borrar registro manualmente) está activada.
Registro de eventos: Conservar el registro de seguridad
1. Fondo
  
  El registro de eventos: Conservar la configuración de seguridad del registro de seguridad determina el método de "ajuste" para el registro de seguridad. Para localizar esta configuración, expande Configuración de Windows y, a continuación, expande Configuración de seguridad.
2. Configuraciones arriesgadas
  
  A continuación se muestran las opciones de configuración perjudiciales:
  - No se pueden conservar todos los eventos de seguridad registrados antes de que se sobrescriban
  - Configuración de la configuración Tamaño de registro de seguridad máximo demasiado pequeño para que los eventos de seguridad se sobrescriban
  - Restringir el tamaño del registro de seguridad y el método de retención mientras está habilitada la opción Auditoría: Apagar el sistema inmediatamente si no se puede registrar la configuración de seguridad de auditorías de seguridad
3. Razones para habilitar esta configuración
  
  Habilite esta configuración solo si selecciona el método de retención Sobrescribir eventos por días . Si usa un sistema de correlación de eventos que sondea para eventos, asegúrese de que el número de días sea al menos tres veces la frecuencia del sondeo. Haga esto para permitir los ciclos de sondeo con errores.
Acceso de red: Permitir que todos los permisos se apliquen a usuarios anónimos
1. Fondo
  
  De forma predeterminada, la opción Acceso de red: Permitir que todos los permisos se apliquen a usuarios anónimos se establece en No definido en Windows Server 2003. De forma predeterminada, Windows Server 2003 no incluye el token de acceso anónimo en el grupo Todos.
2. Ejemplo de problemas
  
  de compatibilidad El siguiente valor de
  
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\everyoneincludesanonymous [REG_DWORD]=0x0 rompe la creación de confianza entre Windows Server 2003 y Windows NT 4.0, cuando el dominio de Windows Server 2003 es el dominio de la cuenta y el dominio de Windows NT 4.0 es el dominio de recursos. Esto significa que el dominio de la cuenta es de confianza en Windows NT 4.0 y que el dominio de recursos confía en el lado de Windows Server 2003. Este comportamiento se produce porque el proceso para iniciar la confianza después de la conexión anónima inicial es ACL'd con el token Todos que incluye el SID anónimo en Windows NT 4.0.
3. Razones para modificar esta configuración
  
  El valor debe establecerse en 0x1 o establecerlo mediante un GPO en la unidad organizativa del controlador de dominio para que sea: Acceso de red: permitir que todos los usuarios se apliquen a usuarios anónimos: habilitado para que las creaciones de confianza sean posibles.
  
  Nota La mayoría de las demás opciones de configuración de seguridad suban de valor en lugar de bajar a 0x0 en su estado más seguro. Una práctica más segura sería cambiar el registro en el emulador de controlador de dominio principal en lugar de en todos los controladores de dominio. Si el rol de emulador de controlador de dominio principal se mueve por cualquier motivo, el registro debe actualizarse en el nuevo servidor.
  
  Es necesario reiniciar una vez establecido este valor.
4. Ruta de acceso del Registro
  
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\everyoneincludesanonymous
Autenticación NTLMv2
1. Seguridad
  
  de sesión La seguridad de sesión determina los estándares de seguridad mínimos para las sesiones de cliente y de servidor. Es una buena idea comprobar la siguiente configuración de directiva de seguridad en el complemento Editor directiva de grupo consola de administración de Microsoft:
  - Configuración del equipo\Configuración de Windows\Configuración de seguridad\Directivas locales\Opciones de seguridad
  - Seguridad de red: seguridad de sesión mínima para servidores basados en NTLM SSP (incluidos servidores RPC seguros)
  - Seguridad de red: seguridad de sesión mínima para clientes basados en NTLM SSP (incluidos los rpc seguros)
  Las opciones para esta configuración son las siguientes:
  - Requerir integridad de mensaje
  - Requerir confidencialidad del mensaje
  - Requerir seguridad de sesión NTLM versión 2
  - Requerir cifrado de 128 bits
  La configuración predeterminada anterior a Windows 7 es Sin requisitos. A partir de Windows 7, el valor predeterminado ha cambiado a Requerir cifrado de 128 bits para mejorar la seguridad. Con este valor predeterminado, los dispositivos heredados que no admiten el cifrado de 128 bits no se podrán conectar.
  
  Estas directivas determinan los estándares de seguridad mínimos para una sesión de comunicaciones de aplicación a aplicación en un servidor para un cliente.
  
  Tenga en cuenta que, aunque se describen como configuraciones válidas, las marcas para requerir integridad y confidencialidad del mensaje no se usan cuando se determina la seguridad de la sesión NTLM.
  
  Históricamente, Windows NT ha admitido las dos siguientes variantes de autenticación de desafío/respuesta para los inicios de sesión de red:
  - Reto/respuesta de LM
  - Respuesta/desafío de NTLM versión 1
  LM permite la interoperabilidad con la base instalada de clientes y servidores. NTLM proporciona seguridad mejorada para las conexiones entre clientes y servidores.
  
  Las claves del Registro correspondientes son las siguientes:
  
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\"NtlmMinServerSec"
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\"NtlmMinClientSec"
2. Configuraciones arriesgadas
  
  Esta configuración controla cómo se controlarán las sesiones de red protegidas con NTLM. Esto afecta a las sesiones basadas en RPC autenticadas con NTLM, por ejemplo. Existen los siguientes riesgos:
  - El uso de métodos de autenticación más antiguos que NTLMv2 hace que la comunicación sea más fácil de atacar debido a los métodos de hash más simples utilizados.
  - El uso de claves de cifrado inferiores a 128 bits permite a los atacantes romper la comunicación mediante ataques con fuerza bruta.

Sincronización de tiempo

Error en la sincronización de tiempo. El tiempo está desactivado durante más de 30 minutos en un equipo afectado. Asegúrese de que el reloj del equipo cliente está sincronizado con el reloj del controlador de dominio.

Solución alternativa para la firma de SMB

Le recomendamos que instale Service Pack 6a (SP6a) en clientes de Windows NT 4.0 que interoperan en un dominio basado en Windows Server 2003. Los clientes basados en La segunda edición de Windows 98, los clientes basados en Windows 98 y los clientes basados en Windows 95 deben ejecutar el cliente de servicios de directorio para realizar NTLMv2. Si los clientes basados en Windows NT 4.0 no tienen Windows NT 4.0 SP6 instalado o si los clientes basados en Windows 95, los clientes basados en Windows 98 y los clientes basados en Windows 98SE no tienen instalado el cliente de servicios de directorio, deshabilite la firma SMB en la configuración de directiva predeterminada del controlador de dominio en la unidad organizativa del controlador de dominio y vincule esta directiva a todas las OU que hospedan controladores de dominio.

El cliente de servicios de directorio para Windows 98 Second Edition, Windows 98 y Windows 95 realizará la firma SMB con servidores de Windows 2003 en autenticación NTLM, pero no en autenticación NTLMv2. Además, los servidores de Windows 2000 no responderán a las solicitudes de firma smb de estos clientes.

Aunque no lo recomendamos, puedes evitar que se requiera la firma smb en todos los controladores de dominio que ejecutan Windows Server 2003 en un dominio. Para configurar esta configuración de seguridad, siga estos pasos:

Abra la directiva predeterminada del controlador de dominio.
Abre la carpeta Configuración del equipo\Configuración de Windows\Configuración de seguridad\Directivas locales\Opciones de seguridad.
Busque y haga clic en el servidor de red de Microsoft: configuración de directiva de comunicaciones de firma digital (siempre) y, a continuación, haga clic en Deshabilitado.

Importante Esta sección, método o tarea contiene pasos que le indican cómo modificar el Registro. Sin embargo, pueden producirse problemas graves si modifica incorrectamente el Registro. Por lo tanto, asegúrese de seguir estos pasos cuidadosamente. Para mayor protección, realice una copia de seguridad del Registro antes de modificarlo. Después, puede restaurar el Registro si se produce un problema. Para obtener más información sobre cómo realizar copias de seguridad y restaurar el Registro, haga clic en el siguiente número de artículo para verlo en Microsoft Knowledge Base:

322756 Cómo hacer una copia de seguridad y restaurar el Registro en Windows Alternativamente, desactiva el inicio de sesión SMB en el servidor modificando el Registro. Para ello, siga estos pasos:

Haga clic en Inicio, haga clic en Ejecutar, escriba regedit y, a continuación, haga clic en Aceptar.
Busque la siguiente subclave y haga clic en ella:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Lanmanserver\Parameters
Haga clic en la entrada enablesecuritysignature .
En el menú Editar , haga clic en Modificar.
En el cuadro Datos del valor, escriba 0 y, a continuación, haga clic en Aceptar.
Salga del Editor del Registro.
Reinicie el equipo o detenga y reinicie el servicio servidor. Para ello, escriba los siguientes comandos en un símbolo del sistema y, después, presione Entrar después de escribir cada comando:
net stop server
net start server

Nota La clave correspondiente del equipo cliente está en la siguiente subclave del Registro:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lanmanworkstation\Parameters A continuación se enumeran los números de código de error traducidos a códigos de estado y a los mensajes de error textuales que se mencionan anteriormente:

error 5

ERROR_ACCESS_DENIED Se denegará el acceso.

error 1326

ERROR_LOGON_FAILURE Error de inicio de sesión: nombre de usuario desconocido o contraseña incorrecta.

error 1788

ERROR_TRUSTED_DOMAIN_FAILURE Error en la relación de confianza entre el dominio principal y el dominio de confianza.

error 1789

ERROR_TRUSTED_RELATIONSHIP_FAILURE Error en la relación de confianza entre esta estación de trabajo y el dominio principal.

Para obtener más información, haga clic en los números de artículo siguientes para verlos en Microsoft Knowledge Base:

324802 Cómo configurar directivas de grupo para establecer la seguridad de los servicios del sistema en Windows Server 2003

816585 Cómo aplicar plantillas de seguridad predefinidas en Windows Server 2003