Entrada e descoberta no Office Communicator

Tópico modificado em: 2009-04-02

O Office Communicator deve determinar em qual servidor ele deve fazer logon utilizando o URI do usuário (por exemplo, jeremy@contoso.com) e as definições manuais configuradas no cliente. Caso tenham sido fornecidas definições manuais, ficará claro qual servidor deverá ser usado. Porém, se o URI for o único indicador fornecido, será necessária uma operação de descoberta.

A descoberta no Communicator varia de acordo com a configuração. Depois que o cliente descobrir o servidor ao qual deverá se conectar, ele tentará estabelecer a conexão usando TCP ou TLS sobre TCP. Se for usado o TLS, o servidor fornecerá um certificado a fim de se autenticar para o cliente. O cliente deverá validar o certificado antes de continuar. O cliente poderá negociar uma compactação (se estiver usando TLS sobre TCP); em seguida, ele iniciará um registro SIP.

Depois disso, o cliente enviará ao servidor uma mensagem SIP REGISTER sem credenciais. Isso levará o Office Communications Server a emitir um desafio solicitando as credenciais do usuário; além disso, especificará para o cliente do Communicator os protocolos de autenticação aceitos.

O Communicator tem duas opções para fornecer credenciais: ele pode utilizar as credenciais do Windows atuais do usuário para fazer logon ou solicitar credenciais ao usuário.

Observação:
O gerenciador de credenciais do Windows também poderá ser usado para gerenciar credenciais. Para obter mais informações sobre o gerenciador de credenciais, consulte o artigo do Microsoft TechNet intitulado Windows XP Resource Kit: Understanding Logon and Authentication, localizado em https://go.microsoft.com/fwlink/?Linkid=133674, na seção Stored User Names and Passwords.

Podem ocorrer falhas na autenticação durante a primeira parte do processamento de logon. Isso pode acontecer quando ainda não há credenciais salvas ou quando as credenciais de área de trabalho não correspondem à conta que o Communicator está tentando usar. Também pode acontecer quando o URI do SIP, o nome da conta ou a senha são digitados incorretamente ou quando as credenciais e o URI do SIP não coincidem. Um exemplo dessa situação é quando Jeremy tenta fazer logon com o URI sip:jeremy@contoso.com, mas utiliza a conta de usuário e a senha de CONTOSO\vadim em vez das credenciais do proprietário da conta, CONTOSO\jeremy.

Noções básicas sobre configuração automática de clientes e descoberta DNS

Para as organizações que planejam usar a configuração automática, um dos requisitos durante a implantação dos servidores é criar um registro SRV de DNS interno que mapeie um dos seguintes registros para o FQDN (nome de domínio totalmente qualificado) do pool Enterprise ou servidor Standard Edition que trata das solicitações de entrada dos clientes:

• _sipinternaltls._tcp.<domínio> (para conexões TLS internas)
• _sipinternal._tcp.<domínio> (para conexões TCP internas, executadas somente se o TCP for permitido)

Quando está definido para usar a configuração automática, o cliente usa o URI do SIP fornecido pelo usuário para descobrir em qual servidor ele deverá entrar. O Communicator faz isso utilizando registros SRV de DNS publicados para obter a parte de domínio do URI do SIP.

Por exemplo, se o usuário digitar o URI sip:jeremy@contoso.com, o Communicator usará contoso.com para descobrir um servidor SIP que empregue o DNS. O Communicator procura os seguintes registros SRV em sua pesquisa por um servidor apropriado:

• _sipinternaltls._tcp.contoso.com
• _sipinternal._tcp.contoso.com
• _sip._tls.contoso.com

Se esses registros não existirem, o Communicator fará uma consulta por registros de host (A):

• sipinternal.contoso.com
• sipexternal.contoso.com

A primeira consulta procura um servidor interno no domínio contoso.com que ofereça portas com suporte a TLS sobre TCP para os clientes. A segunda consulta tenta descobrir um servidor interno no domínio contoso.com que ofereça portas TCP para os clientes. Por fim, a terceira consulta procura um servidor para o domínio contoso.com que possa ser acessado pela Internet e ofereça portas com suporte a TLS sobre TCP para os clientes. O Communicator nunca procura por um servidor que possa ser acessado pela Internet e ofereça suporte a TCP, porque o uso de SIP com texto não criptografado na Internet não faz sentido do ponto de vista da segurança. Em outras palavras, o Communicator não sabe se a rede que está sendo usada é interna ou externa. Ele faz consultas em busca de todos os registros SRV de DNS, mas tenta primeiro as conexões TLS sobre TCP. O TLS sobre TCP é forçado através de um Servidor de Borda (sem opção para levar em conta as conexões TCP desprotegidas).

Finalmente, se todos os registros SRV de DNS não existirem (não que não sejam válidos, mas quando não existirem mesmo), o cliente reverterá para sipinternal.<domínio do URI> e tentará resolver esse nome de host. Se o nome de host for resolvido como um endereço IP, o Communicator tentará se conectar usando TLS sobre TCP, TCP ou ambos, dependendo do que for determinado pela diretiva. Se isso falhar, ele tentará uma última vez com sipexternal.<domínio do URI>.

As diretivas do Communicator podem ser colocadas em vigor para evitar que o TCP seja usado, e isso evita que a segunda consulta seja emitida. Também é possível especificar a diretiva EnableStrictDNSNaming, que requer nomes restritos para os computadores descobertos. Nesse caso, o Communicator só terá permissão de se conectar aos servidores se o nome corresponder ao domínio na parte de domínio do URI do SIP do usuário ou se o FQDN for sip.<domínio do URI>. Caso essa diretiva não seja habilitada, qualquer nome de servidor no formato <nome do servidor>.<domínio do URI> será permitido. Por exemplo, para sip:jeremy@contoso.com, o host sip.contoso.com será sempre permitido (com ou sem a diretiva restritiva). Servidor77.contoso.com, sipfed.contoso.com e ap.contoso.com também serão permitidos se a diretiva de nomenclatura restritiva não estiver habilitada. Os nomes de servidor a seguir nunca serão permitidos, pois não correspondem exatamente ao domínio especificado pelo URI do usuário. Portanto, o cliente não confiará nesses servidores como pontos de logon válidos: sip.eng.contoso.com, sip.contoso.net, sip.com, sip.contoso.com.cpandl.com e assim por diante.

Essa validação rígida entre o nome do host e o URI é feita especificamente porque a única configuração fornecida ao cliente é o URI do SIP. Em função disso, o cliente deve tomar muito cuidado para não permitir que ataques ao DNS permitam que ele se conecte a qualquer “man-in-the-middle”, o qual poderia então observar o tráfego do Communicator. Através de um vínculo restrito entre o URI e os nomes de host com permissão de logon, o Communicator tem mais certeza de que o certificado que o usuário está validando realmente tem autoridade para acessar o domínio no qual ele está tentando fazer logon.

Depois que o nome do host é identificado, o Communicator também resolve esse nome como um endereço IP. Em geral, isso acontece como resultado da solicitação de SRV de DNS, porém, o Communicator não poderá se conectar até que o endereço IP seja resolvido. Isso também pode ser um problema durante o logon.

A versão mais recente do Communicator permite especificar manualmente um servidor interno e também um servidor externo no qual seja possível fazer logon. O Communicator sempre tentará se conectar ao servidor interno se ele estiver disponível, mas retornará ao servidor externo. Anteriormente, o Communicator dispunha de uma única entrada manual, o que causava problemas para os funcionários móveis. Com a capacidade de especificar um servidor interno e um externo, agora ficou mais fácil para os administradores configurar e habilitar configurações de laptop que funcionem em redes internas e externas. Essa funcionalidade ampliada também é importante nas empresas em que o domínio no URI do usuário é diferente do domínio do servidor corporativo SIP. Como o administrador pode configurar o Communicator (em um laptop, por exemplo) uma vez, o usuário não precisa se lembrar dos servidores internos ou externos, e os administradores não têm que publicar registros SRV de DNS para todos os domínios aos quais desejem oferecer suporte para usuários de acesso remoto.

O cliente do Office Communicator permite que o usuário se conecte automaticamente ao servidor do Office Communications Server apropriado sem precisar fornecer o nome do servidor. Quer o cliente esteja dentro da rede interna ou trabalhando externamente, esse recurso o redirecionará e permitirá que ele autentique seu próprio servidor do Office Communications Server (no caso do Standard Edition) ou pool primário (no caso do Enterprise Edition) e se conecte a ele. Esse recurso apresenta uma dependência significativa do DNS. Para que essa operação tenha êxito, os registros SRV apropriados devem ser publicados interna e externamente.

Quando o cliente do Office Communicator é iniciado pela primeira vez e o usuário tenta se conectar, o Office Communicator sempre tenta se conectar ao servidor ou pool primário no mesmo domínio que o seu, ou usando o mesmo URI do SIP como endereço de entrada. Por exemplo, caso o nome de entrada utilizado seja kim.akers@fabrikam.com, o Office Communicator procurará o pool primário ou o servidor do Office Communications Server no mesmo namespace do DNS, ou seja, fabrikam.com. Esse processo é facilitado com o uso de registros SRV de DNS, pois, em última análise, isso aponta o cliente para o FQDN do pool primário ou servidor no domínio correto. O processo será o mesmo quer o cliente esteja em uma rede interna ou externa.

O cliente começa consultando os registros SRV e, por padrão, sempre tenta usar o TLS para autenticação. Caso o TLS não tenha êxito, só então o cliente reverterá para o protocolo TCP.

• _sipinternaltls._tcp.fabrikam.com
• _sipinternal._tcp.fabrikam.com

Qualquer um desses dois primeiros registros DNS deverá ser publicado e estar disponível no namespace interno do DNS. Assim, se neste ponto o cliente conseguir o nome do host de volta, ele se conectará diretamente ao pool primário ou ao servidor do Office Communications Server. Caso contrário, ele continuará o processo de consulta, sabendo que no momento não está na rede interna.

• _sip._tls.fabrikam.com
• _sip._tcp.fabrikam.com

Caso qualquer uma dessas consultas tenha êxito, o cliente será redirecionado para a borda externa do Servidor de Borda de Acesso e, em seguida, para o pool primário ou o servidor do Office Communications Server interno. Contudo, se ainda ocorrer falha, como tentativa final, ele tentará pesquisar os registros de host diretamente, como ilustram os dois exemplos a seguir. Caso ocorra falha nessa tentativa de configurar as definições automaticamente, haverá falha no Office Communicator e será necessária uma intervenção manual.

• sip.fabrikam.com
• sipinternal.fabrikam.com