Inicio de sesión y detección de Office Communicator
Última modificación del tema: 2009-04-02
Office Communicator debe determinar en qué servidor se debe iniciar sesión mediante el URI del usuario (por ejemplo, juan@contoso.com) y cualquier opción manual configurada en el cliente. Si se ha proporcionado una configuración manual, no habrá dudas sobre el servidor que hay que utilizar. Pero si el URI es el único indicador proporcionado, se requerirán algunas tareas de detección.
La detección de Communicator varía en función de la configuración. Cuando el cliente detecta el servidor al que debe conectarse, intenta realizar la conexión mediante TCP o TLS a través de TCP. Si se utiliza TLS, el servidor proporciona un certificado para autenticarse en el cliente. El cliente debe validar el certificado antes de continuar. El cliente podría negociar la compresión (si se utiliza TLS a través de TCP) y, a continuación, iniciar un registro SIP.
A continuación, el cliente envía un mensaje SIP REGISTER al servidor sin credenciales. Solicita a Office Communications Server que autentique las credenciales de usuario y especifica al cliente de Communicator los protocolos de autenticación que acepta.
En el momento de proporcionar las credenciales, Communicator tiene dos opciones. Communicator puede utilizar las credenciales de Windows actuales del usuario para iniciar sesión o puede solicitárselas al usuario.
Nota
El administrador de credenciales de Windows también se puede utilizar para administrar las credenciales. Encontrará más información sobre el administrador de credenciales es en el artículo de Microsoft TechNet del Kit de recursos de Windows XP: Descripción del inicio de sesión y la autenticación en https://go.microsoft.com/fwlink/?Linkid=133674, en la sección Nombres de usuario y contraseñas almacenados (en inglés).
Se pueden producir errores de autenticación durante la primera parte del procesamiento de inicio de sesión. Estos errores se pueden producir cuando las credenciales aún no se han guardado o cuando las credenciales de escritorio no coinciden con la cuenta que Communicator intenta utilizar. También se pueden producir errores cuando el URI del SIP, el nombre de la cuenta o la contraseña se especifican de forma incorrecta o cuando las credenciales y el URI del SIP no coinciden. Por ejemplo, Juan intenta iniciar sesión con el URI sip:juan@contoso.com, pero utiliza la cuenta de usuario y contraseña de CONTOSO\vadim en lugar de las credenciales del propietario de la cuenta, CONTOSO\juan.
Configuración automática del cliente y detección DNS
Para las organizaciones que piensan usar la configuración automática, uno de los requisitos durante la implementación del servidor es crear un registro DNS SRV interno que asigne uno de los registros siguientes al nombre de dominio completo (FQDN) del grupo de servidores Enterprise Edition o del servidor Standard Edition que administra las solicitudes de inicio de sesión de los clientes:
- _sipinternaltls._tcp.<dominio> (para las conexiones TLS internas)
- _sipinternal._tcp. <dominio> (para las conexiones TCP internas, que solo se realizan si se permite TCP)
Cuando se configura el cliente para que use la configuración automática, utiliza el URI del SIP proporcionado por el usuario para detectar en qué servidor debe iniciar sesión. Para ello, Communicator utiliza registros DNS SRV publicados para la parte del dominio del URI del SIP.
Por ejemplo, si el usuario escribe el URI sip:juan@contoso.com, Communicator utiliza contoso.com para detectar un servidor SIP que utilice DNS. Communicator busca los registros SRV siguientes para encontrar un servidor adecuado:
- _sipinternaltls._tcp.contoso.com
- _sipinternal._tcp.contoso.com
- _sip._tls.contoso.com
Si estos registros no existen, Communicator consulta los registros (A) del host:
- sipinternal.contoso.com
- sipexternal.contoso.com
La primera consulta busca un servidor interno en el dominio contoso.com que proporcione puertos que admitan TLS a través de TCP para los clientes. La segunda consulta intenta detectar un servidor interno en el dominio contoso.com que proporcione puertos TCP para los clientes. Por último, la tercera consulta busca un servidor accesible a través de Internet para el dominio contoso.com que proporcione puertos que admitan TLS a través de TCP para los clientes. Communicator no busca nunca un servidor accesible a través de Internet que admita TCP, porque el uso del SIP de texto sin cifrar en Internet no tiene sentido desde el punto de vista de la seguridad. O dicho de otra forma, Communicator no es capaz de determinar si la red que se utiliza es interna o externa. Communicator consulta todos los registros DNS SRV. Sin embargo, prueba primero las conexiones TLS a través de TCP. El uso de TLS a través de TCP se impone a través de un servidor perimetral (no hay ninguna opción para permitir conexiones TCP no seguras).
Por último, si no existe ningún registro DNS SRV (no si no hay ningún registro válido; solo si no existe ninguno), el cliente recurre a sipinternal.<URI del dominio> e intenta resolver ese nombre de host. Si el nombre de host se resuelve como una dirección IP, Communicator intenta conectarse utilizando TLS a través de TCP, TCP o ambos, dependiendo de lo que la directiva permita. Si no puede conectarse, lo intentará por última vez con sipexternal.<URI del dominio>.
Se pueden aplicar directivas de Communicator para impedir que se utilice TCP, con lo que impedirá que se emita la segunda consulta. Se puede especificar también la directiva EnableStrictDNSNaming, que requiere nombres estrictos para los equipos detectados. En ese caso, Communicator solamente puede conectarse a los servidores si el nombre coincide con el dominio en la parte del dominio del URI del SIP del usuario o si el FQDN es sip.<dominio del URI>. Si no se habilita esta directiva, se permite cualquier nombre del servidor que tenga el formato <nombreDeServidor>.<URI del dominio>. Por ejemplo, para sip:juan@contoso.com, se permite siempre el host sip.contoso.com (con o sin directiva de nombres estrictos). Server77.contoso.com, sipfed.contoso.com y ap.contoso.com también se permiten si la directiva de nombres estrictos no está habilitada. Los nombres de servidor siguientes no se permiten nunca porque no coinciden con el dominio especificado por el URI de usuario. Por consiguiente, el cliente no confía en estos servidores como puntos de inicio de sesión válidos: sip.eng.contoso.com, sip.contoso.net, sip.com, sip.contoso.com.cpandl.com, etc.
Esta validación estricta entre el nombre de host y el URI se realiza sobre todo porque la única configuración que se proporciona al cliente es el URI del SIP. Por este motivo, el cliente debe tener mucho cuidado para no permitir ataques de DNS que permitan la conexión de un intermediario, que podría observar el tráfico de Communicator. Con esta estrecha asociación entre el URI y los nombres de host permitidos para el inicio de sesión, Communicator tendrá la certeza de que el certificado que el usuario valida está autorizado en el dominio en el que intenta iniciar sesión.
Una vez identificado el nombre de host, Communicator resuelve también el nombre de host como una dirección IP. Esto se produce normalmente como resultado de la solicitud DNS SRV, pero hasta que se resuelva la dirección IP, Communicator no se puede conectar. Esto también puede ser un problema durante el inicio de sesión.
La última versión de Communicator proporciona la capacidad de especificar manualmente tanto un servidor interno como uno externo para el inicio de sesión. Communicator siempre intenta conectarse al servidor interno si está disponible, pero recurrirá al servidor externo si no puede realizar la conexión. Anteriormente, Communicator solamente tenía una única entrada manual, que creaba problemas a los trabajadores móviles. Con la capacidad de especificar un servidor interno y externo, ahora es más sencillo para los administradores definir y habilitar configuraciones de portátil que funcionen en redes internas y externas. Esta funcionalidad mejorada también es importante para las compañías en las que el dominio del URI del usuario difiere del dominio del servidor de empresa SIP. Como el administrador puede configurar Communicator (en un portátil, por ejemplo) una vez, el usuario no necesita recordar los servidores internos o externos y los administradores no tienen que publicar los registros DNS SRV para todos los dominios que desean permitir a los usuarios de acceso remoto.
El cliente de Office Communicator permite que el usuario se conecte automáticamente al servidor de Office Communications Server adecuado sin tener que especificar el nombre del servidor. Independientemente de si el cliente pertenece a la red interna o funciona externamente, esta característica redirige al cliente y le permite autenticarse y conectarse a su propio servidor de Office Communications Server (en el caso de Standard Edition) o grupo de servidores principales (en el caso de Enterprise Edition). Esta característica tiene una gran dependencia de DNS. Para que funcione correctamente, los registros SRV adecuados deben publicarse interna y externamente.
Cuando el cliente de Office Communicator se inicia por primera vez y el usuario intenta conectarse, Office Communicator siempre intenta conectarse al servidor o grupo de servidores principales en su mismo dominio o mediante el mismo URI del SIP que la dirección de inicio de sesión. Por ejemplo, si el nombre de sesión utilizado es kim.akers@fabrikam.com, Office Communicator busca el grupo de servidores principales o el servidor de Office Communications Server en el mismo espacio de nombres DNS, que es fabrikam.com. Este proceso se simplifica gracias al uso de registros DNS SRV, que finalmente dirigirán al cliente al FQDN del grupo de servidores principales o del servidor en el dominio correcto. El proceso funciona del mismo modo si el cliente está en una red interna o externa.
El cliente consulta inicialmente los registros SRV y, de forma predeterminada, siempre intenta utilizar TLS para la autenticación. Si la conexión TLS no se realiza correctamente, entonces, y solo entonces, recurre al Protocolo de control de transmisión (TCP).
- _sipinternaltls._tcp.fabrikam.com
- _sipinternal._tcp.fabrikam.com
Se debe publicar alguno de estos dos primeros registros DNS y deben estar disponibles en el espacio de nombres DNS interno. De este modo, si el cliente recibe el nombre del host, se conectará directamente al grupo de servidores principales o al servidor de Office Communications Server. En caso contrario, continuará con el proceso de consulta sabiendo ya que el servidor no se encuentra en la red interna.
- _sip._tls.fabrikam.com
- _sip._tcp.fabrikam.com
Si alguna de estas consultas tiene éxito, se redirige al cliente al perímetro externo del servidor de acceso perimetral y, por tanto, al grupo de servidores principales internos o al servidor de Office Communications Server. Pero si estas consultas tampoco tienen éxito, como último intento se intentará buscar directamente los registros del host, como en los dos ejemplos siguientes. Si este intento de definir automáticamente la configuración no tiene éxito, Office Communicator producirá un error y se requerirá la intervención manual.
- sip.fabrikam.com
- sipinternal.fabrikam.com