Comunicaciones
Inicie una sesión en Outlook Web Access con tarjetas inteligentes
Victor Akinnagbe and Ted Dressel and Jason Opdycke
Resumen:
- Autenticación en dos fases
- Delegación limitada de Kerberos
- ISA Server y Exchange
Los empleados móviles presentan un desafío exclusivo para la seguridad en las organizaciones de TI. Los usuarios remotos necesitan acceso seguro a los datos y servicios como, por ejemplo, el correo electrónico. Sin embargo, lamentablemente la realidad es que la mayoría de
los vínculos vulnerables en la cadena de seguridad implican contraseñas deficientes, software malintencionado (tales como los registradores de pulsaciones de tecla) y los virus en los equipos remotos que tienen acceso a los recursos internos de la organización.
Una manera de aumentar la seguridad en este entorno móvil es quitar uno de esos vínculos vulnerables: las contraseñas (aunque la idea de permitir el acceso a una cuenta sin una contraseña para autenticación puede parecer molesta). Una técnica principal para eliminar los problemas asociados con contraseñas se conoce como la autenticación en dos fases (o a veces conocida como autenticación multifase). En lugar de depender de un método único, como una contraseña, para habilitar el acceso, la autenticación en dos fases exige el uso de métodos de autenticación adicionales, entre los que se incluyen una combinación de nombre de usuario y contraseña, un dispositivo físico tal como una tarjeta inteligente o un identificador biométrico tal como una huella dactilar.
Si tiene usuarios remotos, normalmente tendrá que abrir el firewall un poco para permitir el acceso remoto a la red corporativa. Un firewall estándar le proporciona una mitigación básica del riesgo al ofrecer un aislamiento de nivel de red entre las redes internas y externas (consulte la figura 1). Para obtener una seguridad adicional, los puertos se bloquean, y es necesario obtener una comunicación con un dispositivo en la red interna, los puertos se reenvían entonces al lugar correcto. Estas técnicas ofrecen una protección importante en el nivel de red, pero ahora se han hecho necesarias varias capas de seguridad de red debido a la siempre creciente sofisticación de los ataques.
Figura 1** Firewall estándar con puertos bloqueados o reenviados **(Hacer clic en la imagen para ampliarla)
Puesto que los servicios corporativos más comunes que los empleados móviles usarán con mayor frecuencia son el correo electrónico y la mensajería, seguramente la infraestructura de Exchange pasa a ser más importante que nunca. Proporcionar a los usuarios acceso al correo electrónico a través de Outlook® Web Access (OWA) es una manera de ofrecer servicios seguros a empleados móviles. Ofrecer una autenticación en dos fases más segura para OWA mediante tarjetas inteligentes es otro paso clave. En este artículo, echamos un vistazo más detenido a los problemas de configuración e instalación que debería tener en cuenta a la hora de permitir su propia implementación de OWA habilitada con tarjetas inteligentes.
Mejor que un firewall
La implementación de Microsoft® Internet Security and Acceleration (ISA) Server 2006 en la red puede simplificar la tarea de la apertura de la red a usuarios remotos de una manera más segura. ISA Server 2006 incluye características de mejora de la seguridad, como por ejemplo, redes privadas virtuales (VPN) habilitada con tarjeta inteligente, autenticación LDAP (Protocolo ligero de acceso a directorios) a Active Directory® y delegación restringida de Kerberos. ISA Server es algo diferente de lo que se puede considerar tradicionalmente como un firewall. Ofrece varios niveles de seguridad no sólo al funcionar en el nivel de red, y puede hacer esto en lugar del hardware de firewall estándar o en conjunto con él, sino también al ofrecer características de seguridad adicionales que no suelen ser compatibles con firewalls tradicionales, tales como filtros de aplicaciones. ¿Desea impedir que un usuario use el método HTTP POST en un sitio web hospedado concreto? ¿Desea obligar el cumplimiento de RFC en mensajes SMTP antes de que toquen Exchange Server? ¿Desea inspeccionar paquetes HTTP cifrados de Nivel de sockets seguros (SSL)? ISA Server puede administrar todas estas tareas y más para asegurarse de que sólo el tráfico limpio y filtrado se reenvía a la red perimetral o red interna.
Las sesiones SSL son un problema para los firewalls estándar. Cuando los paquetes atraviesan el firewall, permanecen cifrados (lo que significa que SSL funciona correctamente). Así, si una aplicación como OWA se publica a través de firewall de hardware o software mediante SSL, no hay realmente ningún tipo de inspección apreciable que el firewall estándar pueda realizar distinta a la inspección de paquete activa. Simplemente, la apertura y el reenvío de los puertos pueden dejar expuesta una importante área de ataque. Puesto que no se está produciendo ninguna inspección verdadera en el perímetro, los paquetes sin inspeccionar y no autenticados podrían dirigirse a la red interna.
ISA Server 2006 puede actuar como un extremo SSL para clientes HTTP, garantizando que únicamente el tráfico autenticado alcanza el servidor Exchange publicado. ISA Server admite una característica útil denominada puente SSL. Típicamente, un paquete está cifrado por un cliente que se comunica con ISA Server mediante una sesión SSL estándar. Con el puente SSL, ISA Server puede poner fin al cifrado SSL de forma local, inspeccionar el paquete ahora sin cifrar, autenticar el usuario a Active Directory (si fuera necesario), volver a cifrar el paquete mediante SSL y pasar el paquete cifrado al servidor de Exchange adecuado (consulte la figura 2). Mediante esta técnica, el puente SSL mitiga los ataques ocultos dentro de una sesión SSL que, para un firewall que desconoce las aplicaciones, no parecerían más que objetos BLOB cifrados de datos.
Figura 2** ISA Server toma una vista de nivel de aplicación del tráfico **(Hacer clic en la imagen para ampliarla)
El tráfico previamente autenticado que alcanza el servidor es un punto importante que se debe tener en cuenta cuando se habla de la delegación restringida de Kerberos. En un firewall estándar, los puertos simplemente se reenvían al servidor de Exchange y el propio servidor front-end es responsable de realizar las tareas de autenticación frente a lo que podrían ser usuarios malintencionados. Cuando se requiere autenticación, ISA Server puede ponerse en contacto directamente con Active Directory y solicitar las credenciales en nombre del usuario. Si el usuario está autenticado correctamente, ISA Server reenviará el mensaje al servidor Exchange front-end. El servidor front-end ya no tiene que autenticar solicitudes aleatorias de usuarios desconocidos y se puede usar únicamente para enviar por proxy solicitudes a los servidores back-end. ISA Server 2006 también puede usar la delegación restringida de Kerberos para habilitar el acceso basado en certificados a tecnologías como Windows SharePoint Services y Exchange ActiveSync.
Exchange Server 2003 incluía compatibilidad con la autenticación basada en Kerberos entre los servidores front-end y back-end para inicios de sesión de OWA. (Está usando IPsec para proteger el tráfico del cliente, ¿no es así?) Exchange Server también admite la autenticación Kerberos a servidores de buzón en clúster.
Habilitación de la autenticación mediante tarjeta inteligente
La implementación de la autenticación basada en tarjetas inteligentes para OWA ha sido un desafío. Sin embargo, se desarrolló una solución basada en la característica de delegación restringida de Kerberos ahora disponible en ISA Server 2006. La solución permite a un usuario enviar credenciales mediante un certificado para autenticar correctamente a OWA. La delegación restringida de Kerberos se incluye como una mejora bienvenida en comparación con la compatibilidad de la delegación de Kerberos en Windows® 2000, que usaba la delegación sin restricciones. La función restringida de Kerberos es más segura y limita el riesgo potencial de ataques sofisticados que usan la suplantación.
En el escenario habilitado con tarjeta inteligente, ISA Server 2006 se pone en contacto con Active Directory para autenticar el usuario, ya que este último no tiene el acceso enrutable a un centro de distribución de claves (KDC) de la red externa. ISA Server somete a Active Directory la asignación de certificado-usuario para autenticar el usuario y adquiere entonces los respectivos vales de Kerberos según el nombre principal del usuario (UPN). En este caso, ISA Server ofrece la funcionalidad de delegación restringida de Kerberos a un servidor Exchange front-end mediante el filtrado de nivel de aplicación y los servicios de proxy inverso. Si la delegación se intenta sin un proxy inverso, el riesgo aumentado de vulnerabilidades podría afectar a la integridad de la red o del dominio de Active Directory.
Tanto Exchange Server 2003 como Exchange Server 2007 permiten la autenticación básica e integrada. Sin embargo, tiene que aplicar una actualización de software a Exchange Server 2003 para que funcione la autenticación basada en tarjetas inteligentes a OWA. (Para obtener más información, consulte el artículo "Descripción de la nueva característica de Exchange Server 2003 que admite la autenticación mediante tarjeta inteligente a Outlook Web Access".) Debe tener un dominio en el modo funcional nativo de Windows Server® 2003, todo los servidores de Exchange Server 2003 implicados deben tener SP2 o versiones posteriores aplicadas y necesita un servidor ISA Server 2006 que actúe como un proxy inverso para el sitio de OWA.
Después de que instale la actualización de software y configure los servidores ISA Server y Exchange, los usuarios pueden autenticar una sesión de OWA mediante tarjetas inteligentes. La figura 3 muestra el flujo de eventos necesarios para la autenticación mediante tarjeta inteligente. Un usuario comienza por abrir el sitio de OWA en Internet Explorer® (1). De hecho, el usuario en realidad se conecta a ISA Server y se le solicita un certificado en lugar de un nombre de usuario y contraseña para iniciar la sesión de OWA. El certificado adecuado se almacena en la tarjeta inteligente para la que el usuario necesita un PIN.
Figura 3** Autenticación de OWA con una tarjeta inteligente **(Hacer clic en la imagen para ampliarla)
La validación de certificados (2) se controla mediante una lista de certificados revocados (CRL) o una solicitud de Protocolo de estado de certificados en línea (OCSP), según la configuración de ISA Server y otro software instalado. ISA Server realiza una solicitud a un controlador de dominio (DC) para comprobar las credenciales del usuario. Si se produce un error en la solicitud, ISA Server ofrece una página de error al usuario y ninguna solicitud llega al servidor Exchange front-end.
Después de que se comprueban las credenciales, se genera el vale de Kerberos y la solicitud se pasa al servidor Exchange front-end usando la autenticación integrada (3). Cuando el servidor Exchange front-end recibe la solicitud, valida el vale de Kerberos y encuentra el servidor back-end de buzones del usuario (4).
El servidor front-end solicita un vale de Kerberos para el servidor back-end adecuado a través de la delegación restringida de Kerberos y envía por proxy la solicitud de buzón al servidor back-end mediante la autenticación integrada (5). El servidor back-end atiende la solicitud (6) y los datos del buzón se devuelven al servidor Exchange front-end (7). Los datos HTML para la página de OWA se pasan a ISA Server (8) que, a su vez, los pasa de nuevo al equipo cliente (9).
Configuración del entorno de Exchange
El artículo de Knowledge Base que se mencionó anteriormente describe la actualización de software para Exchange Server 2003 e incluye información que le guiará por el proceso de habilitación de la delegación restringida de Kerberos mediante ISA Server 2006 y Exchange Server 2003.
La acción principal que la actualización de software habilita es la automatización de la delegación restringida de Kerberos desde el servidor Exchange front-end a los servidores back-end respectivos. La actualización no automatizará el proceso de delegación restringida de Kerberos desde ISA Server al servidor front-end, ya que ISA Server no forma parte de la organización de Exchange. Esa delegación tendrá que habilitarse manualmente desde cada sesión de ISA Server a cada servidor Exchange front-end.
La actualización de software agrega una nueva ficha en el Administrador del sistema de Exchange (ESM) que permite designar un servidor Exchange front-end como un KCD-FE (consulte la figura 4) que, a su vez, permite que ese servidor se rellene en la ficha de la delegación de los servidores Exchange back-end respectivos.
Figura 4** Habilitación de la delegación restringida de Kerberos **
La nueva interfaz de usuario también permite especificar en las propiedades del grupo administrativo las credenciales que se deben usar para rellenar el atributo msDS-AllowedToDelegateTo (A2D2), tal como se muestra en la figura 5. Éste es el atributo responsable de la delegación restringida de Kerberos.
Figura 5** Establecimiento de la cuenta que controla la delegación **
Al respetar el principio de privilegio mínimo, puede usar una cuenta de usuario estándar y concederle la capacidad de delegar usuarios y equipos mediante un objeto de directiva de grupo (GPO). Después de que a la cuenta se le haya concedido este permiso elevado, se puede usar como una cuenta de servicio para automatizar el proceso de delegación restringida de Kerberos para el grupo administrativo respectivo.
Lleve a cabo los pasos apropiados para asegurarse de que ningún usuario malintencionado pueda poner en peligro la cuenta del servicio de delegación restringida de Kerberos. Aunque la cuenta no sea un administrador de dominio, el acceso a ella podría dar lugar a sofisticados ataques que aprovechan la delegación de Kerberos. Puesto que la cuenta tendrá la capacidad de establecer nuevas asociaciones de Kerberos, debería usarse con cuidado. Tome las precauciones necesarias para garantizar la seguridad y la integridad de dicha cuenta: una contraseña larga y compleja, auditoría aumentada, técnicas de inhabilitación de cuentas, etc.
La actualización de software de Exchange también crea un cambio muy importante a la interfaz de ESM respecto a la autenticación integrada. Anteriormente en Exchange Server 2003, cuando un servidor se designaba como servidor front-end, la opción para habilitar la Autenticación integrada de Windows para los directorios virtuales HTTP (bajo el servidor virtual HTTP) aparecía atenuada (consulte la figura 6).
Figura 6a** La actualización habilita la autenticación integrada **
Figura 6b** La actualización habilita la autenticación integrada **
Esto se produce porque la autenticación integrada no era compatible en servidores Exchange front-end debido a problemas técnicos como, por ejemplo, el hecho de que los servidores proxy interrumpieron las sesiones NTLM, los usuarios que emplean la autenticación Kerberos necesitaban una conexión a Active Directory y los usuarios de Internet generalmente no formaban parte del dominio. La actualización descrita en el artículo de Knowledge Base anterior quita estas limitaciones. Con la actualización instalada, simplemente puede ir al directorio virtual y activar la casilla para la Autenticación integrada de Windows como el mecanismo para comprobar las credenciales de usuario. Cuando se activa, establece un atributo denominado msexchAuthenticationFlags en el objeto de directorio virtual de Active Directory (puede verlo si usa el complemento de Adsiedit.msc para Microsoft Management Console).
Los usuarios que comprueban el correo a través de OWA pueden saber el nombre de sus servidor Exchange back-end y pueden conectarse a ellos usando la autenticación integrada mientras que se encuentran en la intranet corporativa. La diferencia en la experiencia de usuario con la autenticación integrada es que, puesto que ha iniciado una sesión en la red, no se le pide un nombre de usuario y una contraseña porque Internet Explorer le autenticará al sitio web de manera automática. Esto es fantástico para los usuarios que se encuentran en la red corporativa, pero los usuarios externos (y los usuarios de OWA suelen ser externos) normalmente no habrán iniciado sesión en un dominio cuando provengan del exterior de la red en un servidor Exchange front-end. (Este proceso se explica con todo detalle en el artículo de Knowledge Base "Cómo IIS autentica los clientes de explorador".)
En Exchange Server, la actualización rellena la ficha Delegación para usar el atributo A2D2 en lugar del nombre principal de servicio (SPN) en Active Directory. Si echa un vistazo al objeto de equipo de Exchange que usa Adsiedit.msc, debería observar dos atributos distintos: el atributo A2D2, que es la lista de la delegación restringida de Kerberos; y el atributo de SPN, que sirve como localizador de Kerberos y punto de especificación de cuenta. Aunque es cierto que ambos atributos funcionan de manera conjunta para que se produzca la delegación restringida de Kerberos, sólo debería modificar el atributo A2D2 a través de la interfaz gráfica.
Windows puede usar el SPN HOST integrado como un alias para localizar otros servicios. Esto significa que no es necesario usar setspn.exe para que la delegación restringida de Kerberos funcione para la delegación front-end a back-end de Exchange. (Aunque la especificación explícita de HTTP/Servername en la lista de atributos de SPN funcionará con esta solución, deja más lugar para errores de administrador y no es necesario para que funcione la delegación restringida de Kerberos). La delegación restringida de Kerberos busca el atributo A2D2 en Active Directory. Cuando este atributo no está rellenado (o rellenado con el valor SPN incorrecto), la delegación restringida de Kerberos no funcionará entre los servidores respectivos. Sin embargo, en un clúster de Exchange, el atributo A2D2 del servidor front-end sólo tiene que señalarse a la cuenta de equipo del nodo de clúster para que funcione adecuadamente.
Como se observó anteriormente, un dominio de Windows Server 2003 que contiene servidores Exchange 2003 debe estar en el modo funcional nativo de Windows Server 2003. La delegación restringida de Kerberos no se puede usar a menos que se haya logrado ese nivel de funcionalidad de dominio. Si el dominio todavía se encuentra en el modo mixto e instala la actualización de software mencionada anteriormente, parecerá que funciona pero realmente se producirá un error en los registros de SPN. La delegación restringida de Kerberos es también una función de dominio y no una función de nivel de bosque. Esto significa que para Exchange Server 2003, ISA Server y los servidores front-end y back-end deben ser miembros del mismo dominio (aunque los usuarios de dominios diferentes todavía puedan autenticar a la delegación restringida de Kerberos). Una sesión de ISA Server que no es miembro de un dominio ni miembro de un dominio diferente no funcionará como parte de esta solución.
Configuración del sitio de OWA
La administración de IIS no se debe usar para ningún tipo de cambios de autenticación en OWA. Aunque OWA se ejecuta bajo IIS y responderá a los cambios en la metabase como cualquier otro sitio web, Exchange incorpora algo de complejidad con el proceso de servicios de directorio a la metabase (DS2MB). El proceso DS2MB replicará los cambios de Active Directory en la metabase IIS mediante un proceso unidireccional que sobrescribirá los cambios realizados directamente en IIS. La repercusión de este proceso es que si un administrador entra para realizar un cambio directamente en la metabase IIS (como, por ejemplo, para establecer la autenticación integrada), parecerá que la solución funciona pero se interrumpirá una vez que arranque el ciclo de réplica de DS2MB.
La opción para habilitar la autenticación integrada de Windows para los directorios virtuales HTTP se hizo disponible en ESM porque ESM realiza sus modificaciones directamente en Active Directory que, a su vez, hace que el cambio se replique hacia la metabase IIS. Tenga en cuenta que aunque la detención del servicio de Operador de sistema también detendrá el proceso DS2MB, permitiéndole realizar cambios en la metabase IIS y no sobrescribirlos; esto no es aconsejable. La próxima vez que se inicie el Operador de sistema, realizará un sondeo de los cambios de Active Directory y, a continuación, se deshabilitará la solución automáticamente.
La ficha Delegación muestra las opciones de usar solamente Kerberos y usar cualquier protocolo de autenticación. La lógica sencilla le diría que seleccione la opción de usar solamente Kerberos, ya que la solución que tratamos usa la delegación restringida de Kerberos; sin embargo, ésta es una de las muchas situaciones de IT en las que la lógica común no se aplica. Por tanto, en cambio debería seleccionar la opción de usar cualquier protocolo de autenticación (tal como se muestra en la figura 7) porque la solicitud no entra como una solicitud de Kerberos, sino como una solicitud HTTP con un certificado correspondiente asignado a una cuenta Active Directory.
Figura 7** Configuración correcta de la autenticación para tarjetas inteligentes **
En este caso, ISA Server solicita el certificado PKI de usuario sobre SSL. La solicitud entrante no es un vale de Kerberos y, por tanto, se tiene que producir una transición para que la delegación restringida de Kerberos funcione adecuadamente. De este modo, si configura la opción de usar solamente Kerberos, se interrumpirá la cadena de comunicación en ISA Server. Sin embargo, tenga en cuenta que la opción de usar solamente Kerberos funcionará en la delegación de servidor front-end al servidor Exchange back-end puesto que el servidor front-end sólo recibirá los vales de Kerberos de ISA Server.
Los directorios virtuales \Exchange y \Public son las únicas ubicaciones que deberían contener información de carpeta pública y de usuario privado. La configuración de SSL en Exchange no es nueva para la delegación restringida de Kerberos ni la autenticación en dos fases, sino un remanente de la habilitación de SSL estándar de OWA con las credenciales de autenticación básicas. Debería seguir los métodos documentados para habilitar SSL en OWA porque forzar SSL incorrectamente puede interrumpir OWA y causar problemas con ESM.
Detalles adicionales de configuración
Al implementar esta solución, es mucho más sencillo implementar primero ISA Server y Exchange de la manera estándar. No incorpore la solución completa de delegación restringida de Kerberos con todos los valores configurados (especialmente si no tenía ISA Server anteriormente en la implementación). Esto puede complicar el proceso de solución de problemas en el caso de que se produzca un error en el componente o el paso. Es mucho más sencillo implementar ISA Server y Exchange de la manera estándar (con el nombre de usuario y la contraseña pero sin la autenticación basada en formularios), asegurarse de que la instalación funciona y, a continuación, realizar la transición a la delegación restringida de Kerberos y la autenticación de certificados.
Normalmente, la autenticación basada en formularios no se puede usar con OWA habilitada con tarjeta inteligente. La autenticación basada en formularios indica que un usuario tiene un nombre de usuario y una contraseña que se deben enviar mediante el formulario estándar de Outlook. Sin embargo, con la autenticación en dos fases basada en tarjeta inteligente, el usuario tendrá sólo una tarjeta inteligente y no una contraseña. Por lo tanto, la autenticación basada en formularios no tendrá ningún medio para aceptar ni enviar únicamente el certificado para la autenticación. El uso de la autenticación basado en formularios en cualquier lugar de la cadena (por ejemplo, en un servidor front-end detrás de ISA Server) interrumpirá la configuración de OWA habilitada con tarjetas inteligentes. Si habilita la autenticación basada en formularios, el directorio virtual de Exchange se establecerá forzosamente en la autenticación básica y así, la metabase IIS se establecerá también en la autenticación básica.
Si tiene una combinación de usuarios que tienen nombres de usuario/contraseñas y tarjetas inteligentes, puede habilitar la autenticación de reserva en el servicio de escucha web de ISA, y cuando un usuario presione el botón ESC después de que se le piden las credenciales basadas en certificado, se le pedirán las credenciales estándar de nombre de usuario/contraseña aunque la autenticación integrada esté habilitada detrás de ISA Server en el servidor de Exchange. Además, ISA Server puede agotar el tiempo de espera de la sesión SSL de una manera muy similar a las funciones de autenticación basadas en formularios.
Conclusión
La compatibilidad con tarjetas inteligentes para la autenticación a OWA es una adición bienvenida tanto para Exchange Server 2003 como para Exchange Server 2007. Con la capacidad de iniciar sesión en OWA usando un certificado, los usuarios ya no se tienen que preocupar por recordar largas y complejas contraseñas, y los administradores disponen ahora de una herramienta eficaz frente a los registradores de pulsaciones de teclas y otras formas de software malintencionado que pueden descubrir credenciales de usuario de un sistema infectado. Consulte la barra lateral de "Recursos" para obtener más información.
La configuración correcta de ISA Server para la autenticación en dos fases mediante tarjetas inteligentes aumenta más la seguridad general al realizar un filtrado de nivel de aplicación en la aplicación de OWA publicada. Además, ISA Server 2006 incorpora compatibilidad para publicar Exchange Server 2003 y Exchange Server 2007 a través de los sencillos asistentes para publicación, por lo que ISA Server sigue siendo una inversión sólida para las organizaciones que están realizando la transición a Exchange Server 2007.
Recursos
- Cómo compartir archivos quitados por la función de filtrado de "HTML seguro" en Outlook Web Access para Exchange Server 2003
- Solución de problemas de la delegación de Kerberos
- Servicio de actualización de metabase
- Autenticación en ISA Server 2006
- Transición del protocolo y delegación restringida de Kerberos
- TechNet Webcast: Implementación de la autenticación multifase mediante tarjetas inteligentes
Victor Akinnagbees ingeniero de campo principal de Microsoft que trabaja en el área de Washington, D.C. Se centra principalmente en la seguridad, en la infraestructura y en la mensajería.
Ted Dresseles consultor de Microsoft que trabaja en el área de Washington, D.C. Se centra principalmente en la seguridad y la infraestructura.
Jason Opdycke es ingeniero de campo principal de Microsoft del área de Charlotte, Carolina del Norte. Se centra principalmente en las áreas de la seguridad y la infraestructura.
© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.