ejemplo de acceso total a la intranet Actualizado: octubre de 2009 Se aplica a: Windows 7, Windows Server 2008 R2 Importante En este tema se describen las consideraciones de diseño di seño para DirectAccess en Windows Server 2008 R2. Para conocer las l as consideraciones de diseño de DirectAccess en Microsoft Forefront Unified Access Gateway (UAG), vea la guía de diseño de DirectAccess en Forefront UAG (http://go.microsoft.com/fwlink/? (http://go.microsoft.com/fwlink/? LinkId=179988) (puede estar en inglés). El acceso total a la intranet permite a los clientes de DirectAccess conectar con todos los recursos accesibles mediante el protocolo de Internet versión 6 (IPv6) dentro de la l a intranet. El cliente de DirectAccess usa el protocolo de seguridad de Internet I nternet (IPsec) para crear dos túneles túnel es cifrados a la interfaz de Internet del servidor de DirectAccess. El primer túnel, conocido como el túnel de infraestructura, permite al cliente de DirectAccess tener acceso a los servidores d el Sistema de nombres de dominio (DNS), a los controladores de dominio de Servicios de dominio domini o de Active Directory (AD DS), y a otros servidores de infraestructura i nfraestructura y de administración. El segundo túnel, conocido como el túnel de intranet, permite al cliente de DirectAccess tener acceso a recursos de la intranet. El túnel de infraestructura usa autenticación de equipo y el túnel de intranet emplea tanto autenticación de equipo como de usuario. Una vez establecido el túnel de intranet, el cliente de DirectAccess puede intercambiar tráfico con servidores de aplicaciones de la intranet. El túnel cifra este tráfico para su viaje a través de Internet. De forma predeterminada, el servidor de DirectAccess actúa como puerta de enlace de IPsec, finalizando los túneles IPsec para el cliente de DirectAccess. En la ilustración siguiente se muestra un ejemplo ejemp lo de acceso total a la intranet.
Cuando el cliente de DirectAccess se inicia y determina d etermina que está en Internet, crea los túneles al servidor de DirectAccess y comienza las comunicaciones normales con servidores de infraestructura de la intranet como los controladores de dominio de AD DS y los servidores servi dores de aplicaciones como si estuvieran conectados directamente a la intranet. Este diseño no necesita la protección de IPsec del tráfico de la intranet y estructuralmente es muy similar a los escenarios de red privada pri vada virtual (VPN) de acceso remoto actuales.
1
Para capturar un seguimiento de red para un cliente de DirectAccess
1. Abra un símbolo del sistema de nivel administrador. 2. En la ventana del símbolo del sistema, escriba el comando netsh trace start scenario=directaccess capture=yes report=yes . 3. Reproduzca el problema que tiene con DirectAccess. 4. En la ventana del símbolo del sistema, escriba el comando netsh trace stop. Netsh.exe escribe información de seguimiento en el archivo NetTrace.etl de la carpeta %TEMP%\NetTraces. Para ver el contenido de este archivo, ábralo con Network Monitor 3.3. Netsh.exe también escribe información adicional de entorno y de solución de problemas en el archivo NetTrace.cab en la carpeta %TEMP%\NetTraces.
Para capturar un seguimiento de red para WFP
1. Abra un símbolo del sistema de nivel administrador. 2. En la ventana del símbolo del sistema, escriba el comando netsh wfp capture start cab=off . 3. Reproduzca el problema que tiene con DirectAccess. 4. En la ventana del símbolo del sistema, escriba el comando netsh wfp capture end. Netsh.exe escribe información de seguimiento en el archivo Wfpdiag.xml, que puede examinar para obtener información sobre los problemas de seguridad de conexión. Puede utilizar los siguientes comandos de shell de red (Netsh) para recopilar información a la hora de solucionar problemas de DirectAccess:
netsh dnsclient show state
netsh namespace show effectivepolicy y netsh namespace show policy
netsh interface 6to4 show relay
netsh interface teredo show state
netsh interface httpstunnel show interfaces
netsh interface istatap show state y netsh interface istatap show router
netsh interface httpstunnel show interfaces
netsh advfirewall monitor show mmsa
netsh advfirewall monitor show qmsa
netsh advfirewall monitor show consec rule name=all 2
netsh advfirewall monitor show currentprofile
netsh interface ipv6 show interfaces
netsh interface ipv6 show interfaces level=verbose
netsh interface ipv6 show route
nltest /dsgetdc: /forcé
Apéndice A: Requisitos de DirectAccess Actualizado: octubre de 2009 Se aplica a: Windows 7, Windows Server 2008 R2 Importante En este tema se describen las consideraciones de diseño para DirectAccess en Windows Server 2008 R2. Para conocer las consideraciones de diseño de DirectAccess en Microsoft Forefront Unified Access Gateway (UAG), vea la guía de diseño de DirectAccess en Forefront UAG (http://go.microsoft.com/fwlink/? LinkId=179988) (puede estar en inglés). Examine esta sección para obtener información sobre los requi sitos de servidor de DirectAccess, cliente de DirectAccess e infraestructura de red. Los requisitos de hardware y software para los equipos basados en Windows 7 descritos en esta sección se aplican tanto a sistemas x86 (de 32 bits) como a sistemas x64 (64 bits).
Elemento Cliente de DirectAccess
Requisitos
Sistema operativo: Windows 7 Ultimate o posterior, Win dows 7 Enterprise o posterior, Windows Server 2008 R2 o posterior
Miembro de un dominio de Servicios de dominio de Active Directory (AD DS)
Certificado de equipo para la autenticación del protocolo de seguridad de Internet (IPsec)
Servidor de DirectAccess
Sistema operativo: Windows Server 2008 R2 o posterior
Miembro de un dominio de AD DS
Al menos dos adaptadores de red que estén conectados a Internet y a la intranet
2 direcciones públicas consecutivas de protocolo de Internet versión 4 (IPv4) configuradas en el adaptador de red de Internet (no puede estar
3
detrás de un traductor de direcciones de red [NAT])
Certificados: Certificado de equipo para autenticación de IPsec, certificado de Capa de sockets seguros (SSL) para protocolo d e Internet sobre protocolo seguro de transferencia de hipertexto (IP-HTTPS)
Si actúa como servidor de ubicación de red, debe tener instalado Internet Information Services (IIS) y un certificado SSL adicional
Nota No hay ninguna limitación integrada en cuanto al número de conexiones de DirectAccess simultáneas que un servidor de DirectAccess puede admitir. Active Directory
Se debe implementar al menos un dominio de Active Directory con un controlador de dominio basado en Windows Server 2008 R2 o Windows Server 2008 como mínimo (un controlador de dominio y un catálogo global compatibles con protocolo de Internet versión 6 [IPv6]). No se necesitan niveles funcionales de dominio o de bosque de Windows Server 2008 R2. No se admiten grupos de trabajo. Para obtener más información sobre cómo instalar Active Directory, vea la página relativa a la guía paso a paso para la instalación y eliminación de AD DS (http://go.microsoft.com/fwlink/? Linkid=139657) (puede estar en inglés).
Directiva de grupo
Es necesaria para la administración centralizada y la implementación de la configuración de DirectAccess. El Asistente para configuración de DirectAccess crea un conjunto de configuraciones y objetos de directiva de grupo para los clientes de DirectAccess, el servidor de DirectAccess y los servidores seleccionados.
Infraestructura de clave pública (PKI)
Es necesaria para emitir certificados de equipo para autenticación y, opcionalmente, certificados de mantenimiento cuando se usa Protección de acceso a redes (NAP). No se necesitan certificados externos. Para obtener más información sobre la configuración de una PKI con Se rvicios de certificados de Active Directory (AD CS), vea el tema acerca de los Servicios de certificados de Active Directory (http://go.microsoft.com/fwlink/?Linkid=106710) (puede estar en inglés).
Servidor del Sistema de nombres de dominio (DNS)
Al menos uno que ejecute Windows Server 2008 R2, Windows Server 2008 con la revisión Q958194 (http://go.microsoft.com/fwlink/?LinkID=159951), Windows Server 2008 SP2 o posterior o un servidor DNS de terceros que admita intercambios de mensajes DNS a través de ISATAP (Intra-Site Automatic Tunnel Addressing Protocol).
4
Apéndice B: Revisar los conceptos clave de DirectAccess Actualizado: octubre de 2009 Se aplica a: Windows 7, Windows Server 2008 R2 Importante En este tema se describen las consideraciones de diseño para DirectAccess en Windows Server 2008 R2. Para conocer las consideraciones de diseño de DirectAccess en Microsoft Forefront Unified Access Gateway (UAG), vea la guía de diseño de DirectAccess en Forefront UAG (http://go.microsoft.com/fwlink/? LinkId=179988) (puede estar en inglés). La solución DirectAccess emplea una combinación de conectividad de un extremo a otro del protocolo de Internet versión 6 (IPv6), protección del tráfico de la intranet con el protocolo de seguridad de Internet (IPsec), separación del tráfico del Sistema de nombres de dominio (DNS) con la Tabla de directivas de resolución de nombres (NRPT) y detección de la ubicación de red que los clientes de DirectAccess usan para determinar cuándo están en la intranet. En l as próximas secciones se describe el rol que desempeñan estas tecnologías para proporcionar a los clientes de DirectAccess acceso transparente a los recursos de la intranet. IPv6 IPv6 es la nueva versión del nivel de Red de la pila de protocolos TCP/IP que está diseñada para reemplazar al protocolo de Internet versión 4 (IPv4), que es ampliamente usado hoy en día en las intranets y en Internet. IPv6 proporciona un espacio de direcciones suficientemente grande para permitir el direccionamiento de un extremo a otro de los nodos en Internet por IPv6 y, con las tecnologías de transición IPv6, de los nodos en Internet por IPv4. DirectAccess emplea esta capacidad para proporcionar direccionamiento de un extremo a otro de los clientes de DirectAccess en Internet por IPv4 o IPv6 a los equipos de una intranet. Puesto que en la actualidad la mayoría de Internet se basa en IPv4 y muchas organizaciones no han implementado direccionamiento y enrutamiento IPv6 nativo en sus intranets, DirectAccess usa tecnologías de transición IPv6 para proporcionar conectividad IPv6 a tr avés de estas redes solo IPv4. Teredo, 6to4, protocolo de Internet sobre protocolo seguro de transferencia de hipertexto (IP-HTTPS) e ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) son ejemplos de tecnologías de transición IPv6. Estas tecnologías le permiten usar IPv6 en Internet por IPv4 y en la intranet solo IPv4. Las tecnologías de transición IPv6 pueden simplificar y reducir los costos d e una implementación de IPv6. Conectividad IPv6 en Internet por IPv4 Para enviar paquetes IPv6 en Internet por IPv4, un cliente de DirectAccess puede usar 6to4, Teredo o IP-HTTPS. Si el cliente de DirectAccess tiene asignada una di rección IPv4 pública, usará 6to4. Si tiene asignada una dirección IPv4 privada, empleará Teredo. Si el cliente de DirectAccess no puede conectar con el servidor de DirectAccess mediante 6to4 o Teredo, usará IP-HTTPS. 6to4
6to4, definido en RFC 3056, es una tecnología de transición IPv6 que proporciona conectividad IPv6 a través de Internet por IPv4 para hosts o sitios que tienen una dirección IPv4 pública. Para obtener más información, vea la página relativa a las tecnologías de transición IPv6 (http://go.microsoft.com/fwlink/?Linkid=117205) (puede estar en inglés). Teredo
Teredo, definido en RFC 4380, es una tecnología de transición IPv6 que proporciona conectividad IPv6 a través de Internet por IPv4 para hosts que están situados detrás de un dispositivo de traducción de direcciones de red (NAT) IPv4 y que tienen asignada una dirección IPv4 privada. Para obt ener más información, vea la página relativa a la información general sobre Teredo (http://go.microsoft.com/fwlink/?Linkid=157322) (puede estar en inglés).
5
IP-HTTPS
IP-HTTPS es un nuevo protocolo para Windows 7 y Windows Server 2008 R2 que permite que los hosts situados detrás de un firewall o un servidor proxy web establezcan conectividad tunelizando paquetes IPv6 dentro de una sesión HTTPS basada en IPv4. HTTPS se usa en lugar de HTTP, por lo que los servidores proxy web no intentarán examinar el flujo de datos y finalizar la conexión. Normalmente, IP-HTTPS solo se usa si el cliente no puede conectar con el servidor de DirectAccess mediante los demás métodos de conectividad IPv6 o si se ha configurado el túnel forzado. Para obtener detalles sobre IP-HTTPS, vea la página sobre la especificación del protocolo de túnel IP sobre HTTPS (IP-HTTPS) (http://go.microsoft.com/fwlink/? Linkid=157309) (puede estar en inglés). Nota El laboratorio de prueba de DirectAccess (http://go.microsoft.com/fwlink/?Linkid=150613) demuestra la conectividad de DirectAccess en una subred de Internet simulada usando 6to4, Teredo e IP-HTTPS. Conectividad IPv6 a través de una intranet solo IPv4 ISATAP, definido en RFC 4214, es una tecnología de transición IPv6 que proporciona conectividad IPv6 entre hosts IPv6/IPv4 a través de una intranet solo IPv4. ISATAP se puede usar para que DirectAccess proporcione conectividad IPv6 a los hosts ISATAP en toda la intranet. Para obtener más información, vea la página relativa a l as tecnologías de transición IPv6 (http://go.microsoft.com/fwlink/?Linkid=117205) (puede estar en inglés). Nota ISATAP también puede usarse para proporcionar conectividad IPv6 cuando el cliente se encuentra en una ubicación remota. Las implementaciones de ISATAP pueden conectarse a Internet por IPv6 o usar 6to4 para transferir tráfico IPv6 a través de Internet por IPv4. El laboratorio de prueba de DirectAccess (http://go.microsoft.com/fwlink/?Linkid=150613) usa ISATAP en la intranet simulada.
IPsec IPsec es un marco de estándares abiertos para garantizar la privacidad y seguridad de las comunicaciones a través de redes del protocolo de Internet (IP) mediante el uso de servicios de seguridad criptográfica. IPsec proporciona una protección exhaustiva contra ataques mediante seguridad descentralizada. Los únicos equipos que deben conocer la protección de IPsec son el remitente y el receptor de la comunicación. IPsec permite proteger la comunicación entre g rupos de trabajo, equipos de red de área local, servidores y clientes de dominio, sucursales (que pueden estar separadas físicamente), extranets y clientes móviles. La protección de IPsec se puede usar en dos modos distintos: modo de transporte y modo de túnel. El modo de transporte está diseñado para proteger una carga de paquete de protocolo de Internet (IP). El modo de túnel está diseñado para proteger todo un paquete IP. Para obtener más información, vea la página relativa a los tipos de protocolo IPsec (http://go.microsoft.com/fwlink/?Linkid=157319) (puede estar en inglés). DirectAccess usa la configuración de IPsec en forma de reglas d e seguridad de conexión en el complemento Firewall de Windows con seguridad avanzada y en el contexto advfirewall de la herramienta de línea de comandos de shell de red (Netsh) para la autenticación del mismo nivel, integridad de datos y confidencialidad de datos (cifrado) de las conexiones de DirectAccess. Es posible aplicar varias reglas a un equipo simultáneamente y cada una de ellas proporciona una función diferente. El resultado del funcionamiento conjunto de todas estas reglas es un cliente de DirectAccess que puede tener protegidas las comunicaciones con los servidores de la intranet y el servidor de 6
DirectAccess, cifrando el tráfico enviado a través de Internet y, opcionalmente, protegiendo el tráfico de un extremo a otro. Nota Windows Server 2003 y las versiones anteriores de Windows Server no son totalmente compatibles con el uso de IPsec con IPv6. Los recursos compatibles con IPv6 en servidores que ejecutan Windows Server 2003 solo estarán disponibles para clientes de DirectAccess si usa el modo de acceso total a la intranet. Los recursos solo IPv4 en servidores que ejecutan Windows Server 2003, incluidas la mayoría de las aplicaciones integradas y los servicios del sistema, necesitan que esté disponible un traductor IPv6/IPv4 y una puerta de enlace DNS IPv6/IPv4 en los clientes de DirectAccess. Cifrado Cuando un cliente de DirectAccess envía datos a la intranet, el tráfico se cifra a través de Internet. Para los modelos de acceso total a la intranet y al servidor seleccionado, varias reglas de seguridad de conexión configuradas en el cliente de DirectAccess definen la configuración de IPsec del modo de túnel para la comunicación entre el cliente de DirectAccess y la intranet:
La primera regla para el túnel de infraestructura exige autenticación con un certificado de equipo y cifra el tráfico con IPsec y la Carga de seguridad encapsuladora (ESP). Esta regla ofrece comunicación protegida con controladores de dominio de Active Directory, servidores DNS y otros recursos de la intranet antes de que el usuario haya iniciado sesión.
La segunda regla para el túnel de intranet exige autenticación con un certificado de equipo y credenciales de Kerberos basadas en el usuario. Esta r egla proporciona comunicación protegida a los recursos de la intranet después de que el usuario haya iniciado sesión.
Para los modelos de acceso de extremo a perímetro y al servidor seleccionado, la finalización de los túneles IPsec entre el cliente de DirectAccess y la intranet la realiza el componente Puerta de enlace IPsec en el servidor de DirectAccess. Este componente se puede encontrar en un servidor diferente con un adaptador de red de descarga de IPsec para aumentar el rendimiento. Integridad de datos La integridad de datos permite al homólogo IPsec receptor comprobar criptográficamente que el paquete no se ha modificado mientras estaba e n tránsito. Al cifrar datos con IPsec, también se proporciona integridad de datos. Es posible especificar la integridad de datos sin cifrado. Esto p uede resultar útil para mitigar el riesgo de ataques de suplantación de identidad y de tipo "man-in-themiddle", y permite garantizar que los clientes de DirectAccess se conectan a los servidores correspondientes. Nota Cuando se transmiten datos confidenciales, únicamente se debe usar IPsec con integridad de datos cuando también se implementa algún otro tipo de cifrado. Es posible tener integridad de datos de un extremo a otro usando reglas del modo de transporte y cifrado de extremo a perímetro para las reglas del modo de túnel, que es como funciona el modelo de acceso al servidor seleccionado. DirectAccess proporciona integridad de datos mediante el uso de configuraciones IPsec de los modo de túnel y de transporte. Estas configuraciones se pueden aplicar a servidores y clientes de DirectAccess o a servidores de aplicaciones, y proporcionan integridad de datos exigiendo ESP-NULL (recomendado) o un Encabezado de autenticación (AH) para las comunicaciones protegidas con IPsec. Es posible que ciertos dispositivos de infraestructura de red o soluciones de supervisión e inspección de tráfico no puedan analizar los paquetes con un encabezado ESP o AH de IPsec. En este caso, puede usar la 7
autenticación con encapsulación nula para realizar la autenticación del mismo nivel de IPsec, pero no para la integridad de datos por paquete. Separación del tráfico DNS Para separar el tráfico de Internet del tráfico de la intranet para DirectAccess, Windows 7 y Windows Server 2008 R2 incluyen la NRPT, una nueva característica que permite definir servidores DNS por espacio de nombres DNS, en lugar de por interfaz. La NRPT almacena una lista de reglas. Cada regla define un espacio de nombres DNS y una configuración que definen el comportamiento del cliente DNS para ese espacio de nombres. Cuando un cliente de DirectAccess está en Internet, se compara cada solicitud de consulta de nombres con las reglas de espacio de nombres almacenadas en la tabla NRPT. Si se encuentra una coincidencia, la solicitud se procesa d e acuerdo con la configuración de la regla de la tabla NRPT. La configuración determina a qué servidores DNS se enviará la solicitud. Si una solicitud de consulta de nombres no coincide con un espacio de nombres enumerado en la tabla NRPT, se envía a los servidores DNS configurados en las opciones de TCP/IP para la interfaz de red especificada. Para un cliente remoto, normalmente serán los servidores DNS de Internet, tal como se configuraron mediante el proveedor de acceso a Internet (ISP). Para un cliente de DirectAccess de la intranet, normalmente serán los servidores DNS de la intranet según se hayan configurado mediante el protocolo de configuración dinámica de host (DHCP). Los nombres de una sola etiqueta, como http://internal, generalme nte tendrán configurados sufijos de búsqueda DNS anexados al nombre antes de la comprobación con la tabla NRPT. Si no hay sufijos de búsqueda DNS configurados y el nombre de una sola etiqueta no coincide con ninguna otra regla de nombre de una sola etiqueta en la tabla NRPT, la solicitud se enviará a los servidores DNS especificados en la configuración de TCP/IP del cliente. Los espacios de nombres, como .internal.contoso.com, se agregan a la tabla NRPT seguidos de las direcciones IPv6 de los servidores DNS a los que deben dirigirse las solicitudes que coinciden con dicho espacio de nombres. Si se especifica una dirección IP para el servidor DNS, todas las solicitudes DNS se enviarán directamente al servidor DNS a través de la conexión de DirectAccess. No es necesario especificar seguridad adicional para esta configuración. Sin embargo, si se especifica un nombre para el servidor DNS (como dns.contoso.com) en la tabla NRPT, ese nombre debe poder resolverse públicamente cuando el cliente consulte a los servidores DNS especificados en la configuración de TCP/IP. Con el fin de evitar que un atacante secuestre esta solicitud de consulta de nombres externa e inserte una respuesta malintencionada, se recomienda encarecidamente habilitar la protección IPsec para los intercambios de mensajes DNS en esta configuración. La tabla NRPT permite a los clientes de DirectAccess usar servidores DNS de la intranet para l a resolución de nombres (no se necesitan servidores DNS dedicados). DirectAccess está diseñado para evitar la exposición del espacio de nombres de la intranet en Internet. Exenciones de la tabla NRPT Hay algunos nombres que deben tratarse de manera distinta a los demás con respecto a la resolución de nombres; estos nombres no deben resolverse con servidores DNS de la i ntranet. Para asegurarse de que estos nombres se resuelven con servidores DNS configurados por interfaz, debe agregarlos como exenciones de la NRPT. Si no se especifican direcciones de servidor DNS en la regla de la tabla NRPT, la regla será una exención. Si un nombre DNS coincide con una regla de la tabla NRPT que no contiene direcciones de servidores DNS o no coincide con ninguna regla de la tabla NRPT, el cliente de DirectAccess enviará la consulta de nombre a los servidores DNS configurados por interfaz. Si alguno de los siguientes servidores tiene un sufijo de nombre que coincide con una regla de la tabla NRPT para el espacio de nombres de la intranet, dicho nombre de servidor debe ser una exención de la tabla NRPT: 8
Servidores de ubicación de red
Puntos de distribución de lista de revocación de certificados (CRL) de la intranet
Servidores de actualizaciones de mantenimiento del sistema
Estos servidores siempre se deben resolver con servidores DNS configurados por interfaz. Nota El Asistente para configuración de DirectAccess del laboratorio de prueba de DirectAccess (http://go.microsoft.com/fwlink/?Linkid=150613) crea dos reglas en la NRPT: una regla de espacio de nombres para corp.contoso.com con la dirección IPv6 del servidor DNS de la intranet y una regla de exención para nls.corp.contoso.com. Puede ver las reglas de la NRPT configuradas con Directiva de grupo desde CLIENT1 si ejecuta el comando netsh namespace show policy en un símbolo del sistema. Puede ver las reglas activas de la NRTP con el comando netsh namespace show effectivepolicy. Detección de ubicación de red Los clientes de DirectAccess usan la detección de ubicación de r ed para determinar si están en la intranet intentando tener acceso a un servidor de ubicación de red. Si el cliente de DirectAccess puede tener acceso correctamente a un localizador uniforme de recursos (dirección URL) basado en el protocolo seguro de transferencia de hipertexto (HTTPS) en el servidor de ubicación de red, determina que está en la intranet y quita las reglas de DirectAccess de la tabla NRPT. El servidor de ubicación de red Un servidor de ubicación de red es un servidor web de intranet que hospeda una dirección URL basada en HTTPS. El servidor de DirectAccess puede ser el servidor de ubicación de red, pero se recomienda encarecidamente usar un servidor web diferente con alta disponibilidad. Este servidor web no tiene por qué estar dedicado a ser servidor de ubicación de red. Puesto que el comportamiento del cliente de DirectAccess depende de la respuesta del servidor de ubicación de red, es fundamental asegurarse de que este sitio web tenga alta disponibilidad y esté disponible desde cada sitio de sucursal remoto. E s posible que las ubicaciones de sucursales necesiten un sitio web de ubicación de red dedicado diferente en cada ubicación de sucursal con el fin de garantizar el acceso al sitio web, incluso cuando se detecte un error de vínculo. Funcionamiento de la detección de ubicación de red Cuando cliente de DirectAccess se inicia o experimenta un evento de cambio de red (como un cambio en el estado del vínculo o una nueva dirección IP), agrega las regl as de DirectAccess a la tabla NRPT. A continuación, el cliente de DirectAccess intenta resolver el nombre de dominio completo (FQDN) de la dirección URL para el servidor de ubicación de red, que está almacenado en la configuración de Directiva de grupo Configuración del equipo/Directivas/Plantillas administrativas/Red/Indicador de estado de conectividad de red/Dirección URL para det erminar la ubicación del dominio. Puesto que la tabla NRPT tiene reglas de DirectAccess activas, este FQDN debe coincidir con una regla de exención o con ninguna regla de la tabla NRPT, de forma que el cliente de DirectAccess pueda usar la resolución de nombres normal y los servidores DNS configurados por interfaz. Después de resolver el FQDN, el cliente de DirectAccess intenta conectarse con la dirección URL basada en HTTPS del servidor de ubicación de red, que incluye autenticación y comprobación basada en Capa de sockets seguros (SSL) del certificado del servidor ofrecido por el servidor de ubicación de red. Para autenticar el acceso a la dirección URL del cliente de DirectAccess, use autenticación anónima. El servidor de ubicación de red no debe necesitar ningún tipo de credenciales de usuario para la autenticación o autorización. La comprobación del certificado incluye validar el certificado y comprobar que no se ha revocado teniendo acceso a la ubicación de CRL definida en el certificado SSL del servidor 9
de ubicación de red. Cuando el cliente de DirectAccess tiene acceso correctamente a la dirección URL basada en HTTPS del servidor de ubicación de red, determina que está en la intranet. A continuación, el cliente de DirectAccess quita las reglas de DirectAccess de la tabl a NRPT activa y usa servidores DNS configurados por interfaz para resolver todos los nombres. Para obtener más información, vea Network Location Detection. Nota Igual que la dirección URL para el servidor de ubicación de red, el FQDN de la dirección URL o la ruta de acceso de la convención de nomenclatura universal (UNC) del punto de distribución de CRL debe coincidir con una regla de exención o con ninguna regla de la tabla NRPT para que el cliente de DirectAccess pueda usar la resolución de nombres normal y los servidores DNS de la intranet configurados por la interfaz para resolver el nombre. Si el cliente de DirectAccess no puede resolver el FQDN para el punto de distribución de CRL, se produce un error en la detección de la ubicación de la intranet. El laboratorio de prueba de DirectAccess (http://go.microsoft.com/fwlink/?Linkid=150613) utiliza APP1, un servidor de aplicaciones diferente, como servidor de ubicación de red y la dirección URL de ubicación de red https://nls.corp.contoso.com. El certificado SSL de APP1 tiene el punto de distribución de CRL http://crl.contoso.com/crld/corp-DC1-CA.crl, que para simplificar la configuración está hospedado en DA1, el servidor de DirectAccess. Para demostrar la detección de ubicación de red, haga lo siguiente: 1. Conecte CLIENT1 a la subred de Internet. 2. Abra un símbolo del sistema. 3. En la ventana Símbolo del sistema, ejecute el comando netsh dnsclient show state. Observe que en el campo Ubicación de la máquina se muestra Fuera de la red corporativa. 4. Ejecute el comando netsh namespace show effectivepolicy. Observe que hay dos reglas activas de la NRPT: una regla de espacio de nombres para corp.contoso.com y una regla de exención para n ls.corp.contoso.com. 5. Desconecte CLIENT1 de la subred de Internet y conéctelo a la subred Corpnet. 6. En la ventana Símbolo del sistema, ejecute el comando netsh dnsclient show state. Observe que en el campo Ubicación de la máquina se muestra Dentro de la red corporativa. 7. Ejecute el comando netsh namespace show effectivepolicy. Observe que ahora no hay ninguna regla activa de la NRPT.
10
