Criar ou editar configuração do parceiro XMPP no Lync Server 2013
Tópico Última Modificação: 2014-09-03
O Microsoft Lync Server 2013 integra um proxy XMPP (Extensible Messaging and Presence Protocol) no Servidor Edge e um Gateway XMPP no Servidor front-end ou no conjunto de Front-end. Para permitir ligações de outras implementações XMPP, tem de configurar o XMPP no Painel de Controle do Lync Server. Pode configurar as definições numa base de domínio XMPP. Para criar uma nova associação de parceiros, faça o seguinte:
Para criar um novo parceiro federado ou editar uma configuração existente
Usando uma conta de usuário que é membro do grupo RTCUniversalServerAdmins (ou tem direitos de usuário equivalentes), ou está atribuída à função CsAdministrator, faça logon em qualquer computador de sua implantação interna.
Abra uma janela do browser e, em seguida, introduza o URL do Administração para abrir o Painel de Controle do Lync Server. Para obter detalhes sobre os diferentes métodos que pode utilizar para iniciar o Lync Server Painel de Controle, consulte Abrir ferramentas administrativas do Lync Server 2013.
Na barra de navegação à esquerda, clique em Federação e Acesso Externo e, em seguida, clique em Parceiros Federados XMPP.
Para criar uma nova configuração, clique em Novo
Para editar uma configuração existente, selecione a configuração e clique em Editar
Para criar ou editar configurações para Parceiros Federados XMPP, defina as seguintes definições:
Domínio primário (Obrigatório). O domínio primário é o domínio base do parceiro XMPP. Por exemplo, introduziria fabrikam.com para o nome de domínio do parceiro XMPP. Esta é uma entrada obrigatória.
Descrição. A descrição destina-se a notas ou outras informações de identificação para esta configuração específica. Esta entrada é opcional.
Domínios adicionais. Os domínios adicionais são domínios que fazem parte do domínio do parceiro XMPP que devem ser incluídos como parte da comunicação XMPP permitida. Por exemplo, se o domínio primário for fabrikam.com, deverá listar todos os outros domínios que estão em fabrikam.com com os quais irá comunicar através de XMPP. Por exemplo, pode introduzir corp.fabrikam.com e it.fabrikam.com para o domínio XMPP empresarial e o domínio XMPP das Tecnologias de Informação no domínio main XMPP de fabrikam.com.
Tipo de parceiro. O Tipo de parceiro é uma definição obrigatória e dá-lhe uma seleção de três opções num menu pendente. Tem de escolher um dos seguintes procedimentos para descrever e impor os contactos que podem ser adicionados. Pode selecionar entre:
Federado. Um tipo de parceiro Federado é uma ligação fidedigna entre uma implementação de parceiro do Lync Server ou do Office Communications Server 2007 R2.
Público verificado. Um parceiro Verificado público é quando os contactos que fazem parte de uma implementação verificada pelo fornecedor podem ser adicionados à lista de contactos do utilizador. Os convites podem ser enviados pelo utilizador do Lync ou o utilizador do Lync pode aceitar convites do contacto do parceiro.
Público não verificado. Uma relação Pública não verificada implica que não existe nenhuma status estabelecida e verificável entre as duas implementações. Um utilizador do Lync tem de convidar o contacto não verificado para esse contacto para poder adicionar o utilizador do Lync à sua lista de contactos. Por exemplo, o Google GTalk não é um serviço XMPP verificado público, uma vez que está relacionado com o Lync Server. Um utilizador do GTalk não poderá adicionar o utilizador do Lync como um contacto, a menos que exista um convite explícito enviado pelo utilizador do Lync.
Notas sobre a negociação de transmissão em fluxo e os métodos de segurança Transport Layer Security (TLS) e Autenticação de Software e Camada de Segurança (SASL):
O XMPP Standards Foundation (XSF) e o IETF (Internet Engineering Task Force ) definem um conjunto de regras e normas para utilizar e gerir certificados de cliente TLS, certificados de servidor TLS e o mecanismo SASL. A utilização de TLS e SASL é o processo necessário para proteger o fluxo XMPP. No documento XEP-0178 das Normas XMPP, "especifica um fluxo de protocolo recomendado para utilização do mecanismo SASL EXTERNAL com certificados PKIX, especialmente quando um serviço XMPP indica que o TLS é obrigatório para negociar". PKIX, conforme indicado na documentação do XSF, refere-se à infraestrutura de chaves públicas, também conhecida como PKI.
Veja o documento XSF XEP-0178 para obter mais detalhes sobre os requisitos de XMPP. Para obter detalhes, consulte "XEP-0178: Melhores Práticas para Utilização de SASL EXTERNO com Certificados". http://xmpp.org/extensions/xep-0178.html
Veja o documento IETF "Extensible Messaging and Presence Protocol (XMPP): Core", Section 5.0, STARTTLS Negotiation https://tools.ietf.org/html/rfc6120.
Negociação TLS. Define as regras de negociação do TLS. Um serviço XMPP pode exigir TLS, tornar o TLS opcional ou definir que o TLS não é suportado. Escolher Opcional deixa o requisito ao serviço XMPP para uma decisão obrigatória de negociação. Para ver todas as definições e detalhes possíveis da negociação SASL, TLS e Dialback (incluindo configurações de erros não válidas e conhecidas), veja Definições de negociação para parceiros federados XMPP no Lync Server 2013.
Obrigatório. O serviço XMPP requer a negociação do TLS.
Opcional. O serviço XMPP indica que o TLS é obrigatório para negociar.
Não suportado. O serviço XMPP não suporta TLS.
Negociação sasl. Define as regras de negociação SASL. Um serviço XMPP pode exigir SASL, tornar a SASL opcional ou definir que o SASL não é suportado. Escolher Opcional deixa o requisito ao serviço XMPP do parceiro para uma decisão obrigatória de negociação.
Aviso
A SASL necessita de TLS. Para utilizar SASL, o TLS tem de ser obrigatório ou opcional. Qualquer configuração que defina a SASL como obrigatória ou opcional tem de ter suporte TLS. Ao clicar em Consolidar para guardar as alterações, se não tiver definido o TLS como obrigatório ou opcional, ser-lhe-á avisado que a SASL tem de ter suporte TLS e as alterações não são guardadas. Para resolve o erro, defina TLS como Obrigatório ou Opcional. Se a utilização da SASL for opcional e o suporte de negociação do TLS não for possível, tem de definir a negociação de SASL como Não Suportada. Confirme com o serviço XMPP quais os fluxos de negociação adequados para tLS e SASL ou a interrupção do serviço ocorrerá.
Obrigatório. O serviço XMPP requer uma negociação SASL.
Opcional. O serviço XMPP indica que a SASL é obrigatória para negociar.
Não suportado. O serviço XMPP não suporta SASL.
Negociação de chamada de retorno. A negociação de chamada de retorno é definida pelo XSF no documento XEP-220: Dialbackhttp://xmpp.org/extensions/xep-0220.html do Servidor. O processo de chamada de retorno do servidor utiliza o sistema de nomes de domínio (DNS) e um servidor autoritativo para verificar se o pedido veio de um parceiro XMPP válido. Para tal, o servidor de origem cria uma mensagem de um tipo específico com uma chave de chamada de retorno gerada e procura o servidor de receção no DNS. O servidor de origem envia a chave num fluxo XML para a pesquisa de DNS resultante, presumivelmente o servidor de receção. Ao receber a chave através do fluxo XML, o servidor de receção não responde ao servidor de origem, mas envia a chave para um servidor autoritativo conhecido. O servidor autoritativo verifica se a chave é válida ou não é válida. Se não for válido, o servidor de receção não responde ao servidor de origem. Se a chave for válida, o servidor de receção informa o servidor de origem de que a identidade e a chave são válidas e que a conversação pode ser iniciada.
Existem dois estados válidos para a negociação da Chamada de Retorno:
É verdade. O servidor XMPP está configurado para utilizar a negociação de Chamada de Retorno se um pedido deve ser recebido de um servidor de origem
Falso. O servidor XMPP não está configurado para utilizar a negociação de Chamada de Retorno e, se um pedido deve ser recebido de um servidor de origem, será ignorado