Si cambia la configuración de seguridad y las asignaciones de derechos de usuario, puede experimentar problemas en sus programas, sus servicios o sus clientes.

Se aplica a: Microsoft Windows Server 2003 Standard Edition (32-bit x86)Microsoft Windows Server 2003 Datacenter Edition (32-bit x86)Microsoft Windows Server 2003 Enterprise Edition (32-bit x86)

Resumen


Configuración de seguridad y las asignaciones de derechos de usuario pueden cambiarse en directivas locales y directivas de grupo para ayudar a reforzar la seguridad de los controladores de dominio y equipos miembro. Sin embargo, la desventaja de aumentar la seguridad es la introducción de incompatibilidades con clientes, servicios y programas.

Este artículo describe las incompatibilidades que pueden producirse en los equipos cliente que ejecutan Windows XP o una versión anterior de Windows, cuando cambia la configuración de seguridad específicos y las asignaciones de derechos de usuario en un dominio de Windows Server 2003 o un anterior Windows Dominio de servidor.

Para obtener información acerca de directiva de grupo para Windows 7, Windows Server 2008 R2 y Windows Server 2008, consulte los artículos siguientes: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 configuradas, utilice la herramienta Editor de objetos de directiva de grupo para cambiar la configuración de seguridad. Cuando se utiliza el Editor de objetos de directiva de grupo, las asignaciones de derechos de usuario se han mejorado 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 cuando se cambia una configuración de seguridad o una asignación de derechos de usuario a una opción que ofrece menos compatibilidad y es más restrictivo. Si cambia directamente la misma seguridad usuario o configuración de asignación de derechos mediante el registro o mediante plantillas de seguridad, el efecto es lo mismo que cambiar la configuración en el Editor de objetos de directiva de grupo. Sin embargo, no aparece el cuadro de diálogo que contiene el vínculo a este artículo.

Este artículo contiene ejemplos de clientes, programas y operaciones que se ven afectadas por la configuración de seguridad o las asignaciones de derechos de usuario. Sin embargo, los ejemplos no tienen autoridad para todos los sistemas operativos de Microsoft, para todos los sistemas operativos de otros fabricantes o para todas las versiones de programa que se ven afectadas. No todas las configuraciones de seguridad y las asignaciones de derechos de usuario 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 de sistema operativo de cliente y servidor, programas cliente y servidor, versiones de service pack, revisiones, cambios de esquema, grupos de seguridad, pertenencia a grupos, permisos sobre objetos en el sistema de archivos, carpetas compartidas, el registro, el directorio de Active Directory tipo y ubicación del recuento servicio, local y la configuración de directiva de grupo y objeto
  • Las tareas administrativas que se realizan, herramientas administrativas que se utilizan y los sistemas operativos que se utilizan para realizar tareas administrativas
  • Operaciones que se realizan, como la siguiente:
    • Autenticación de inicio de sesión de usuario y de equipo
    • Los usuarios, equipos y administradores de restablecimiento de contraseñas
    • Exploración
    • Establecer permisos para el sistema de archivos, de carpetas compartidas, el registro y los recursos de Active Directory mediante el Editor de ACL en todos los sistemas operativos de cliente en todos los dominios de cuentas o recursos de todos los sistemas operativos de cliente de todas las cuentas o recursos dominios
    • Impresión desde cuentas administrativas y no administrativas

Windows Server 2003 SP1

Advertencias en Gpedit.msc

Para ayudar a que los clientes sepan que está editando un derecho de usuario u opción de seguridad que podría tener negativamente afectan a su red, se han agregado dos mecanismos de advertencia a gpedit.msc. Cuando los administradores editan un derecho de usuario que puede afectar a toda la empresa, verán un nuevo icono que se asemeja a un inicio de sesión de rendimiento. También recibirá un mensaje de advertencia que tiene un vínculo al artículo 823659 de Microsoft Knowledge Base. El texto de este mensaje es el siguiente:
Si modifica esta configuración puede afectar a la compatibilidad con clientes, servicios y aplicaciones. Para obtener más información, consulte < usuario derecha u opción de seguridad está modificando > (Q823659)
Si se le ha dirigido a este artículo de Knowledge Base desde un vínculo en Gpedit.msc, asegúrese de que lee y entiende la explicación proporcionada y el posible efecto de este cambio. A continuación enumeran los derechos de usuario que contienen el texto de advertencia:
  • Tener acceso a este equipo desde la red
  • Iniciar sesión localmente
  • Omitir comprobación de recorrido
  • Habilitar equipos y usuarios para la delegación de confianza
A continuación enumeran las opciones de seguridad que contienen la advertencia y un mensaje emergente:
  • Miembro de dominio: Cifrar o firmar datos de canal seguro (siempre) digitalmente
  • Miembro de dominio: Requerir strong (Windows 2000 o una versión posterior) de clave de sesión
  • Controlador de dominio: Servidor LDAP requisitos de firma
  • Servidor de red Microsoft: firmar digitalmente las comunicaciones (siempre)
  • Acceso de red: Permite anónimo Sid / Name translation
  • Acceso de red: No permitir la enumeración anónima de SAM cuentas y recursos compartidos
  • Seguridad de red: nivel de autenticación de LAN Manager
  • Auditoría: Apagar el sistema de inmediato si no puede registrar auditorías de seguridad
  • Acceso de red: Requisitos de firma de cliente LDAP

Más información


En las secciones siguientes se describen las incompatibilidades que pueden producirse cuando se cambia una configuración específica en dominios de Windows NT 4.0, Windows 2000 dominios y dominios de Windows Server 2003.

Derechos de usuario

La lista siguiente describe un derecho de usuario, identifica los valores de configuración que pueden causar problemas, describe por qué se debe aplicar el derecho de usuario, y por qué quizás desee quitar el derecho de usuario y proporciona ejemplos de problemas de compatibilidad que pueden producirse cuando el usuario derecho se configura.
  1. Tener acceso a este equipo desde la red
    1. Fondo

      La capacidad de interactuar con equipos remotos basados en Windows requiere el derecho de usuario tener acceso a este equipo desde la red . A continuación se indican algunos ejemplos de estas operaciones de red:
      • Replicación de Active Directory entre controladores de dominio en un dominio común o bosque
      • Solicitudes de autenticación a los controladores de dominio de los usuarios y de equipos
      • Acceso a carpetas compartidas, impresoras y otros servicios del sistema ubicados en equipos remotos de la red


      Los usuarios, equipos y cuentas de servicio obtienen o pierden el derecho de usuario tener acceso a este equipo desde la red al ser explícita o implícitamente, agregado o quitado de un grupo de seguridad que se ha concedido este derecho de usuario. Por ejemplo, una cuenta de usuario o una cuenta de equipo puede agregarse explícitamente a un grupo de seguridad personalizado o un grupo de seguridad integrado por un administrador, o puede agregarse implícitamente por el sistema operativo a un grupo de seguridad programado como usuarios de dominio, autenticado Los usuarios, o controladores de dominio empresariales.

      De forma predeterminada, las cuentas de usuario y cuentas de equipo se conceden al usuario tener acceso a este equipo desde la red derecho cuando calcular grupos tales como todos o, preferiblemente, usuarios autenticados y, para los controladores de dominio, el grupo controladores de dominio empresariales , se definen en los controladores de dominio predeterminada del objeto de directiva de grupo (GPO).
    2. Configuraciones arriesgadas

      Los siguientes son dañinos de configuración:
      • Quitar el grupo de seguridad controladores de dominio empresariales de este derecho de usuario
      • Quitar el grupo Usuarios autenticados o un grupo explícito que permita a los usuarios, equipos y cuentas de servicio el derecho de usuario para conectarse a equipos a través de la red
      • Quitar todos los usuarios y equipos de este derecho de usuario
    3. Razones para conceder este derecho de usuario
      • Conceder el derecho de usuario tener acceso a este equipo desde la red al grupo de controladores de dominio empresariales satisface los requisitos de autenticación que debe tener la replicación de Active Directory para la replicación entre controladores de dominio en el mismo bosque.
      • Este derecho de usuario permite a los usuarios y equipos tener acceso a archivos compartidos, impresoras y servicios del sistema, incluyendo Active Directory.
      • Este derecho de usuario es necesario para los usuarios tener acceso al correo mediante versiones anteriores de Microsoft Outlook Web Access (OWA).
    4. Razones para quitar este derecho de usuario
      • Los usuarios que pueden conectar sus equipos a la red pueden tener acceso a recursos en equipos remotos que tienen permisos para. Por ejemplo, este derecho de usuario es necesaria para un usuario para conectarse a impresoras compartidas y carpetas. Si se concede este derecho de usuario todos grupo, y si algunas carpetas compartidas tienen permisos de sistema de archivos NTFS configurados de modo que el mismo grupo tenga acceso de lectura y de recursos compartidos, cualquier persona puede ver los archivos de esas carpetas compartidas. Sin embargo, esto es una situación poco probable en las instalaciones recientes de Windows Server 2003 porque el recurso compartido predeterminado y los permisos de NTFS en Windows Server 2003 no incluyen el grupo todos. Para los sistemas que se han actualizado 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 ninguna razón válida para quitar el grupo de controladores de dominio empresariales de este derecho de usuario.
      • Generalmente, se quita el grupo todos a favor del grupo Usuarios autenticados. Si se quita el grupo todos, el grupo Usuarios autenticados debe concederse este derecho de usuario.
      • Dominios de Windows NT 4.0 actualizados a Windows 2000 no conceden explícitamente al usuario tener acceso a este equipo desde la red derecha para el grupo todos, el grupo Usuarios autenticados o el grupo de controladores de dominio empresariales. Por lo tanto, al quitar el grupo todos de la directiva de dominio de Windows NT 4.0, la replicación de Active Directory se 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 concediendo que este derecho de usuario de grupo de controladores de dominio empresariales al actualizar los controladores de dominio principal (PDC) de Windows NT 4.0. Conceda al grupo de controladores de dominio empresariales de este derecho si no está presente en el Editor de objetos de directiva de grupo de usuario.
    5. Ejemplos de problemas de compatibilidad
      • Windows 2000 y Windows Server 2003: Como indican las herramientas como REPLMON y REPADMIN o replicación de sucesos en el registro de eventos de supervisión, se producirá un error de replicación de las particiones siguientes con errores de "Acceso denegado".
        • Partición de esquema del directorio activo
        • Partición de configuración
        • Partición de dominio
        • Partición de catálogo global
        • Partición de aplicación
      • Sistemas operativos de red Microsoft todos: Se producirá un error en la autenticación de la cuenta de usuario de los equipos de cliente de red remota, a menos que el usuario o un grupo de seguridad que el usuario es un miembro de se ha concedido este derecho de usuario.
      • Sistemas operativos de red Microsoft todos: Se producirá un error en la autenticación de cuentas de clientes de red remotos, a menos que la cuenta o la cuenta es un miembro de un grupo de seguridad se ha concedido este derecho de usuario. Este escenario se aplica a cuentas de usuario, cuentas de equipo y cuentas de servicio.
      • Sistemas operativos de red Microsoft todos: Quitar todas las cuentas este derecho de usuario evitará cualquier cuenta inicien sesión en el dominio o tenga acceso a recursos de red. Si los grupos programados como controladores de dominio empresariales, todos o usuarios autenticados se quitan, debe conceder explícitamente este derecho de usuario a cuentas o a grupos de seguridad que la cuenta es un miembro de 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.
      • Sistemas operativos de red Microsoft todos: La cuenta de administrador local utiliza una contraseña "en blanco". No se permite la conectividad de red con contraseñas en blanco para las cuentas de administrador en un entorno de dominio. Con esta configuración, puede esperar recibir un mensaje de error "Acceso denegado".
  2. Permitir el registro local
    1. Fondo

      Los usuarios que intentan iniciar sesión en la consola de un equipo basado en Windows (mediante el método abreviado CTRL + ALT + SUPR) y las cuentas que intentan iniciar un servicio deben tener privilegios de inicio de sesión local en el equipo host. Los administradores que inician sesión en las consolas de equipos miembro o controladores de dominio en toda la empresa y los usuarios que inician sesión en equipos miembro para tener acceso a sus escritorios mediante algunos ejemplos de operaciones de inicio de sesión local cuentas sin privilegios. Los usuarios que utilizan una conexión de escritorio remoto o servicios de Terminal Server deben tener el usuario Permitir el inicio de sesión local en los equipos de destino que ejecutan Windows 2000 o Windows XP porque estos modos de inicio de sesión se consideran como locales en el equipo host. Usuarios que inician sesión en un servidor que cuenta con Terminal Server habilitado y que no tienen este derecho de usuario puede aún iniciar una sesión interactiva remota en los dominios de Windows Server 2003 si tienen el derecho de usuario Permitir inicio de sesión a través de servicios de Terminal Server .
    2. Configuraciones arriesgadas

      Los siguientes son dañinos de configuración:
      • Quitar grupos de seguridad administrativos, incluyendo operadores de cuentas, operadores de copia, operadores de impresión u operadores de servidores y el grupo de administradores integrado de la directiva del controlador de dominio predeterminado.
      • Quitar las cuentas de servicio que se utilizan por componentes y programas en los equipos miembro y controladores de dominio en el dominio de la directiva del controlador de dominio predeterminado.
      • Quitar usuarios o grupos de seguridad que inician sesión en la consola de los equipos miembro del dominio.
      • Quitar las cuentas de servicio que se definen en la base de datos de administrador de cuentas de seguridad (SAM) local de los equipos miembro o equipos del grupo de trabajo.
      • Quitar las cuentas administrativas no integradas que se autentican a través de servicios de Terminal Server que se ejecuta en un controlador de dominio.
      • Agregar todas las cuentas de usuario en el dominio de forma explícita o implícita a través de todos sesión derecha grupo el Denegar el inicio de sesión localmente . Esta configuración impedirá a los usuarios iniciar sesión en los equipos miembro o controladores de dominio en el dominio.
    3. Razones para conceder este derecho de usuario
      • Los usuarios deben tener el derecho de usuario Permitir el inicio de sesión local para tener acceso 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 iniciar sesión a través de una sesión de servicios de Terminal Server que se ejecuta en un equipo miembro basado en Windows 2000 o un controlador de dominio.
    4. Razones para quitar este derecho de usuario
      • Para restringir el acceso a la consola a cuentas de usuario legítimas podría resultar en que los usuarios no autorizados descargar y ejecutar código malintencionado para cambiar sus derechos de usuario.
      • Al quitar el derecho de usuario Permitir el inicio de sesión local evitan los inicios de sesión no autorizados en las consolas de equipos, como controladores de dominio o servidores de aplicaciones.
      • Eliminación de este derecho de inicio de sesión impide que cuentas sin dominio inicien sesión en la consola de los equipos miembro del dominio.
    5. Ejemplos de problemas de compatibilidad
      • Servidores de terminales Server de Windows 2000: El derecho de usuario Permitir el inicio de sesión local se requiere para que los usuarios iniciar sesión en servidores terminal Server de Windows 2000.
      • Windows NT 4.0, Windows 2000, Windows XP o Windows Server 2003: Las cuentas de usuario se deben conceder este derecho de usuario para 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 posterior: En equipos que ejecutan Windows NT 4.0 y posterior, si agrega el derecho de usuario Permitir el inicio de sesión local pero implícita o explícitamente, también concesión el derecho de inicio de sesión Denegar el inicio de sesión localmente , las cuentas no podrán iniciar sesión en la consola del dominio controladores.
  3. Omitir comprobación de recorrido
    1. Fondo

      El derecho de usuario Omitir comprobación de recorrido permite al usuario explorar las carpetas en el sistema de archivos NTFS o en el registro sin comprobar el permiso de acceso especial Recorrer carpeta . El derecho de usuario Omitir comprobación de recorrido permite al usuario mostrar el contenido de una carpeta. Permite al usuario recorrer sólo las carpetas.
    2. Configuraciones arriesgadas

      Los siguientes son dañinos de configuración:
      • Quitar las cuentas no administrativas que inician sesión en equipos de servicios de Terminal Server basado en Windows 2000 o servicios de Terminal Server basado en Windows Server 2003 que no tiene permisos para obtener acceso a archivos y carpetas en el sistema de archivos.
      • Quitar el grupo todos de la lista de principales de seguridad que tienen este usuario derecho de forma predeterminada. Sistemas operativos Windows y también muchos programas están diseñados con la expectativa de que cualquiera que pueda tener acceso el equipo legítimamente tendrá el derecho de usuario Omitir comprobación de recorrido . Por lo tanto, quitar el todos grupo de la lista de principales de seguridad que tienen este derecho de usuario por defecto podría generar inestabilidad en el sistema operativo o un error de programa. Es mejor dejar este valor en su valor predeterminado.
    3. Razones para conceder este derecho de usuario

      La configuración predeterminada para el derecho de usuario Omitir comprobación de recorrido es permitir todos los usuarios saltarse la comprobación de recorrido. Para los administradores experimentados del sistema Windows, éste es el comportamiento esperado y configuran las listas de control de acceso de sistema de archivos (SACL) en consecuencia. El único escenario donde la configuración predeterminada puede conducir a un contratiempo es si el administrador que configura los permisos no entiende el comportamiento y espera que los usuarios que no se pueden tener acceso a una carpeta principal no podrá tener acceso al contenido de los hijos carpetas.
    4. Razones para quitar este derecho de usuario

      Para intentar impedir el acceso a los archivos o las carpetas del sistema de archivos, las organizaciones que están muy preocupadas por la seguridad pueden sentirse tentadas de quitar el grupo todos o incluso el grupo de usuarios de la lista de grupos que tienen el Omitir comprobación de recorrido derecho de usuario.
    5. Ejemplos de problemas de compatibilidad
      • Windows 2000, Windows Server 2003: Si el derecho de usuario Omitir comprobación de recorrido se quita o se configura incorrectamente en equipos que ejecutan Windows 2000 o Windows Server 2003, la configuración de directiva de grupo en la carpeta SYVOL no se replicará entre los controladores de dominio en el dominio.
      • Windows 2000, Windows XP Professional, Windows Server 2003: Equipos que ejecutan Windows 2000, Windows XP Professional o Windows Server 2003 registrarán los sucesos 1000 y 1202 y no podrán aplicar la directiva de equipo y la directiva de usuario cuando se quitan los permisos del sistema de archivo requeridos del árbol SYSVOL si la omisión la comprobación de derecho de usuario de recorrido se quita o se configura incorrectamente.

        Para obtener más información, haga clic en el siguiente número de artículo para verlo en Microsoft Knowledge Base:
         
        290647 identificadores de suceso 1000, 1001 se registra cada cinco minutos en el registro de sucesos de aplicación
         
      • Windows 2000, Windows Server 2003: En equipos que ejecutan Windows 2000 o Windows Server 2003, la ficha cuota en el Explorador de Windows desaparecerá cuando vea las propiedades de un volumen.
      • Windows 2000: No administradores que inicien sesión en un servidor terminal server de Windows 2000 pueden recibir el siguiente mensaje de error:
        Error de aplicación de Userinit.exe. La aplicación no se ha podido inicializar correctamente 0xc0000142 haga clic en Aceptar para finalizar la aplicación.
      • Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003: Los usuarios cuyos equipos ejecutan Windows NT 4.0, Windows 2000, Windows XP o Windows Server 2003 no puede tener acceso a carpetas compartidas o los archivos en las carpetas compartidas y pueden recibir el mensaje de error "Acceso denegado" Si no se les concede el Bypass traverse comprobación de derecho de usuario.


        Para obtener más información, haga clic en el siguiente número de artículo para verlo en Microsoft Knowledge Base:
         
        277644 mensaje de error "Acceso denegado" cuando los usuarios intentan tener acceso a carpetas compartidas
         
      • Windows NT 4.0: En equipos basados en Windows NT 4.0, quitar el derecho de usuario Saltarse la comprobación hará que una copia del archivo en secuencias de archivo. Si quita este derecho de usuario, cuando se copia un archivo desde un cliente de Windows o desde un cliente Macintosh a un controlador de dominio de Windows NT 4.0 que ejecuta Servicios para Macintosh, se pierde la secuencia de archivo de destino y el archivo aparece como archivo de sólo texto.
      • Microsoft Windows 95, Microsoft Windows 98: En un equipo cliente que ejecuta Windows 95 o Windows 98, el net use * /Home comando fallará con un mensaje de error "Acceso denegado" si el grupo Usuarios autenticados no se concede el derecho de usuario Omitir comprobación de recorrido .
      • Outlook Web Access: No administradores no podrán iniciar sesión en Microsoft Outlook Web Access y recibirán un mensaje de error "Acceso denegado" Si no tienen el derecho de usuario Omitir comprobación de recorrido .

Configuración de seguridad

La lista siguiente identifica una configuración de seguridad, y la lista anidada proporciona una descripción sobre la configuración de seguridad, identifica los valores de configuración que pueden causar problemas, describe por qué debería aplicar la configuración de seguridad y, a continuación, se describe por qué razones es aconsejable quitar la configuración de seguridad. La lista anidada, a continuación, 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.
  1. Auditoría: Apagar el sistema de inmediato si no puede registrar auditorías de seguridad
    1. Fondo
      • El auditoría: apagar el sistema inmediatamente si no puede registrar auditorías de seguridad determina si el sistema se apaga cuando no puede registrar sucesos de seguridad. Esta configuración es necesaria para la evaluación C2 del programa TCSEC Trusted Computer Security evaluación criterios () y los criterios comunes para la evaluación de seguridad de tecnología de información 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 cierra y aparece un mensaje de error Stop.
      • Si el equipo no puede registrar sucesos en el registro de seguridad, prueba esencial o importante información de solución de problemas puede no estar disponible para su revisión después de un incidente de seguridad.
    2. Configuración arriesgada

      La siguiente es una configuración perjudicial: el auditoría: apagar el sistema inmediatamente si no puede registrar auditorías de seguridad está activado y el tamaño del registro de sucesos de seguridad está restringido por la no sobrescribir sucesos (borrado manual del registro) opción, Sobrescribir sucesos cuando sea necesario o Sobrescribir sucesos de hace más de días número del Visor de sucesos. Consulte la sección "Ejemplos de problemas de compatibilidad" para obtener información acerca de los riesgos específicos para los equipos que ejecutan la versión comercial original de Windows 2000, Windows 2000 Service Pack 1 (SP1), Windows 2000 SP2 o SP3 de Windows 2000.
    3. Razones para habilitar esta configuración

      Si el equipo no puede registrar sucesos en el registro de seguridad, prueba esencial o importante información de solución de problemas puede no estar disponible para su revisión después de un incidente de seguridad.
    4. Razones para deshabilitar esta configuración
      • Habilitar la de auditoría: apagar el sistema inmediatamente si no puede registrar auditorías de seguridad configuración detiene el sistema si no se puede registrar una auditoría de seguridad por algún motivo. Normalmente, un suceso no puede registrarse 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 sucesos (borrado manual del registro) o la opción Sobrescribir sucesos de hace más de días de número .
      • La carga administrativa de habilitar el auditoría: apagar el sistema inmediatamente si no puede registrar auditorías de seguridad configuración puede ser muy alta, sobre todo si también activa la opción no sobrescribir sucesos (borrado manual del registro) para el registro de seguridad. Esta configuración proporciona una responsabilidad individual de las acciones del operador. Por ejemplo, un administrador podría restablecer permisos en todos los usuarios, equipos y grupos en una unidad organizativa (OU) donde se habilitó la auditoría mediante la cuenta de administrador integrada u otra cuenta compartida y, a continuación, denegar que restablezcan esos permisos. Sin embargo, al habilitar a la opción reducir la solidez del sistema porque un servidor puede verse obligado a cerrar si se satura con eventos de inicio de sesión y otros sucesos de seguridad que se escriben en el registro de seguridad. Además, dado que el cierre no es correcto, pueden producirse daños irreparables en el sistema operativo, programas o datos. Si bien NTFS garantiza la integridad del sistema de archivos un cerrarse el sistema incorrectamente, no puede garantizar que cada archivo de datos de cada programa será en un formato utilizable cuando se reinicia el sistema.
    5. Nombre simbólico:

      CrashOnAuditFail
       
    6. Ruta de acceso 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 comercial original de Windows 2000, Windows 2000 SP1, Windows 2000 SP2 o Windows Server SP3 pueden dejar de registrar eventos antes el tamaño especificado en la opción máximo tamaño de registro de seguridad se ha alcanzado el registro de sucesos. Este error se corrigió en el Service Pack 4 (SP4) de Windows 2000. Asegúrese de que los controladores de dominio de Windows 2000 tienen Windows 2000 Service Pack 4 instalado antes de habilitar a esta opción.

        Para obtener más información, haga clic en el siguiente número de artículo para verlo en Microsoft Knowledge Base:
         
        312571 el registro de sucesos deja de registrarlos antes de alcanzar el tamaño máximo del registro
         
      • Windows 2000, Windows Server 2003: Equipos que ejecutan Windows 2000 o Windows Server 2003 puede dejar de responder y, a continuación, pueden reiniciarse espontáneamente si el auditoría: apagar el sistema inmediatamente si no puede registrar auditorías de seguridad está activado, el registro de seguridad está lleno y uno existente no se puede sobrescribir la entrada de registro de sucesos. Cuando se reinicia el equipo, aparecerá el siguiente mensaje de error Stop:
        STOP: C0000244 {Error de auditoría}
        Error al intentar generar una auditoría de seguridad.
        Para recuperar, un administrador debe iniciar sesión, archivar el registro de seguridad (opcional), borrar el registro de seguridad y, a continuación, restablezca esta opción (opcional y según proceda).
      • Cliente de redes Microsoft para MS-DOS, Windows 95, Windows 98, Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003: No administradores que intenten iniciar sesión en un dominio recibirán el mensaje de error siguiente:
        Su cuenta está configurada para impedir que use este equipo. Pruebe con otro equipo.
      • Windows 2000: En equipos basados en Windows 2000, 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
        Para obtener más información, haga clic en el siguiente número de artículo para verlo en Microsoft Knowledge Base:
         
        Mensaje de error de 285665 : su cuenta está configurada para impedir que use este equipo
         
      • Windows 2000: En controladores de dominio de Windows 2000, el servicio de mensajería entre sitios (Ismserv.exe) se detendrá y no se puede reiniciar. DCDIAG informará del error como "Error de servicios de prueba de ISMserv" y 1083 de ID de evento se registrará en el registro de sucesos.
      • Windows 2000: En controladores de dominio de Windows 2000, se producirá un error en la replicación de Active Directory y aparecerá un mensaje de "error acceso denegado" si el registro de sucesos de seguridad está lleno.
      • Microsoft Exchange 2000: Los servidores que ejecutan Exchange 2000 no podrán montar la base de datos de almacén de información y se registrará el evento 2102 en el registro de sucesos.
      • Outlook, Outlook Web Access: No administradores no podrán tener acceso a su correo a través de Microsoft Outlook o Microsoft Outlook Web Access y recibirán el error 503.
  2. Controlador de dominio: requisitos de firma de servidor LDAP
    1. Fondo

      El controlador de dominio: requisitos de firma de servidor LDAP configuración de seguridad determina si el servidor de protocolo ligero de acceso a directorios (LDAP) requiere que los clientes LDAP negocien la firma de datos. Los valores posibles para esta configuración de directiva son:
      • Ninguno: No es necesaria la firma de datos para enlazar con el servidor. Si el cliente solicita la firma de datos, el servidor la admite.
      • Requiere firma: La opción de firma de datos LDAP ha de negociarse a menos que se sirve Transport Layer Security/Secure Sockets Layer (TLS/SSL).
      • no definido: Esta opción no está habilitada o deshabilitada.
    2. Configuraciones arriesgadas

      Los siguientes son dañinos de configuración:
      • Habilitar requiere firma en entornos donde los clientes no admiten la firma LDAP o donde la firma de cliente LDAP no está habilitada en el cliente
      • Aplicar el Windows 2000 o la plantilla de seguridad Hisecdc.inf de Windows Server 2003 en entornos donde los clientes no admiten la firma LDAP o donde la firma LDAP del cliente no está habilitada
      • Aplicar el Windows 2000 o la plantilla de seguridad Hisecws.inf de Windows Server 2003 en entornos donde los clientes no admiten la firma LDAP o donde la firma LDAP del cliente no está habilitada
    3. Razones para habilitar esta configuración

      El tráfico de red sin firmar es susceptible a ataques de intermediario en donde un intruso captura los paquetes entre el cliente y el servidor, modifica los paquetes y, a continuación, los reenvía al servidor. Cuando este comportamiento se produce en un servidor LDAP, un atacante podría provocar que un servidor tome decisiones basándose en consultas falsas del cliente LDAP. Puede reducir este riesgo en una red corporativa mediante la implementación de medidas eficaces de seguridad física para ayudar a proteger la infraestructura de red. Modo de encabezado de autenticación de Internet Protocol security (IPSec) puede ayudar a prevenir los ataques de intermediario. Modo de encabezado de autenticación realiza una autenticación mutua e integridad de paquete para el tráfico IP.
    4. Razones para deshabilitar esta configuración
      • Los clientes que no admiten la firma LDAP no podrán llevar a cabo consultas LDAP en controladores de dominio ni en catálogos globales si se negocia la autenticación NTLM y si no están instalados los service Pack correctos en los controladores de dominio de Windows 2000.
      • Se cifrarán las trazas de red del tráfico LDAP entre los clientes y servidores. Esto hace difícil examinar las conversaciones LDAP.
      • Servidores basados en Windows 2000 deben tener Windows 2000 Service Pack 3 (SP3) instalan o cuando se administran con programas que admiten la firma LDAP y que se ejecutan en equipos cliente que ejecutan Windows 2000 SP4, Windows XP o Windows Server 2003. Para obtener más información, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
         
        Controladores de dominio de 325465 los Windows 2000 requieren el Service Pack 3 o posterior al utilizar las herramientas de administración de Windows Server 2003
         
    5. Nombre simbólico:

      LDAPServerIntegrity
    6. Ruta de acceso del registro:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LDAPServerIntegrity (Reg_DWORD)
    7. Ejemplos de problemas de compatibilidad
      • Los enlaces simples se producirá y recibirá el siguiente mensaje de error:
        En ldap_simple_bind_s () Error: se requiere autenticación sólida.
      • Windows 2000 Service Pack 4, Windows XP, Windows Server 2003: En clientes que ejecutan Windows 2000 SP4, Windows XP o Windows Server 2003, algunas herramientas de administración de Active Directory no funcionarán correctamente en los controladores de dominio que ejecutan versiones de Windows 2000 anteriores a SP3 cuando NTLM se negocia la autenticación.

        Para obtener más información, haga clic en el siguiente número de artículo para verlo en Microsoft Knowledge Base:
         
        Controladores de dominio de 325465 los Windows 2000 requieren el Service Pack 3 o posterior al utilizar las herramientas de administración de Windows Server 2003
         
      • Windows 2000 Service Pack 4, Windows XP, Windows Server 2003: En clientes que ejecutan Windows 2000 SP4, Windows XP o Windows Server 2003, algunas herramientas de administración de Active Directory destinados a controladores de dominio que ejecutan versiones de Windows 2000 que son anteriores a SP3 no funcionarán correctamente si están usando direcciones IP (por ejemplo, "dsa.msc/Server =x.x.x.x" donde
        x.x.x.x es una dirección IP).


        Para obtener más información, haga clic en el siguiente número de artículo para verlo en Microsoft Knowledge Base:
         
        Controladores de dominio de 325465 los Windows 2000 requieren el Service Pack 3 o posterior al utilizar las herramientas de administración de Windows Server 2003
         
      • Windows 2000 Service Pack 4, Windows XP, Windows Server 2003: En clientes que ejecutan Windows 2000 SP4, Windows XP o Windows Server 2003, algunas herramientas de administración de Active Directory destinados a controladores de dominio que ejecutan versiones de Windows 2000 que son anteriores al SP3 no funcionarán correctamente.

        Para obtener más información, haga clic en el siguiente número de artículo para verlo en Microsoft Knowledge Base:
         
        Controladores de dominio de 325465 los Windows 2000 requieren el Service Pack 3 o posterior al utilizar las herramientas de administración de Windows Server 2003
         
  3. Miembro de dominio: requerir clave de sesión protegida (Windows 2000 o posterior)
    1. Fondo
      • El miembro de dominio: requerir clave de sesión protegida (Windows 2000 o posterior) determina si se puede establecer un canal seguro con un controlador de dominio que no puede cifrar el tráfico del canal seguro con una clave de sesión protegida de 128 bits. Al habilitar a esta opción evita que establezca un canal seguro con ningún controlador de dominio que no puede cifrar datos de canal seguro con una clave protegida. Si deshabilita a esta configuración permite que las claves de sesión de 64 bits.
      • Para poder habilitar a esta opción en una estación de trabajo miembro o en un servidor, todos los controladores de dominio en el dominio al que pertenece el miembro deben ser capaces de cifrar datos de canal seguro con una clave protegida de 128 bits. Esto significa que todos esos controladores de dominio deben ejecutar Windows 2000 o posterior.
    2. Configuración arriesgada

      Habilitar la miembro de dominio: requerir clave de sesión protegida (Windows 2000 o posterior) configuración es una configuración perjudicial.
    3. Razones para habilitar esta configuración
      • Claves de sesión que se utilizan para establecer comunicaciones de canal seguro entre los equipos miembro y controladores de dominio están mucho más protegidas en Windows 2000 que se encuentran en las versiones anteriores de sistemas operativos de Microsoft.
      • Cuando sea posible, es una buena idea para aprovechar estas claves de sesión más protegidas para ayudar a proteger las comunicaciones de canal seguro contra el espionaje y de los ataques de red. Espionaje es una forma de ataque malintencionado donde los datos de la red es de lectura o está alterados en tránsito. Los datos pueden modificarse para ocultar o cambiar el remitente o bien para redireccionarlo.
      Importante: Un equipo que ejecuta Windows Server 2008 R2 o Windows 7 es compatible con claves seguras sólo cuando se utilizan canales seguros. Esta restricción evita una confianza entre un dominio basado en Windows NT 4.0 y cualquier dominio basado en Windows Server 2008 R2. Además, esta restricción bloquea la pertenencia de dominio basado en Windows NT 4.0 en equipos que ejecutan Windows 7 o Windows Server 2008 R2, y viceversa.
    4. Razones para deshabilitar esta configuración

      El dominio contiene equipos miembro que ejecutan sistemas operativos distintos de Windows 2000, Windows XP o Windows Server 2003.
    5. Nombre simbólico:

      StrongKey
    6. Ruta de acceso 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, al restablecer los canales seguros de las relaciones de confianza entre Windows NT 4.0 y dominios de Windows 2000 con NLTEST se produce un error. 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 no se respeta ya y se utiliza siempre la clave segura. Por este motivo, las confianzas con los dominios de Windows NT 4.0 no funcionan ya.
  4. Miembro de dominio: cifrar o firmar datos de canal seguro (siempre) digitalmente
    1. Fondo
      • Habilitar miembro de dominio: cifrar o firmar datos de canal seguro (siempre) digitalmente no se podrá establecer un canal seguro con ningún controlador de dominio que no puede firmar o cifrar todos los datos de canal seguro. Para ayudar a proteger el tráfico de autenticación de ataques de intermediario, los ataques de reproducción y otros tipos de ataques a la red, equipos basados en Windows crean un canal de comunicación que se conoce como un canal seguro mediante el servicio de Net Logon autenticar las cuentas de equipo. Los canales seguros también se utilizan cuando un usuario de un dominio se conecta a un recurso de red en un dominio remoto. Esta autenticación de varios dominios o autenticación de paso a través, permite a un equipo basado en Windows que se ha unido a un dominio para tener acceso a la base de datos de cuentas de usuario en su dominio y en cualquier dominio de confianza.
      • Para habilitar el miembro de dominio: cifrar o firmar datos de canal seguro (siempre) digitalmente configuración en un equipo miembro, todos los controladores de dominio en el dominio al que pertenece el miembro deben ser capaces de firmar o cifrar todos los datos de canal seguro. Esto significa que todos esos controladores de dominio deben ejecutar Windows NT 4.0 con Service Pack 6a (SP6a) o posterior.
      • Habilitar la miembro de dominio: cifrar o firmar datos de canal seguro (siempre) digitalmente automáticamente permite el miembro de dominio: digitalmente, cifrar o firmar datos de canal seguro (cuando sea posible) configuración.
    2. Configuración arriesgada

      Habilitar la miembro de dominio: cifrar o firmar datos de canal seguro (siempre) digitalmente puesta en los 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 intermediario, donde un intruso captura los paquetes entre el cliente y el servidor y, a continuación, modifica antes de reenviarlos al cliente. Cuando este comportamiento se produce en un servidor de protocolo ligero de acceso a directorios (LDAP), el intruso puede hacer que un cliente tome decisiones basándose en registros falsos del directorio LDAP. Puede reducir el riesgo de este tipo de ataque en una red corporativa mediante la implementación de medidas eficaces de seguridad física para ayudar a proteger la infraestructura de red. Además, implementar seguridad de protocolo Internet (IPSec) modo de encabezado de autenticación puede ayudarle a evitar los ataques de intermediario. Este modo realiza una autenticación mutua e integridad de paquete para el tráfico IP.
    4. Razones para deshabilitar esta configuración
      • Equipos en dominios locales o externos admiten canales seguros cifrados.
      • No todos los controladores de dominio en el dominio tienen el nivel de revisión de adecuado service pack para admitir canales seguros cifrados.
    5. Nombre simbólico:

      StrongKey
    6. Ruta de acceso del registro:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\RequireSignOrSeal (REG_DWORD)
    7. Ejemplos de problemas de compatibilidad
      • Windows NT 4.0: Equipos miembro basados en Windows 2000 no podrán unirse a dominios de Windows NT 4.0 y recibirán el mensaje de error siguiente:
        La cuenta no está autorizada a iniciar sesión desde esta estación.
        Para obtener más información, haga clic en el siguiente número de artículo para verlo en Microsoft Knowledge Base:
         
        Mensaje de error 281648 : la cuenta no está autorizada a iniciar sesión desde esta estación
         
      • Windows NT 4.0: 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 mensaje de error siguiente:
        La cuenta no está autorizada a iniciar sesión desde esta estación.
        Confianzas de nivel inferior existentes podrán tampoco autentiquen a los usuarios del dominio de confianza. Algunos usuarios pueden tener problemas para iniciar sesión 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 que se unen a dominios de Windows NT 4.0 no podrán autenticar los intentos de inicio de sesión y pueden recibir el siguiente mensaje de error, o en el registro de sucesos pueden registrarse los siguientes sucesos:
        Windows no puede conectarse al dominio porque el controlador de dominio está inactivo o no está disponible o porque no se encontró la cuenta de equipo
      • Red de Microsoft: Los clientes de Microsoft Network, recibirá 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 el inicio de sesión especificado.
  5. Cliente de red Microsoft: firmar digitalmente las comunicaciones (siempre)
    1. Fondo

      Bloque de mensajes de servidor (SMB) es el protocolo de uso compartido de recursos que admite 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 el servidor que aloja los datos. Si alguno no supera el proceso de autenticación, no se producirá la transmisión de datos.

      Habilitar la firma SMB comienza durante la negociación del protocolo SMB. Las directivas de firma SMB determinan si el equipo firma siempre 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 "tipo man in the middle". El protocolo de autenticación SMB de Windows 2000 también admite la autenticación de mensajes. Autenticación de mensajes ayuda a evitar ataques de mensajes activos. Para darle esta autenticación, la firma SMB pone una firma digital en cada SMB. El cliente y el servidor comprueban la firma digital.

      Para utilizar la firma 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 se habiliten para la firma utilizarán el protocolo de firma durante las siguientes sesiones de paquetes. 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 requerido para la firma SMB.


      Habilitar la firma digital en redes de alta seguridad ayuda a evita la suplantación de clientes y servidores. Este tipo de suplantación se conoce como apropiación de sesión. Un atacante que tiene acceso a la misma red que el cliente o el servidor utiliza herramientas de apropiación de sesión para interrumpir, finalizar o robar una sesión en curso. Un atacante puede interceptar y modificar paquetes SMB sin firmar, modificar el tráfico y a continuación, reenviarlo de modo que el servidor realice acciones no deseadas. O bien, el atacante puede presentarse como el servidor o el cliente después de una autenticación legítima y obtener acceso no autorizado a los datos.

      El protocolo SMB que se utiliza para compartir archivos e impresoras en equipos que ejecutan Windows 2000 Server, Windows 2000 Professional, Windows XP Professional o Windows Server 2003 admite la 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 los ataques de intermediario. La firma SMB proporciona esta autenticación colocando una firma digital en cada SMB. El cliente y el servidor, a continuación, comprueban la firma.

      Notas:
      • Como otra contramedida, puede habilitar las firmas digitales con IPSec para proteger todo el tráfico de red. Existen aceleradores basados en hardware para IPSec cifrado y firma que se puede utilizar para minimizar el impacto de rendimiento de la CPU del servidor. No hay ningún esos aceleradores que están disponibles para la firma SMB.

        Para obtener más información, consulte el capítulo de firmar digitalmente las comunicaciones del servidor en el sitio Web de Microsoft MSDN.

        Configurar la firma de SMB a través del Editor de objetos de directiva de grupo porque un cambio en un valor del registro local no tiene ningún efecto si hay una directiva de dominio de reemplazo.
      • En Windows 95, Windows 98 y Windows 98 Segunda edición, el cliente de servicios de directorio utiliza la firma SMB cuando se autentica con servidores de Windows Server 2003 utilizando autenticación NTLM. Sin embargo, estos clientes no utilizan la firma SMB cuando se autentican con estos servidores utilizando la autenticación de NTLMv2. Además, los servidores de Windows 2000 no responden a las solicitudes de los clientes de la firma SMB. Para obtener más información, vea el elemento 10: "seguridad de red: nivel de autenticación de Lan Manager."
    2. Configuración arriesgada

      Lo siguiente es una configuración perjudicial: dejando ambos el cliente de red Microsoft: firmar digitalmente las comunicaciones (siempre) configuración y la cliente de red Microsoft: firmar digitalmente las comunicaciones (si el servidor lo permite) configuración de " No está definido"o deshabilitado. Estas opciones permiten que el redirector envíe contraseñas de texto sin formato a servidores SMB que no son de Microsoft que no admitan el cifrado de contraseñas durante la autenticación.
    3. Razones para habilitar esta configuración

      Habilitación de cliente de red Microsoft: firmar digitalmente las comunicaciones (siempre) requiere que los clientes firmen el tráfico SMB al contactar con servidores que no requieren la firma SMB. Así los clientes son menos vulnerables a los ataques de secuestro de sesión.
    4. Razones para deshabilitar esta configuración
      • Habilitación de cliente de red Microsoft: firmar digitalmente las comunicaciones (siempre) evita que los clientes se comuniquen con los servidores de destino que no admiten la firma SMB.
      • Configurar los equipos para ignorar todas las comunicaciones SMB sin firmar impide que conecten las programas y sistemas operativos anteriores.
    5. Nombre simbólico:

      RequireSMBSignRdr
    6. Ruta de acceso 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 Windows XP en los clientes a servidores basados en Windows 2000 y servidores basados en Windows Server 2003 pueden tardar más tiempo.
      • No podrá asignar una unidad de red desde un cliente con esta opción habilitada, y recibirá el siguiente mensaje de error:
        La cuenta no está autorizada a iniciar sesión desde esta estación.
    8. Requisitos de reinicio

      Reinicie el equipo o reinicie el servicio de estación de trabajo. Para ello, escriba los comandos siguientes en un símbolo del sistema. Después de escribir cada comando, presione ENTRAR.
      net stop workstation
      comando Net start workstation
  6. Servidor de red Microsoft: firmar digitalmente las comunicaciones (siempre)
    1. Fondo
      • Bloque de Messenger de servidor (SMB) es el protocolo de uso compartido de recursos que admite 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 el servidor que aloja los datos. Si alguno no supera el proceso de autenticación, no se producirá la transmisión de datos.

        Habilitar la firma SMB comienza durante la negociación del protocolo SMB. Las directivas de firma SMB determinan si el equipo firma siempre 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 "tipo man in the middle". El protocolo de autenticación SMB de Windows 2000 también admite la autenticación de mensajes. Autenticación de mensajes ayuda a evitar ataques de mensajes activos. Para darle esta autenticación, la firma SMB pone una firma digital en cada SMB. El cliente y el servidor comprueban la firma digital.

        Para utilizar la firma 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 se habiliten para la firma utilizarán el protocolo de firma durante las siguientes sesiones de paquetes. 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 requerido para la firma SMB.


        Habilitar la firma digital en redes de alta seguridad ayuda a evita la suplantación de clientes y servidores. Este tipo de suplantación se conoce como apropiación de sesión. Un atacante que tiene acceso a la misma red que el cliente o el servidor utiliza herramientas de apropiación de sesión para interrumpir, finalizar o robar una sesión en curso. Un atacante puede interceptar y modificar paquetes Administrador de ancho de banda de subred (SBM) sin firmar, modificar el tráfico y a continuación, reenviarlo de modo que el servidor realice acciones no deseadas. O bien, el atacante puede presentarse como el servidor o el cliente después de una autenticación legítima y obtener acceso no autorizado a los datos.

        El protocolo SMB que se utiliza para compartir archivos e impresoras en equipos que ejecutan Windows 2000 Server, Windows 2000 Professional, Windows XP Professional o Windows Server 2003 admite la 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 los ataques de intermediario. La firma SMB proporciona esta autenticación colocando una firma digital en cada SMB. El cliente y el servidor, a continuación, comprueban la firma.
      • Como otra contramedida, puede habilitar las firmas digitales con IPSec para proteger todo el tráfico de red. Existen aceleradores basados en hardware para IPSec cifrado y firma que se puede utilizar para minimizar el impacto de rendimiento de la CPU del servidor. No hay ningún esos aceleradores que están disponibles para la firma SMB.
      • En Windows 95, Windows 98 y Windows 98 Segunda edición, el cliente de servicios de directorio utiliza la firma SMB cuando se autentica con servidores de Windows Server 2003 utilizando autenticación NTLM. Sin embargo, estos clientes no utilizan la firma SMB cuando se autentican con estos servidores utilizando la autenticación de NTLMv2. Además, los servidores de Windows 2000 no responden a las solicitudes de los clientes de la firma SMB. Para obtener más información, vea 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 Microsoft: firmar digitalmente las comunicaciones (siempre) en servidores y controladores de dominio que se tiene acceso por incompatibles equipos basados en Windows y aplicaciones de terceros equipos cliente basados en el sistema operativo en dominios locales o externos.
    3. Razones para habilitar esta configuración
      • Todos los equipos cliente que habilitan a esta opción directamente a través del registro o la configuración de directiva de grupo admiten la firma SMB. En otras palabras, todos los equipos cliente que tienen habilitada esta opció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 servidor de red Microsoft: firmar digitalmente las comunicaciones (siempre) está deshabilitada, la firma SMB está totalmente deshabilitada. Al deshabilitar SMB de todos los equipos firma deja más vulnerable a los ataques de secuestro de sesión.
    4. Razones para deshabilitar esta configuración
      • Si habilita a esta configuración puede provocar archivo copia y red lento en cliente equipos.
      • Al habilitar a esta configuración evitará que los clientes que no pueden negociar la firma SMB comuniquen con los servidores y controladores de dominio. Esto hace que las operaciones como las uniones de dominio, autenticación de usuario y de equipo o acceso a la red por programas falle.
    5. Nombre simbólico:

      RequireSMBSignServer
    6. Ruta de acceso 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 tienen instalado el cliente de servicios de directorio (DS) se producirá un error de autenticación de inicio de sesión y recibirán el mensaje de error siguiente:
        La contraseña de dominio proporcionada no es correcta o se ha denegado el acceso a su servidor de inicio de sesión.
        Para obtener más información, haga clic en el siguiente número de artículo para verlo en Microsoft Knowledge Base:
         
        811497 mensaje de error cuando el cliente de Windows 95 o Windows NT 4.0 inicia sesión en el dominio de Windows Server 2003
         
      • Windows NT 4.0: Los equipos cliente que ejecutan versiones de Windows NT 4.0 que son anteriores al Service Pack 3 (SP3), se producirá un error de autenticación de inicio de sesión y recibirán el mensaje de error siguiente:
        El sistema no pudo iniciar sesión. Asegúrese de que su nombre de usuario y dominio sean correctos, luego repita su contraseña.
        Algunos servidores SMB que no sean de Microsoft admiten sólo los intercambios de contraseña no cifrada durante la autenticación. (Estos intercambios también conocido 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 las contraseñas no cifradas para el cliente SMB en Windows NT 4.0 Service Pack 3 y los sistemas más recientes, modifique el registro como sigue: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Rdr\Parameters

        Nombre de valor: EnablePlainTextPassword

        Tipo de datos: REG_DWORD

        Datos: 1


        Para obtener más información acerca de temas relacionados, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
         
        224287 mensaje de error: error de sistema 1240. La cuenta no está autorizada a iniciar sesión desde esta estación.
      • Windows Server 2003: De forma predeterminada, la configuración de seguridad en controladores de dominio que ejecutan Windows Server 2003 está configurados para evitar comunicaciones de controlador de dominio se intercepta o manipulado por usuarios malintencionados. Para que los usuarios se comuniquen correctamente con un controlador de dominio que ejecuta Windows Server 2003, los equipos cliente deben utilizar tanto 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 anterior instalado y los clientes que ejecutan Windows 95 no tienen habilitada la firma de paquetes SMB. Por lo tanto, estos clientes pueden no ser capaces de autenticarse en un controlador de dominio basado en Windows Server 2003.
      • Windows 2000 y Windows Server 2003 configuración de la directiva: Dependiendo de sus necesidades específicas de instalación y configuración, recomendamos que configure las siguientes opciones de directiva en la menor entidad de ámbito necesario en la jerarquía del complemento Editor de directivas de grupo de Microsoft Management Console:
        • Equipo equipo\Configuración de Seguridad\opciones de seguridad
        • Enviar contraseña no cifrada para conectar a servidores SMB de terceros (esta configuración es para Windows 2000)
        • Cliente de red Microsoft: enviar contraseña sin cifrar a servidores SMB de terceros (esta configuración es para Windows Server 2003)

        Nota: En algunos servidores CIFS de otros fabricantes, como versiones anteriores de Samba, no puede utilizar contraseñas cifradas.
      • Los siguientes clientes son incompatibles con la servidor de red Microsoft: firmar digitalmente las comunicaciones (siempre) configuración:
        • Clientes de Mac OS X de Apple Computer, Inc.,
        • Clientes de red de Microsoft MS-DOS (por ejemplo, Microsoft LAN Manager)
        • Microsoft Windows para trabajo en grupo
        • Los clientes de Microsoft Windows 95 sin el cliente DS instalado
        • Microsoft equipos basados en Windows NT 4.0 sin Service Pack 3 o posterior instalados
        • Clientes de Novell Netware 6 CIFS
        • Clientes de SAMBA SMB que no tienen soporte para la firma SMB
    8. Requisitos de reinicio

      Reinicie el equipo o reinicie el servicio servidor. Para ello, escriba los comandos siguientes en un símbolo del sistema. Después de escribir cada comando, presione ENTRAR.
      net stop servidor
      Net start servidor
  7. Acceso de red: permitir traducción SID/nombre anónima
    1. Fondo

      El acceso de red: permitir traducción SID/nombre anónima configuración de seguridad 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 la acceso de red: permitir traducción SID/nombre anónima configuración es una configuración perjudicial.
    3. Razones para habilitar esta configuración

      Si el acceso de red: permitir traducción SID/nombre anónima configuración es deshabilitados, anteriores sistemas operativos o aplicaciones pueden no ser capaces de comunicarse con dominios de Windows Server 2003. Por ejemplo, los siguientes sistemas operativos, servicios o aplicaciones no funcionen:
      • Servidores de servicio de acceso remoto basados en NT 4.0 Windows
      • Microsoft SQL Server que se ejecutan en equipos 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 que se encuentran en dominios de Windows NT 3.x o Windows NT 4.0
      • SQL Server que se ejecuta en equipos basados en Windows 2000 que están ubicados en dominios Windows NT 3.x o Windows NT 4.0
      • Los usuarios de dominio de recursos de Windows NT 4.0 que desean concesión permisos de acceso 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. Razones para deshabilitar esta configuración

      Si habilita esta opción, un usuario malintencionado podría utilizar al SID conocido de los administradores para obtener el nombre real de la cuenta de administrador integrada, incluso si se ha cambiado el nombre de la cuenta. Esa persona podría utilizar el nombre de cuenta para iniciar un ataque de averiguación de contraseñas.
    5. Nombre simbólico: N/A
    6. Ruta de acceso del registro: Ninguno. 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: Equipos de Windows NT 4.0 de dominios de recursos mostrará el mensaje de error "Cuenta desconocida" en el Editor de ACL si los recursos, incluyendo las carpetas compartidas, archivos compartidos y objetos del registro, están protegidos mediante principales de seguridad que residen en dominios de cuentas que contienen controladores de dominio de Windows Server 2003.
  8. Acceso a redes: no permitir la enumeración anónima de SAM cuentas
    1. Fondo
      • El acceso a redes: no permitir la enumeración anónima de SAM cuentas configuración determina qué permisos adicionales se conceden para las conexiones anónimas al equipo. Windows permite a los usuarios anónimos realizar determinadas actividades, como enumerar los nombres de las cuentas de administrador de cuentas de seguridad (SAM) de workstation y server y de recursos compartidos de red. Por ejemplo, un administrador puede utilizar esto para conceder acceso a usuarios en 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 a todos grupo basándose en la configuración de la acceso de red: deja que los permisos se aplican a los usuarios anónimos configuración o la lista de control de acceso discrecional (DACL) de el objeto.

        Normalmente, las versiones anteriores de clientes (clientes de nivel inferior) solicitan conexiones anónimas durante la configuración de la sesión SMB. En estos casos, una traza de red muestra que el identificador de proceso de SMB (PID) es que el redirector de cliente como 0xFEFF en Windows 2000 o 0xCAFE en la interfaz RPC de Windows NT también puede intentar realizar conexiones anónimas.
      • Importante: Este valor no influye en los controladores de dominio. En los controladores de dominio, este comportamiento está controlado por la presencia de "NT AUTHORITY\ANONYMOUS LOGON" en "Pre-Windows 2000 compatible Access".
      • En Windows 2000, una configuración similar denominada Restricciones adicionales para conexiones anónimas administra el valor RestrictAnonymous del registro. La ubicación de este valor es el siguiente
        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA
        Para obtener más información acerca del valor RestrictAnonymous del registro, haga clic en los números de artículo siguientes para verlos en Microsoft Knowledge Base:
         
        246261 cómo utilizar el valor del registro RestrictAnonymous en Windows 2000
         
        143474 restringir la información disponible para los usuarios de inicio de sesión anónimo
         
    2. Configuraciones arriesgadas

      Habilitar la acceso a redes: no permitir la enumeración anónima de SAM cuentas configuración es una configuración perjudicial desde el punto de vista de compatibilidad. Deshabilitarla es una configuración perjudicial desde una perspectiva de seguridad.
    3. Razones para habilitar esta configuración

      Un usuario no autorizado puede ver anónimamente los nombres de cuenta y usar la información para tratar de adivinar las contraseñas o realizar ataques de ingeniería social . La ingeniería social es jerga que significa engañar a las personas para que revelen sus contraseñas o algún tipo de información de seguridad.
    4. Razones para deshabilitar esta configuración

      Si habilita esta opción, es imposible establecer confianzas con dominios de Windows NT 4.0. Esta configuración también causa problemas con clientes de nivel inferior (como clientes de Windows NT 3.51 y clientes de Windows 95) que intentan utilizar recursos en el servidor.
    5. Nombre simbólico:


      RestrictAnonymousSAM
    6. Ruta de acceso del registro:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RestrictAnonymousSAM (Reg_DWORD)
    7. Ejemplos de problemas de compatibilidad
    • Network Discovery de SMS 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 Windows 98 no podrán cambiar sus contraseñas.
    • Windows NT 4.0: Windows equipos miembro basados en NT 4.0 no podrán ser autenticados.
    • Windows 95, Windows 98: Equipos basados en Windows 98 y Windows 95 no podrán ser autenticados por los controladores de dominio de Microsoft.
    • Windows 95, Windows 98: Los usuarios de equipos basados en Windows 98 y Windows 95 no podrán cambiar las contraseñas de sus cuentas de usuario.
  9. Acceso a redes: no permitir la enumeración anónima de SAM cuentas y recursos compartidos
    1. Fondo
      • El acceso a redes: no permitir la enumeración anónima de SAM cuentas y recursos compartidos configuración (también se conoce como RestrictAnonymous) determina si se permite la enumeración anónima de cuentas de administrador de cuentas de seguridad (SAM) y recursos compartidos. Windows permite a los usuarios anónimos realizar determinadas actividades, como enumerar los nombres de las cuentas de dominio (usuarios, equipos y grupos) y de recursos compartidos de red. Esto es conveniente, por ejemplo, cuando un administrador desea conceder acceso a usuarios en un dominio de confianza que no mantiene una confianza recíproca. Si no desea permitir la enumeración anónima de cuentas SAM y recursos compartidos, habilite a esta configuración.
      • En Windows 2000, una configuración similar denominada Restricciones adicionales para conexiones anónimas administra el valor RestrictAnonymous del registro. La ubicación de este valor es el siguiente:
        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA
    2. Configuración arriesgada

      Habilitar la acceso a redes: no permitir la enumeración anónima de SAM cuentas y recursos compartidos configuración es una configuración perjudicial.
    3. Razones para habilitar esta configuración
      • Habilitar la acceso a redes: no permitir la enumeración anónima de SAM cuentas y recursos compartidos configuración evita la enumeración de cuentas SAM y recursos compartidos por los usuarios y equipos que usan cuentas anónimas.
    4. Razones para deshabilitar esta configuración
      • Si habilita esta opción, un usuario no autorizado puede ver anónimamente los nombres de cuenta y usar la información para tratar de adivinar las contraseñas o realizar ataques de ingeniería social . La ingeniería social es jerga que significa engañar a las personas para que revelen sus contraseñas o algún tipo de información de seguridad.
      • Si esta configuración está habilitada, resultará imposible establecer confianzas con dominios de Windows NT 4.0. Esta opción también causará problemas con clientes de nivel inferior como clientes de Windows NT 3.51 y Windows 95 que intentan usar recursos en el servidor.
      • Será imposible conceder acceso a usuarios de dominios de recursos porque los administradores del dominio que confía no podrán enumerar listas de cuentas en el otro dominio. Los usuarios que tienen acceso anónimo a los servidores de impresión y archivos no podrán enumerar los recursos de red compartidos en esos servidores. Los usuarios deben autenticarse antes de poder ver las listas de carpetas e impresoras compartidas.
    5. Nombre simbólico:

      RestrictAnonymous
    6. Ruta de acceso 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 las estaciones de trabajo Windows NT 4.0 cuando RestrictAnonymous está habilitado en controladores de dominio de los usuarios.
      • Windows NT 4.0: Agregar usuarios o grupos globales de dominios de Windows 2000 de confianza a grupos locales de Windows NT 4.0 en el Administrador de usuarios se producirá un error y aparecerá el siguiente mensaje de error:
        Actualmente no hay ningún servidor de inicio de sesión disponibles para atender la solicitud de inicio de sesión.
      • Windows NT 4.0: Windows equipos basados en NT 4.0 no podrán unirse a dominios durante la instalación o mediante la interfaz de usuario de dominio join.
      • 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. Cuando RestrictAnonymous está habilitado en el dominio de confianza, aparecerá el siguiente mensaje de error:
        No se pudo encontrar el controlador de dominio para este dominio.
      • Windows NT 4.0: Los usuarios que inician sesión en equipos basados en Windows NT 4.0 Terminal Server asignará para el directorio particular predeterminado en lugar del directorio particular que se define en el Administrador de usuarios para dominios.
      • Windows NT 4.0: Controladores de dominio de reserva (BDC) de Windows NT 4.0 no podrán iniciar el servicio Net Logon, obtener una lista de los examinadores de reserva o sincronizar la base de datos SAM de Windows 2000 o controladores de dominio de Windows Server 2003 en el mismo dominio.
      • Windows 2000: Equipos miembro basados en Windows 2000 en dominios no podrán ver las impresoras en los dominios externos si está habilitada la configuración de No obtener acceso sin permisos anónimos explícitos en la directiva de seguridad local del equipo cliente de Windows NT 4.0.
      • Windows 2000: Los usuarios de dominio de Windows 2000 no podrán agregar impresoras de red de Active Directory; Sin embargo, podrán agregar las impresoras después de seleccionarlas en la vista de árbol.
      • Windows 2000: En equipos basados en Windows 2000, en el Editor de ACL no podrá agregar usuarios o grupos globales de dominios de Windows NT 4.0 de confianza.
      • Versión 2 de ADMT: Se producirá un error en la migración de contraseñas para las cuentas de usuario que se migran entre los bosques con la herramienta de migración de directorio activo (ADMT) versión 2.

        Para obtener más información, haga clic en el siguiente número de artículo para verlo en Microsoft Knowledge Base:
         
        322981 cómo solucionar problemas de migración de contraseñas entre bosques con ADMTv2
      • Los clientes de outlook: La lista global de direcciones les aparecerá vacía a los clientes de Microsoft Outlook.

        Para obtener más información, haga clic en el siguiente número de artículo para verlo en Microsoft Knowledge Base:
        321169 rendimiento de SMB cuando copia archivos de Windows XP en un controlador de dominio de Windows 2000
      • SMS: Descubrimiento de red de Microsoft Systems Management Server (SMS) no podrá obtener información del sistema operativo. Por ello, escribirá "Desconocido" en la propiedad OperatingSystemNameandVersion de la propiedad de DDR de SMS del registro de datos de descubrimiento (DDR).
      • SMS: Cuando utilice el Asistente de usuario de administrador de SMS para buscar usuarios y grupos, no se mostrarán usuarios o grupos. Además, los clientes avanzados no pueden comunicarse con el punto de administración. Se requiere el acceso anónimo en el punto de administración.
      • SMS: Cuando utiliza la función Network Discovery en SMS 2.0 y en instalación de cliente remoto con la opción topología, cliente y sistemas operativos activada, pueden se descubran los equipos pero no esté instalados.
  10. Seguridad de red: nivel de autenticación de Lan Manager
    1. Fondo

      Autenticación de LAN Manager (LM) es el protocolo que se utiliza para autenticar a los clientes de Windows para las operaciones de red, incluidas las uniones de dominio, acceso a recursos de red y autenticación de usuario o equipo. El nivel de autenticación de LM determina qué protocolo de autenticación de desafío y respuesta se negocia entre el cliente y los equipos servidores. En concreto, el nivel de autenticación de LM determina qué protocolos de autenticación intentará negociar el cliente o que el servidor aceptará. El valor que se establece para LmCompatibilityLevel determina qué protocolo de autenticación de desafío/respuesta se utiliza para los inicios de sesión de red. Este valor afecta el nivel de protocolo de autenticación que utilizan los clientes, el nivel de seguridad de sesión negociada y el nivel de autenticación aceptado por los servidores.

      Las configuraciones posibles son las siguientes:
      Valor Configuración Descripción
      0 Enviar respuestas de LM y NTLM Los clientes utilizan autenticación LM y NTLM y nunca utilizan la seguridad de sesión NTLMv2. Los controladores de dominio aceptan autenticación LM, NTLM y NTLMv2.
      1 Enviar LM y NTLM: usar la seguridad de sesión NTLMv2 si se negocia Los clientes utilizan autenticación LM y NTLM y utilizan seguridad de sesión NTLMv2 si el servidor admite. Los controladores de dominio aceptan autenticación LM, NTLM y NTLMv2.
      2 Enviar sólo respuesta NTLM Los clientes utilizan sólo la autenticación NTLM y utilizan seguridad de sesión NTLMv2 si el servidor admite. Los controladores de dominio aceptan autenticación LM, NTLM y NTLMv2.
      3 Enviar sólo respuesta NTLMv2 Los clientes utilizan sólo la autenticación NTLMv2 y utilizan seguridad de sesión NTLMv2 si el servidor admite. Los controladores de dominio aceptan autenticación LM, NTLM y NTLMv2.
      4 Enviar sólo respuestas NTLMv2 y rechazar LM Los clientes utilizan sólo la autenticación NTLMv2 y utilizan seguridad de sesión NTLMv2 si el servidor admite. Controladores de dominio rechazan LM y aceptan sólo la autenticación NTLM y NTLMv2.
      5 Enviar sólo respuestas NTLMv2 y rechazar LM y NTLM Los clientes utilizan sólo la autenticación NTLMv2 y utilizan seguridad de sesión NTLMv2 si el servidor admite. Controladores de dominio rechazan LM y NTLM y aceptan sólo la autenticación NTLMv2.
      Nota: En Windows 95, Windows 98 y Windows 98 Segunda edición, el cliente de servicios de directorio utiliza la firma SMB cuando se autentica con servidores de Windows Server 2003 utilizando autenticación NTLM. Sin embargo, estos clientes no utilizan la firma SMB cuando se autentican con estos servidores utilizando la autenticación de NTLMv2. Además, los servidores de Windows 2000 no responden a las solicitudes de los clientes de la firma SMB.

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

      Si la directiva se establece en (5) respuestas enviar NTLMv2 y rechazar LM y NTLM en el equipo de destino al que desea conectarse, debe reducir la configuración en ese equipo o configurar la seguridad de la misma configuración que está en el equipo de origen que son conn ejo de.

      Buscar la ubicación correcta donde puede cambiar el Administrador de LAN de nivel de autenticación que establezca el cliente y el servidor en el mismo nivel. Después de encontrar la directiva que establece el Administrador de LAN nivel de autenticación, si desea conectarse a y desde equipos que ejecutan versiones anteriores de Windows, reduzca el valor de al menos (1) Enviar LM y NTLM: usar NTLM versión 2 seguridad de sesión si negocia. Un efecto de tener valores incompatibles es que si el servidor requiere NTLMv2 (valor 5), pero el cliente está configurado para utilizar LM y NTLMv1 único (valor 0), el usuario que intente la autenticación experimenta un error de inicio de sesión que tiene una contraseña incorrecta y que incrementa la mala recuento de contraseña. Si se configura la salida de bloqueo de cuenta, el usuario puede al final se bloquea.

      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: Tendrá que repetir el procedimiento siguiente en todos los controladores de dominio.
      1. Haga clic en Inicio, seleccione programasy, a continuación, haga clic en Herramientas administrativas.
      2. En Configuración de seguridad Local, expanda Directivas locales.
      3. Haga clic en Opciones de seguridad.
      4. Haga doble clic en seguridad de red: nivel de autenticación de LAN managery, a continuación, haga clic en un valor en la lista.

      Si la configuración vigente y la configuración Local son iguales, se cambió la directiva en este nivel. Si los valores son distintos, debe comprobar la directiva del controlador de dominio para determinar si la seguridad de red: nivel de autenticación de LAN manager se define allí. Si no se define allí, examine las directivas del controlador de dominio.

      Examinar directivas del controlador de dominio
      1. Haga clic en Inicio, seleccione programasy, a continuación, haga clic en Herramientas administrativas.
      2. En la directiva de Seguridad controlador de dominio , expanda Configuración de seguridady, a continuación, expanda Directivas locales.
      3. Haga clic en Opciones de seguridad.
      4. Haga doble clic en seguridad de red: nivel de autenticación de LAN managery, a continuación, haga clic en un valor en la lista.

      Note
      • También tendrá que examinar las directivas vinculadas en el nivel de sitio, el nivel de dominio o la unidad organizativa de nivel (OU) para determinar dónde debe configurar el nivel de autenticación de LAN manager.
      • Si implementa una configuración de directiva de grupo como la 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 del controlador de dominio predeterminado, la directiva sólo se aplica a los servidores de la unidad organizativa del controlador de dominio.
      • Es una buena idea establecer el nivel de autenticación de LAN manager en la menor entidad de ámbito necesario en la jerarquía de aplicación de directivas.
       
       
      Windows Server 2003 tiene una nueva configuración predeterminada para utilizar NTLMv2 únicamente. De forma predeterminada, Windows Server 2003 y los controladores de dominio basados en Windows 2000 Server SP3 tienen habilitada la "servidor de red Microsoft: firmar digitalmente las comunicaciones (siempre)" Directiva. Esta configuración requiere que el servidor SMB para realizar la firma de paquetes SMB. Se realizaron cambios en Windows Server 2003 porque los controladores de dominio, servidores de archivos, servidores de infraestructura de red y servidores Web de cualquier organización requieren una configuración diferente 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 utilizar este nivel de autenticación. Si aplica Active Directory cliente extensiones para Windows 95 o Windows 98 y Windows NT 4.0, las extensiones cliente utilizarán las características de autenticación mejoradas disponibles en NTLMv2. Como los equipos cliente que ejecutan cualquiera del sistema operativo siguiente no se ven afectados por objetos de directiva de grupo de Windows 2000, quizás 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 almacenar valor de hash de LAN manager en el próximo cambio de contraseña directiva o establece la clave de registro NoLMHash , clientes basados en Windows 98 y Windows 95 que no tienen instalado el cliente de servicios de directorio no pueden Inicie sesión en el dominio después de un cambio de contraseña.

      Muchos servidores CIFS de otros fabricantes, como Netware 6 de Novell, no son conscientes de NTLMv2 y sólo utilizan NTLM. Por lo tanto, los niveles superiores a 2 no permiten la conectividad. También hay clientes SMB de otros fabricantes que no utilizan la seguridad de sesión extendido. En estos casos, el LmCompatiblityLevel del servidor de recursos no se toma en consideración. El servidor, a continuación, paquetes de esta solicitud heredada y lo envía al controlador de dominio de usuario. La configuración del controlador de dominio, a continuación, decida qué algoritmos de hash se utilizan para comprobar la solicitud y si éstas están cumpliendo los requisitos de seguridad del controlador de dominio.

      Para obtener más información acerca de cómo configurar manualmente el nivel de autenticación de LAN manager, haga clic en los números de artículo siguientes para verlos en Microsoft Knowledge Base:
       
      147706 cómo deshabilitar la autenticación LM en Windows NT
       
      299656 cómo impedir que Windows almacene un hash de administrador de LAN de su contraseña en Active Directory y bases de datos locales de SAM
       
      312630 outlook sigue pidiéndole las credenciales de inicio de sesión
       
      2701704 Suceso de auditoría muestra el paquete de autenticación como NTLMv1 en lugar de NTLMv2
      Para obtener más información acerca de 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 autenticación NTLM 2
       
    2. Configuraciones arriesgadas

      Los siguientes son dañinos de configuración:
      • Configuración no restrictivos que envían las contraseñas en texto sin cifrar y que deniegan la negociación NTLMv2
      • Configuración restrictiva que impiden a los clientes incompatibles o controladores de dominio negociar un protocolo de autenticación común
      • Solicitar la autenticación NTLMv2 en los equipos miembro y controladores de dominio que ejecutan versiones de Windows NT 4.0 anteriores a Service Pack 4 (SP4)
      • Solicitar la autenticación NTLMv2 en los clientes de Windows 95 o en los clientes Windows 98 que no tienen instalado el cliente de servicios de directorio de Windows.
      • Si hace clic para activar la casilla de verificación de la seguridad de sesión NTLMv2 requieren en el complemento Editor de directivas de grupo de Microsoft Management Console en un equipo basado en Windows 2000 Service Pack 3 o Windows Server 2003, y disminuir el nivel de autenticación de LAN manager en 0, la dos configuraciones entran en conflicto y puede recibir 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 locales. Se ha producido un error desconocido al intentar abrir la base de datos.
        Para obtener más información acerca de la herramienta de análisis y configuración de seguridad, consulte los archivos de Ayuda de Windows Server 2003 o de Windows 2000.
    3. Razones para modificar esta configuración
      • Desea aumentar el protocolo de autenticación común más baja que es compatible con los clientes y controladores de dominio de su organización.
      • La autenticación segura es un requisito corporativo, por lo que desea impedir la negociación de lo protocolos LM y NTLM.
    4. Razones para deshabilitar esta configuración

      Cliente, requisitos de autenticación de servidor o ambos, han aumentado hasta el punto donde no se puede realizar la autenticación a través de un protocolo común.
    5. Nombre simbólico:

      LmCompatibilityLevel
    6. Ruta de acceso del registro:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel
    7. Ejemplos de problemas de compatibilidad
      • Windows Server 2003: De forma predeterminada, las respuestas de Windows Server 2003 NTLMv2 Send NTLM configuración está habilitada. Por lo tanto, Windows Server 2003 recibe el mensaje de error "Acceso denegado" después de la instalación inicial cuando intenta conectar con un clúster basado en Windows NT 4.0 o con servidores basados en LanManager V2.1, como OS/2 Lanserver. Este problema también se produce si intenta conectarse desde un cliente de la versión anterior a un servidor basado en Windows Server 2003.
      • Instalar el paquete de continuación 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). Para obtener más información acerca de SRP1, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
         
        311401 Windows 2000 Security Rollup Package 1, enero de 2002
         
      • Windows 7 y Windows Server 2008 R2: muchos servidores CIFS de otros fabricantes, como los servidores de Novell Netware 6 o Samba basados en Linux, no son conscientes de NTLMv2 y sólo utilizan NTLM. Por lo tanto, los niveles superiores a "2" no permiten la conectividad. Ahora en esta versión del sistema operativo, el valor predeterminado de LmCompatibilityLevel se cambió a "3". Por lo que al actualizar Windows, estos sistemas de almacenamiento de terceros pueden dejar de funcionar.
      • Los clientes de Microsoft Outlook le pedirá las credenciales aunque ya han iniciado sesión en el dominio. Cuando los usuarios proporcionan sus credenciales, reciben el siguiente mensaje de error: Windows 7 y Windows Server 2008 R2
        Las credenciales de inicio de sesión proporcionadas eran incorrectas. Asegúrese de que su nombre de usuario y dominio sean correctos, luego vuelva a escribir la contraseña.
        Cuando inicia Outlook, le pedirá sus credenciales aunque la configuración seguridad de red de inicio de sesión se establece en paso a través o en autenticación de contraseña. Después de escribir sus credenciales correctas, puede recibir el siguiente mensaje de error:
        Las credenciales de inicio de sesión proporcionadas eran incorrectas.
        Una traza de Monitor de red puede mostrar que el catálogo global emitió un error de procedimiento remoto (RPC) de llamada con un estado de 0 x 5. Un estado de 0 x 5 significa "Acceso denegado".
      • Windows 2000: Una captura de Monitor de red puede mostrar los errores siguientes en el NetBIOS sobre la sesión de TCP/IP (NetBT) server message block (SMB):
        Error de SMB R búsqueda directorio Dos, identificador de usuario no válido (91) ACCESS_DENIED (109) STATUS_LOGON_FAILURE (5)
      • Windows 2000: Si un dominio de Windows 2000 con NTLMv2 nivel 2 o posterior se confía en un dominio de Windows NT 4.0, los equipos miembro basados en Windows 2000 en el dominio de recursos pueden presentar errores de autenticación.
      • Windows 2000 y Windows XP: De forma predeterminada, Windows 2000 y Windows XP establecen la opción de directiva de seguridad Local de LAN Manager autenticación nivel 0. Un valor de 0 significa "respuestas Enviar LM y NTLM".

        Nota: Windows clústeres basados en NT 4.0 debe utilizar LM para la administración.
      • Windows 2000: Organización por clústeres de Windows 2000 no autentica un nodo que se une si ambos nodos forman parte de un Windows NT 4.0 Service Pack 6a (SP6a) dominio.
      • La herramienta Lockdown de IIS (HiSecWeb) establece el valor de LMCompatibilityLevel en 5 y el valor RestrictAnonymous en 2.
      • Servicios para Macintosh

        Módulo de autenticación de usuarios (UAM): El Microsoft UAM (módulo de autenticación de usuarios) proporciona un método para cifrar las contraseñas que utiliza para iniciar sesión en servidores de Windows AFP (Protocolo de archivos de AppleTalk). El módulo de autenticación de usuarios (UAM) de Apple proporciona sólo una mínima o ninguna codificación. Por lo tanto, su contraseña se podría interceptar fácilmente en la LAN o en Internet. Aunque el UAM no es necesario, proporciona autenticación cifrada a los servidores de Windows 2000 que ejecutan servicios para Macintosh. Esta versión incluye compatibilidad con autenticación cifrada NTLMv2 de 128 bits y una versión de Mac OS X 10.1 compatible.

        De forma predeterminada, los servicios de Windows Server 2003 para el servidor Macintosh permite sólo Microsoft Authentication.


        Para obtener más información, haga clic en los números de artículo siguientes para verlos en Microsoft Knowledge Base:
         
        834498 el cliente Macintosh no puede conectarse a servicios para Mac en Windows Server 2003
      • Windows Server 2008, Windows Server 2003, Windows XP y Windows 2000: Si configura el valor de LMCompatibilityLevel para ser 0 o 1 y, a continuación, configurar el valor NoLMHash para que sea 1, aplicaciones y componentes se pueden denegar el acceso a través de NTLM. Este problema se produce porque el equipo está configurado para habilitar LM pero no para utilizar contraseñas almacenados LM.

        Si configura el valor NoLMHash para que sea 1, debe configurar el valor de LMCompatibilityLevel para que sea 2 o superior.
  11. Seguridad de red: requisitos de firma de cliente LDAP
    1. Fondo

      El seguridad de red: requisitos de firma de cliente LDAP determina el nivel de firma de datos que se solicita en nombre de los clientes que emiten el enlace de protocolo ligero de acceso a directorios (LDAP) se solicita como sigue:
      • Ninguno: la solicitud LDAP BIND se emite con las opciones especificadas por el llamador.
      • Negociar firma: si no se ha iniciado el Secure Sockets Layer/Transport Layer Security (SSL/TLS), la solicitud LDAP BIND se inicia con la opción activada, además de las opciones especificadas por el llamador de firma de datos LDAP. Si se ha iniciado SSL/TLS, la solicitud LDAP BIND se inicia con las opciones especificadas por el llamador.
      • Requerir firma: es el mismo que Negociar firma. Sin embargo, si la respuesta saslBindInProgress intermedia del servidor LDAP no indica que se requiere la firma de tráfico LDAP, el llamador se le indica que falló la solicitud de comando LDAP BIND.
    2. Configuración arriesgada

      Habilitar la seguridad de red: requisitos de firma de cliente LDAP configuración es una configuración perjudicial. Si establece el servidor solicite firmas LDAP, también debe configurar la firma LDAP en el cliente. No configurar el cliente para utilizar firmas LDAP impedirá la comunicación con el servidor. Esto hace la autenticación de usuario, directiva de grupo configuración, secuencias de comandos de inicio de sesión y otras características de un error.
    3. Razones para modificar esta configuración

      El tráfico de red sin firmar es susceptible a ataques de intermediario en donde un intruso captura los paquetes entre el cliente y los servidores, modifica y, a continuación, los reenvía al servidor. Cuando esto ocurre en un servidor LDAP, un atacante podría provocar que un servidor responda basándose en consultas falsas del cliente LDAP. Puede reducir este riesgo en una red corporativa mediante la implementación de medidas eficaces de seguridad física para ayudar a proteger la infraestructura de red. Además, puede ayudar a prevenir todo tipo de ataques de intermediario si se requieren firmas digitales en todos los paquetes de red mediante los encabezados de autenticación IPSec.
    4. Nombre simbólico:

      LDAPClientIntegrity
    5. Ruta de acceso del registro:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LDAP\LDAPClientIntegrity
  12. Registro de sucesos: Tamaño máximo de registro de seguridad
    1. Fondo

      El registro de sucesos: tamaño máximo del registro de seguridad configuración de seguridad especifica el tamaño máximo del registro de sucesos de seguridad. Este registro tiene un tamaño máximo de 4 GB. Para localizar esta configuración, expanda
      Configuración de Windowsy, a continuación, expanda Configuración de seguridad.
    2. Configuraciones arriesgadas

      Los siguientes son dañinos de configuración:
      • Restringir el tamaño del registro de seguridad y el método de retención del registro de seguridad cuando el auditoría: apagar el sistema inmediatamente si no puede registrar auditorías de seguridad está habilitada. Consulte la "auditoría: apagar el sistema inmediatamente si no puede registrar auditorías de seguridad" sección de este artículo para obtener más detalles.
      • Restringir el tamaño del registro de seguridad de modo que se sobrescriben eventos de seguridad de interés.
    3. Razones para aumentar este valor

      Pueden dictar los requisitos empresariales y de seguridad que aumentan el tamaño del registro de seguridad para controlar el detalle del registro de seguridad adicionales o conservar los registros de seguridad para un período de tiempo más largo.
    4. Razones para disminuir este valor

      Registros del Visor de eventos son archivos asignados en memoria. El tamaño máximo de un registro de sucesos está limitado por la cantidad de memoria física en el equipo local y por la memoria virtual que está disponible para el proceso de registro de sucesos. Aumentar el tamaño del registro más allá de la cantidad de memoria virtual que está disponible en el Visor de sucesos no aumenta el número de entradas del registro que se mantienen.
    5. Ejemplos de problemas de compatibilidad

      Windows 2000: Los equipos que ejecutan versiones de Windows 2000 que son anteriores a Service Pack 4 (SP4) pueden dejar de registrar eventos en el registro de sucesos antes de alcanzar el tamaño especificado en el valor de tamaño máximo del registro en el Visor de sucesos Si el no sobrescribir sucesos (borrado manual del registro) opción está activada.


      Para obtener más información, haga clic en el siguiente número de artículo para verlo en Microsoft Knowledge Base:
       
      312571 el registro de sucesos deja de registrarlos antes de alcanzar el tamaño máximo del registro
       
  13. Registro de sucesos: Conservar el registro de seguridad
    1. Fondo

      El registro de sucesos: conservar el registro de seguridad configuración de seguridad determina el método de "ajuste" del registro de seguridad. Para localizar esta configuración, expanda Configuración de Windowsy, a continuación, expanda Configuración de seguridad.
    2. Configuraciones arriesgadas

      Los siguientes son dañinos de configuración:
      • No conservar todos los registrados antes de que se sobrescriban los sucesos de seguridad
      • Configurar el tamaño máximo del registro de seguridad valor demasiado reducido de modo que se sobrescriban los sucesos de seguridad
      • Restringir el método de retención y el tamaño de registro de seguridad mientras el auditoría: apagar el sistema inmediatamente si no puede registrar auditorías de seguridad está habilitada
    3. Razones para habilitar esta configuración

      Habilite a esta opción únicamente si se selecciona el método de retención Sobrescribir sucesos por días . Si utiliza un sistema de correlación de sucesos que sondea para eventos, asegúrese de que el número de días es al menos tres veces la frecuencia de sondeo. Hacer esto para permitir ciclos de sondeo fallidos.
  14. Acceso de red: deja que los permisos se aplican a los usuarios anónimos todos
    1. Fondo

      De forma predeterminada, la acceso de red: deja que los permisos se aplican a los usuarios anónimos se debe establecer en No está definido en Windows Server 2003. De forma predeterminada, Windows Server 2003 no incluye el token acceso anónimo en el todos grupo.
    2. Ejemplo de problemas de compatibilidad

      El siguiente valor de
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\everyoneincludesanonymous
      [REG_DWORD] = 0 x 0 interrumpe 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 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 el dominio de recursos es fiable en el lado de Windows Server 2003. Este comportamiento se produce porque el proceso inicia la confianza después de que la conexión anónima inicial es ACL con el símbolo todos, que incluye al SID anónimo en Windows NT 4.0.
    3. Razones para modificar esta configuración

      El valor debe establecerse en 0 x 1 o establecer mediante un GPO en la OU del controlador de dominio como: acceso de red: deja que los permisos se aplican a los usuarios anónimos - habilitado para realizar las creaciones de confianza posibles.

      Nota: Más otras configuraciones de seguridad aumentan de valor en lugar de hacia abajo hasta 0 x 0 en su estado más seguro. Una práctica más segura sería cambiar el registro en el emulador del controlador principal de dominio en lugar de en todos los controladores de dominio. Si la función de emulador de controlador de dominio principal se mueve por cualquier razón, el registro debe actualizarse en el nuevo servidor.

      Después de establecer este valor, se requiere un reinicio.
    4. Ruta de acceso del registro
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\everyoneincludesanonymous
  15. 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 servidor. Es una buena idea comprobar la siguiente configuración de directiva de seguridad en el complemento Editor de directivas de grupo de Microsoft Management Console:
      • Equipo\Configuración de Windows\Configuración de seguridad\Directivas Locales\opciones de seguridad
      • Seguridad de red: Base de seguridad mínima de sesión para NTLM SSP (incluyendo RPC seguro) servidores
      • Seguridad de red: Base de seguridad mínima de sesión para NTLM SSP (incluyendo RPC seguro) clientes
      Las opciones para esta configuración son los siguientes:
      • Necesita integridad de mensaje
      • Necesita confidencialidad de mensaje
      • Requerir NTLM versión 2 seguridad de sesión
      • Requerir cifrado de 128 bits
      La configuración predeterminada antes de Windows 7 no es ningún requisito. A partir de Windows 7, el valor predeterminado cambia a cifrado requieren 128 bits para mejorar la seguridad. Este valor predeterminado será no se puede conectar los dispositivos heredados que no admiten el cifrado de 128 bits.

      Estas directivas determinan los estándares de seguridad mínimos para una sesión de comunicaciones de aplicación a otra en un servidor para un cliente.

      Tenga en cuenta que aunque se describe como valores válidos, los indicadores para requerir la confidencialidad y la integridad de los mensajes no se utilizan cuando se determina la seguridad de sesión NTLM.

      Históricamente, Windows NT ha admitido las dos variantes siguientes de autenticación de desafío/respuesta para los inicios de sesión de red:
      • Desafío/respuesta de LM
      • Desafío/respuesta 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 los 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 tratarán las sesiones de red protegidas mediante NTLM. Esto afecta a las sesiones basadas en RPC autenticadas con NTLM, por ejemplo. Existen los siguientes riesgos:
      • Utilizando los antiguos métodos de autenticación de NTLMv2 facilita la comunicación a los ataques debido a los métodos más simples de hash utilizados.
      • Usa claves de cifrado inferiores a 128 bits permite a los intrusos Interrumpir comunicación mediante ataques de fuerza bruta.

Sincronización de hora

Error de sincronización de tiempo. La hora está desfasada 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 para la firma SMB

Recomendamos que instale el Service Pack 6a (SP6a) en clientes de Windows NT 4.0 que interoperen en un dominio basado en Windows Server 2003. Clientes basados en Windows 98 Segunda edición, los clientes basados en Windows 98 y clientes basados en Windows 95 deben ejecutar el cliente de servicios de directorio para poder realizar NTLMv2. Si los clientes basados en Windows NT 4.0 no tienen instalado Windows NT 4.0 SP6, o si los clientes basados en Windows 95, clientes basados en Windows 98 y clientes basados en 98SE no tienen instalado, el cliente de servicios de directorio de Windows deshabilitar SMB iniciar sesión en el dominio predeterminado configuración del controlador de dominio de directiva del controlador de la unidad organizativa y, a continuación, vincule esta directiva a todas las OU que alojan controladores de dominio.

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

Aunque no es recomendable, puede evitar que de en todos los controladores de dominio que ejecutan Windows Server 2003 en un dominio de la firma SMB. Para configurar esta opción de seguridad, siga estos pasos:
  1. Abra la directiva del controlador de dominio predeterminado.
  2. Abra la carpeta Configuración del equipo\Configuración de Windows\Configuración de seguridad\Directivas Locales\opciones de seguridad .
  3. Busque y, a continuación, haga clic en el servidor de red Microsoft: firmar digitalmente las comunicaciones (siempre) configuración de directiva y, a continuación, haga clic en deshabilitado.
Importante: esta sección, el método o la tarea contiene pasos que indican cómo modificar el registro. Sin embargo, pueden producirse problemas graves si modifica incorrectamente el registro. Por lo tanto, asegúrese de que sigue estos pasos cuidadosamente. Para una mayor protección, haga una copia de seguridad del registro antes de modificarlo. Entonces, puede restaurar el registro si se produce un problema. Para obtener más información acerca de cómo hacer copia de seguridad y restaurar el registro, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
322756 cómo hacer copia de seguridad y restaurar el registro en Windows
Como alternativa, desactive la firma SMB en el servidor modificando el registro. Para ello, siga estos pasos:
  1. Haga clic en Inicio, haga clic en Ejecutar, escriba regedit y, a continuación, haga clic en Aceptar.
  2. Busque y, a continuación, haga clic en la subclave siguiente:
    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Lanmanserver\Parameters
  3. Haga clic en la entrada enablesecuritysignature .
  4. En el menú Edición , haga clic en Modificar.
  5. En el cuadro información del valor , escriba 0y, a continuación, haga clic en Aceptar.
  6. Salga del Editor del Registro.
  7. Reinicie el equipo o detenga y reinicie el servicio servidor. Para ello, escriba los comandos siguientes en un símbolo del sistema y, a continuación, presione ENTRAR después de escribir cada comando:
    net stop servidor
    Net start servidor
Nota: La clave correspondiente en el equipo cliente está en la subclave del registro siguiente:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lanmanworkstation\Parameters
A continuación enumeran los números de código de error traducidos a códigos de estado y los mensajes de error textual que se mencionan anteriormente:
Error 5
ERROR_ACCESS_DENIED

Acceso denegado.
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 configurar la seguridad para servicios del sistema en Windows Server 2003
 
161372 cómo habilitar la firma SMB en Windows NT
 
816585 cómo aplicar plantillas de seguridad predefinidas en Windows Server 2003
 
820281 debe proporcionar las credenciales de cuenta de Windows al conectarse a Exchange Server 2003 utilizando RPC de Outlook 2003 sobre la característica de HTTP