Cuatro malentendidos típicos en el diseño del entorno de dominio de Windows Server 2008

En el entorno de red Windows
, el dominio es el núcleo. De hecho, el concepto de dominio se ha propuesto desde la era del NT y se ha mejorado continuamente. En el entorno del servidor 2008, se puede decir que es bastante perfecto. Desafortunadamente, muchos administradores de sistemas tienen algunos malentendidos típicos al diseñar la estructura del dominio por varias razones. El autor hace algunos resúmenes aquí, espero que los lectores cambien, y que nadie sea coronado.

Mito 1: La confusión de niveles funcionales no maximiza el rendimiento.

En el entorno del servidor Windows2008
, al igual que en 2003, también se adoptó un diseño de nivel funcional. El nivel de funcionalidad se toma principalmente para garantizar la compatibilidad con versiones anteriores del dominio. En el nuevo entorno de red, 2008 también tiene su propio nivel de funcionalidad para mantener la compatibilidad.

Los siguientes niveles de funcionalidad ahora son compatibles en 2008. 2000 nivel funcional local (permite que el controlador adopte las versiones 2008, 2003 y 2000 SP3, tenga en cuenta que si es un controlador de dominio 2000, debe ser parcheado con SP3), nivel funcional 2003 (permite que coexistan los controladores de dominio 2003 y 2008, y agregará La funcionalidad agregada al bosque incluye confianza transferible, nivel funcional de 2008 (todos los controladores de dominio deben tener una versión de servidor de 2008). Este nivel de funcionalidad se puede ver, principalmente para los controladores de dominio, independientemente de la versión de otros servidores o clientes. De forma predeterminada, el servidor utiliza un modo de compatibilidad degradado para realizar operaciones.

Si utiliza un nivel inferior de funcionalidad, no podrá utilizar las nuevas funciones que ofrece 2008. Si utiliza el nivel de funcionalidad de 2003, no podrá adoptar una política de contraseña precisa y no podrá implementar completamente las capacidades del dominio DS. Como puede ver, los diferentes niveles de funcionalidad realmente limitan las funciones que puede tomar un administrador del sistema. Para hacer esto, en el diseño del dominio, el analista del sistema debe confirmar las nuevas características de 2008 y confirmar que estas nuevas características deben ejecutarse al menos a ese nivel. Luego juzgue si necesita usar estas funciones de acuerdo con la situación real de la empresa. En última instancia, determinar el nivel de funcionalidad que debe tomarse. En lugar de introducir primero un nivel de funcionalidad, considere qué funciones no están disponibles. En este caso, el carro antes del caballo está al revés.

Mito 2: configurar diferentes dominios para diferentes oficinas.

Si ahora hay una empresa, tiene una oficina en Shanghai y Guangzhou, y su sede está en Beijing. En este caso, ¿necesita configurar un dominio para cada uno de Shanghai y Guangzhou? Muchos diseñadores de sistemas lo han hecho antes. De hecho, no hay tal necesidad. Especialmente después de que Microsoft propuso un controlador de dominio de solo lectura en 2008, no es necesario configurar dominios separados para algunas oficinas. De lo contrario, solo aumentará la carga de trabajo de los administradores del sistema.

De hecho, el dominio es un límite lógico inicial o el límite lógico más pequeño del entorno de red de Microsoft. Los ingenieros de sistemas administran y almacenan usuarios y computadoras desde dentro de los límites del dominio. Incluye impresoras, información de cuenta de usuario, permisos y más. Desde una perspectiva de seguridad, los dominios también actúan como límites de seguridad administrativos para objetos y contienen sus propias políticas de seguridad. En pocas palabras, significa que el dominio es la estructura lógica del objeto y puede abarcar fácilmente varias ubicaciones físicas. Esto muestra que al diseñar la estructura del dominio, la ubicación física no es el factor principal (y, a veces, debe considerarse), y depende principalmente de la estructura lógica del entorno de la aplicación empresarial.

Por lo tanto, en la práctica, no es necesario configurar múltiples dominios separados para oficinas en diferentes ubicaciones geográficas. Debemos hacer todo lo posible para evitar este tipo de vida antigua. En el entorno de aplicación de 2008, los administradores del sistema pueden usar controladores de dominio de solo lectura para resolver problemas de seguridad en la oficina o sucursal.

El autor cree que si la sucursal o la oficina de la empresa es pequeña, como solo unas pocas docenas de personas, entonces no es necesario establecer un dominio separado para ella. Por el contrario, si la sucursal de la empresa es una sola persona jurídica, o si su escala es de cientos de personas, la empresa a menudo necesita tener administradores de sistemas profesionales en esta sucursal. En este punto, por el bien de la flexibilidad de administración, se puede configurar un dominio separado para esta rama. En resumen, independientemente de la ubicación, no es razonable configurar dominios separados para la oficina debido a la ubicación geográfica.

Mito # 3: Confundir la entrega de confianza con los derechos de acceso.

Varios dominios forman un árbol de dominios. O el árbol de dominios está formado por múltiples dominios conectados por conexiones de confianza transitiva bidireccional. En esta definición, hay una palabra clave principal llamada transitiva bidireccional transitiva. Si ahora hay un número de dominio, A.com es el dominio raíz de confianza, y B.A.COM y C.A.COM son sus dos subdominios paralelos. Ahora, de acuerdo con la regla de confianza transitiva de dos vías, si el dominio A confía en B, entonces el dominio B también cree en el dominio A. Si el dominio C confía en el dominio A, entonces el dominio A también confía en el dominio B. De acuerdo con la regla de entrega, B confía en A, y A confía en C, y el dominio B también confía en C dominio.

Ahora, cuando formulo la pregunta, si el administrador del dominio A puede administrar el dominio B y el dominio C, ¿significa que el administrador del dominio B también puede administrar el dominio C? Porque B cree que A, y A cree en C, ¿por qué B puede gestionar C? De hecho, aquí se ha cometido un error conceptual. Mezclar confianza con derechos de acceso. Es como si tuvieras un amigo que confía mucho en él. Pero eso no significa que él pueda manejar sus asuntos familiares.

Por esta razón, los administradores del sistema deben tener en cuenta que, aunque en un entorno de árbol de dominios, la confianza es bidireccional y se puede pasar. Pero esto no significa que todos los usuarios tengan acceso completo. Incluso para los administradores entre dominios, la confianza solo proporciona una ruta de un dominio a otro. O bien, la confianza es un requisito previo para la gestión. Sólo sobre la base de la confianza se puede autorizar su gestión. De forma predeterminada, el sistema no permite el acceso de un dominio a otro. El administrador del dominio debe otorgar permisos a los usuarios o administradores en otro dominio para acceder a los recursos en su dominio.

Sin embargo, debe tenerse en cuenta que cada dominio del árbol de dominios comparte un esquema común y un catálogo global. Todos los dominios dentro de un árbol comparten el mismo espacio de nombres. De acuerdo con el mecanismo de seguridad predeterminado, un administrador de un subdominio tiene control relativo sobre todo su dominio. Otro subdominio o incluso el dominio raíz no pueden acceder a los recursos en su dominio sin autorización. También se puede ver en esto que la desconfianza y el acceso son fundamentalmente diferentes. Por supuesto, sobre la base de la confianza, el administrador del sistema puede otorgar a otros usuarios del dominio o del dominio raíz ciertos permisos según sea necesario para permitirles tener acceso a recursos específicos de su dominio.

En resumen, los administradores del sistema deben distinguir entre la conexión y la diferencia entre la confianza y los derechos de acceso, y no pueden confundir los dos. Luego, sobre esta base, considere si necesita establecer los derechos de acceso apropiados para los usuarios en otros dominios.

Mito 4: adopta el modo de autenticación de dominio predeterminado.

En el entorno de red de 2008, admite dos modos de autenticación de dominio predeterminados, NTLM y Kerberos. NTLM es la abreviatura de NT LAN Manager. Como puede verse en este nombre, sigue el sistema de autenticación del entorno de red NT anterior de Microsoft. Este tipo de autenticador pasa la contraseña cifrada a través de la red en forma de hash. Aunque se toma el cifrado de los comandos transmitidos en la red, todavía existen ciertos riesgos de seguridad. Cualquiera puede monitorear la información de hash que se transmite a través de la red y recopilarla antes de usar una herramienta de descifrado de terceros para descifrarla. La dificultad de craqueo depende de la complejidad del cifrado. En el caso de la producción normal, un atacante puede usar un diccionario o una tecnología de ataque de fuerza bruta para descifrar la contraseña, y el crack es solo una cuestión de tiempo.

El método de autenticación Kerberos es diferente. En pocas palabras, este método de autenticación no envía información de contraseña en la red, y sus propias medidas de cifrado son más seguras que los sistemas de autenticación de red de área local de NT. Desafortunadamente, por el bien de la compatibilidad hacia adelante, incluso en el entorno de 2008, Microsoft ha adoptado un método de autenticación NTLM relativamente inseguro de forma predeterminada. Algunos administradores de sistemas pueden no estar muy familiarizados con este aspecto. En algunas ocasiones donde los requisitos de seguridad de las aplicaciones son relativamente altos, se adopta este mecanismo de seguridad predeterminado, que ha causado muchos incidentes de seguridad.

Recomiendo que los administradores del sistema tengan que entender las diferencias entre los dos modos de autenticación. Luego, de acuerdo con la situación real de la empresa, si el requisito de nivel de seguridad es relativamente alto, entonces se debe cambiar el modo de autenticación adoptado, y se selecciona un modo de autenticación Kerberos más seguro.