Dokumentaci k tomuto tématu nalezneme u Microsoftu na řadě míst Configuring SIP Federation, XMPP Federation and Public Instant Messaging, Configure XMPP Gateway on Lync Server 2013, Manage XMPP Federated Partners for Your Organization, Example XMPP Configuration - XMPP Federation with Google Talk.

XMPP a jeho využití

Protokol Extensible Messaging and Presence Protocol (XMPP) je otevřený standard založený na XML a vznikl již v roce 1999. Díky jeho jednoduchosti a otevřenosti existuje množství serverů (komerčních i open source) a princip používání můžeme přirovnat k emailu. Kdokoliv si může zprovoznit vlastní server, kde si vytváříme účty v rámci své domény. Nebo existuje řada veřejných serverů, kde si můžeme zdarma vytvořit účet (obdoba free mailů). Jako náš identifikátor slouží Jabber ID (JID), které má stejný tvar jako emailová adresa (a ve většině případů používáme stejnou adresu pro email i XMPP). Klientem se připojujeme ke svému serveru, a pokud chceme komunikovat s někým v jiné doméně, tak si náš server najde server příjemce a jemu posílá zprávy.

XMPP je využíván také v některých velkých sítích a samozřejmě pak funguje vzájemné propojení. Komunikační nástroj Google Talk (vznikl v roce 2005) je postaven na XMPP protokolu (pro hlas využívá Jingle), což přináší ohromnou základnu uživatelů. Před krátkou dobou ovšem Google oznámil přechod na Google Hangouts (spojení IM, VoIP, video) a spolu s tím zmenšení podpory XMPP (ze zpráv mi není jasné, co přesně to má znamenat, zatím mi komunikace s uživateli na Google Talk funguje bez problémů). Dalším zástupcem je firma Cisco, která v roce 2008 získala společnost Jabber, Inc., a začala využívat XMPP protokol ve všech svých komunikačních nástrojích (hlavní zástupce je Cisco Unified Presence). A podporu XMPP má například i Facebook.

Možnosti federace v Lyncu

U Lyncu máme tři různé možnosti pro komunikaci s externími/federovanými uživateli. Můžeme se na to podívat dle nastavení, které se nachází v Control Panelu ve Federation and External Access:

• SIP Federated Domains - základní federace s Lyncem (OCS) v jiných organizacích
• SIP Federated Providers - Public Instant Messaging (PIM) connectivity, konektory do veřejných sítí, hlavní byl dříve MS Messenger, který je nyní nahrazen Skypem
• XMPP Federated Partners - napojení na určité XMPP domény

U federace s Lyncem (či OCS) můžeme využít Open Federation, pak je možná komunikace se všemi doménami, využívá se automatické vyhledávání v DNS. Nastavení řídíme v Access Edge Configuration hodnota Partner Domain Discovery. Opakem je to, že musíme ručně zadat všechny domény, s kterými chceme povolit komunikaci. I když máme Partner Discovery zapnuto, tak někdy může být potřeba přidat doménu do Allowed External Domains. Jinak se totiž uplatňuje limit 20 zpráv za vteřinu a komunikace maximálně s 1000 uživateli druhé domény.

Bohužel u XMPP federace nelze nastavit Open Federation (což je běžné u jiných Jabber serverů). Takže každou XMPP doménu, s kterou chceme federaci provozovat, musí administrátor explicitně konfigurovat.

Důležité je, jakým způsobem do Lyncu přidáme externí kontakt. Princip je takový, že jsou vyjmenované domény, které jsou přiřazeny nějaké službě a ostatní se berou (v případě Open Federation), že patří Lync instalaci v jiné organizaci a provádí se hledání Lync služeb. Tyto kontakty zadáváme ve formátu emailové adresy (či SIP adresy). Automaticky a napevno jsou nastaveny domény Microsoftu, které jsou (dnes) přiřazeny k PIC Skype. Dále můžeme definovat XMPP domény a při zadání adresy z této domény se hledá přes XMPP Gateway. Zbývají Skype adresy z ne MS domény, ty se musí zadávat speciálním formátem user(domain.tld)@msn.com.

Zprovoznění federace Lync a XMPP

Základní princip je takový, že na Front End serveru nám běží služba XMPP Gateway, která komunikuje se službou XMPP Proxy na Edge serveru. Služba XMPP Proxy komunikuje do internetu a z internetu přijímá požadavky.

Povolení XMPP federace pro topologii

Pokud nemáme XMPP federaci povolenu, tak ji musíme zapnout pro Edge server a celou Site v topologii.

Připojíme se na Lync Front End server a spustíme Lync Server Topology Builder. Klikneme na jméno Site a podíváme se v sekci Site federation route assigment na nastavení XMPP federation. Pokud je disabled, tak musíme zapnout.

Rozklikneme Lync Server 2013 a Edge pools, klikneme pravým tlačítkem na náš Edge server a zvolíme Edit properties. Zatrhneme Enable XMPP federation for this Edge pool (port 5269).

Dále klikneme pravým tlačítkem na naši Site a zvolíme Edit properties. Zatrhneme Enable XMPP federation a vybereme náš Edge server.

Vypublikujeme topologii.

Instalace služeb a certifikátu na Edge serveru

Po té, co jsme povolili XMPP, musíme doinstalovat jeho službu na Edge server. Připojíme se na Lync Edge server a spustíme Deployment Wizard, klikneme na Install or Update Lync Server System a zde zvolíme Step 2: Setup or Remove Lync server Components. Tím se nainstaluje XmppProxy.msi a upraví DB.

Po instalaci nám přibude nová služba Lync Server XMPP Translating Gateway Proxy, kterou musíme nastartovat. Můžeme k tomu využít Step 4: Start Services.

Pozn.: Na Front End serveru máme službu Lync Server XMPP Translating Gateway.

Jenže zatím nastartovat službu nemůžeme (krok 4 je neaktivní, při ručním startu služba selže), protože vyžaduje certifikát. Použijeme Step 3: Request, Install or Assign Certificates. Můžeme přidat nový certifikát pro XmppServer nebo můžeme pouze nastavit již existující, protože ve většině případů využijeme existující DNS jméno Access Edge rozhraní i pro XMPP. Označíme External Edge certificate (public internet), zkontrolujeme, že je zatržena volba XmppServer (většinou potřebujeme mít označeny všechny). A projdeme průvodce tlačítkem Assign.

Poté již můžeme nastartovat novou službu třeba pomocí Step 4: Start Services.

Zprovoznění komunikací

Pro XMPP využijeme TCP port 5269 (XMPP), který se standardně používá pro komunikaci mezi XMPP servery (tedy XMPP Proxy na Edge Serveru s federovanými partnery). Musíme povolit komunikaci z Access Edge rozhraní Edge serveru na tento port v internetu a zpětně z internetu na publikovanou adresu tohoto rozhraní. Na externím firewallu můžeme rozšířit již existující pravidla.

Potom potřebujeme ještě TCP port 23456 (XMPP/MTLS), který používá Lync pro komunikaci mezi XMPP Gateway na Front End Server a interní IP adresou Edge Serveru. Tento port musíme povolit z Front End serveru na interní rozhraní Edge serveru, opět stačí rozšířit pravidla na interním firewallu.

DNS záznam

Když spolu komunikují XMPP servery, tak podle domény v JID cílového kontaktu hledají SRV (Service) DNS záznam _xmpp-server._tcp.firma.cz. Tento záznam jim oznámí adresu XMPP serveru a port na kterém poslouchá (pokud ale nepoužijeme standardní, tak mohou vzniknout problémy). Tím získá náš server informaci, s jakým cílovým serverem se spojit. Musíme tedy vytvořit SRV záznam, do kterého zadáme DNS jméno Access Edge Lyncu a port 5269.

_xmpp-server._tcp.firma.cz, sip.firma.cz, 5269

Konfigurace XMPP federace

Pokud nemáme federaci obecně povolenou, tak musíme nastavit, třeba pomocí Lync Server Control Panel. Nastavení se nachází pod Federation and External Access, kde upravíme External Access Policy a Access Edge Configuration.

Potom musíme pro každou XMPP doménu vytvořit záznam. V Control Panel jde o záložku XMPP Federated Partner. Nebo můžeme použít PowerShell cmdlet. V příkladu nastavujeme povolení pro Google Talk.

New-CsXmppAllowedPartner gmail.com -TlsNegotiation NotSupported -SaslNegotiation NotSupported -EnableKeepAlive $false -SupportDialbackNegotiation $true

Při zadávání federovaného XMPP partnera musíme nastavit několik důležitých hodnot.

Partner type - definuje důvěru vůči doméně, určuje oprávnění pro kontakty

• Federated - vysoký stupeň důvěry, doporučeno pro komunikaci se servery uvnitř stejné organizace nebo s partnerskou organizací, XMPP kontakt může přidat Lync kontakt (bez nutné autorizace), vidět presence a uživatelský status a posílat zprávy komukoliv na Lyncu
• Public verified - veřejný XMPP poskytovatel, kde důvěřujeme jeho uživatelům, stejná práva jako Federated, pouze nevidí uživatelský status, toto nastavení se nedoporučuje
• Public unverified- není ověřena identita uživatelů sítě, nemohou komunikovat s uživateli Lyncu pokud je Lync uživatel neautorizuje tím, že si je přidá do seznamu kontaktů, toto nastavení se doporučuje pro Google Talk apod.

TLS Negotiation - Transport Layer Security (TLS), vyjednává šifrování komunikace pomocí certifikátů, využívá se TLS rozšíření STARTTLS

• Required - je požadováno
• Optional - znamená, že TLS je mandatory-to-negotiate
• Not Supported - nepoužije se

SASL negotiation - Software Authentication and Security Layer (SASL), vyjednává způsob autentizace mezi servery, při použití SASL je povinné TLS

• Required - je požadováno
• Optional - znamená, že SASL je mandatory-to-negotiate
• Not Supported - nepoužije se

Dialback negotiation - využívá DNS a spolehlivý server pro ověření, že požadavek pochází od důvěryhodného XMPP partnera, vždy musí být nastaveno Dialback nebo SASL

Možné kombinace výše uvedených parametrů obsahuje tabulka Negotiation Settings for XMPP Federated Partners.

Hledání problémů a testování

Pokud se nám nedaří spojení s XMPP serverem, tak přijde na řadu kontrola nastavení a funkčnosti jednotlivých částí. Nejprve se asi podíváme do logu na Lync Edge serveru, jestli není zaznamenána nějaká jasná chyba. Logy nalezneme v Event Viewer - Applications and Services Logs - Lync Server.

Na Edge serveru můžeme zkontrolovat, že nám server poslouchá na obou potřebných portech.

netstat -ano | findstr 5269
netstat -ano | findstr 23456

Dále můžeme zkontrolovat, že existuje náš SRV záznam a má správné hodnoty.

C:\>nslookup
> set type=srv
> _xmpp-server._tcp.firma.com

Z Edge serveru můžeme zkusit, že je na FW povolena komunikace do internetu na port 5269. Například zjistíme adresu XMPP serveru Google a pak se zkusíme spojit (výsledkem musí být navázání session a ne timeout či connect failed).

telnet xmpp-server.l.google.com 5269

Tady je ovšem otázka, pokud jsme povolili komunikaci pouze z Access Edge rozhraní Edge serveru a do příkazové řádky zadáme výše uvedený příkaz. Tak server využije svoji nejnižší IP adresu, což může být adresa interního rozhraní. Pak nám samozřejmě komunikace neprojde. Pro zájemce o tuto problematiku podrobnější popis Source IP address selection on a Multi-Homed Windows Computer.

Stejně tak můžeme vyzkoušet, že je správně nastaveno zveřejnění našeho XMPP serveru. Odněkud z internetu nebo přímo z Edge serveru můžeme zkusit spojení.

telnet sip.firma.cz 5269

Použití propojení Lync a XMPP

Podíváme se trochu více prakticky na komunikaci mezi Lyncem a určitými XMPP servery.

Obecné chování

Podle mého krátkého testování se XMPP gateway v Lyncu nechová úplně ideálně a z uživatelského hlediska nedosahuje pohodlí, jako například při použití XMPP serveru OpenFire. Myslím tím oblast komunikace s kontakty na jiných XMPP serverech.

Mezi kontakty Lyncu a XMPP sítě se přenáší pouze základní údaje a nepřenáší se fotografie uživatele (stejný problém je i u Skype). Možná je to drobnost, ale když si člověk zvykne, že má u všech kontaktů fotku a najednou někde není, tak je to škoda.

Jestli jsem to dobře pochopil z nějakých poznámek, tak to co se mi děje v praxi je vlastnost. Kontakt si vždy musí přidat uživatel Lyncu, danému XMPP uživateli se korektně odešle žádost a pokud ji schválí, tak vše funguje. Ale když si uživatel XMPP sítě přidá náš Lync kontakt, tak nám nic nepřijde (ani se neobjeví informace na záložce NEW, jako tomu je u Skypu).

Je zde jeden velký problém, který je shodný i u federace se Skypem. Pokud si přidáme XMPP kontakt do Lyncu a třeba ani neodejde požadavek (protože máme špatně nastaveného federovaného partnera). Tak když kontakt smažeme (Remove from Contact List) a znovu přidáme, tak se již neodešle požadavek (Authorization Request).

Obecně spojení s různými doménami závisí na nastavení parametrů TLS negotiation, SASL negotiation a Dialback negotiation u XMPP Federated Partner. Pokud tyto hodnoty nenastavíme "správně", tak nám nebude komunikace fungovat. U jiných XMPP serverů (než Lync) nic takového nenastavujeme a vše funguje.

Google Talk

Častý cíl, s kým je XMPP federace požadována, je Google Talk. Microsoft přímo v dokumentaci uvádí, že Google je XMPP partner, s kterým oficiálně komunikaci testují a některé návody jsou zaměřeny právě na nastavení pro Google Talk.

Doporučené nastavení je TLS negotiation Not Supported, SASL negotiation Not Supported a Dialback negotiation True.

Řada lidí na internetu uvádí, že mají problémy se spojením na Google Talk. Údajně začal Google blokovat určitou XMPP komunikaci. Zmínky jsou například Google Blocking XMPP Invites From Federated Partners, Google Talk - XMPP Federation. Mě ovšem v současnosti vše funguje, jak bych očekával (viz omezení popsána v předchozí kapitole).

V Lync klientovi dáme hledat adresu GTalk uživatele a přidáme si jej do seznamu kontaktů. Kontakt se zobrazí s neznámou presence a označený jako External Network.

Přidáním kontaktu (nebo pokusem o zaslání zprávy) přijde na Google žádost. Pokud žádost odsouhlasíme, tak budeme mít kontakt na obou stranách, budeme si moci psát a uvidíme presence (hned po přidání se mi nezobrazovala správně na straně Lyncu, ale po první změně stavu vše začalo fungovat).

Můžeme se pokusit přidat Lync kontakt do Google Talku, ale na Lync nic nedorazí a nic se nestane. Přesto se toto přidání může hodit, pokud máme problémy, tak přidáme kontakt z obou stran a to někdy pomůže.

Jabber.cz, Jabbim.cz

Jeden z Českých (populárních) veřejných poskytovatelů XMPP služeb je JabbIM. Tato služba vlastní řadu domén jako jabber.cz, jabbim.cz, njs.netlab.cz atd., na kterých si můžeme zdarma vytvořit Jabber účet. Podle údajů na xmpp.net využívá server software ejabberd a certifikát od CAcert.org (zde je možno získat zdarma certifikát).

Nejprve jsem zkusil nastavení TLS negotiation Optional, SASL negotiation Optional a Dialback negotiation True. Komunikace nefungovalo a do logu Lync Edge serveru se zapisovalo několik varování.

EventID 39015 The XMPP Translating Gateway Proxy failed to validate a remote certificate during
 TLS negotiation. Failure: The remote certificate failed to pass certificate revocation list check.
EventID 39014 The XMPP Translating Gateway Proxy encountered an error communicating with a remote server.
EventID 39013 The XMPP Translating Gateway Proxy failed to send a stanza to a remote server.

Vyzkoušel jsem tedy nepoužít SASL over TLS, ale TCP Dialback a pak již komunikace fungovala. Nastavení parametrů TLS negotiation Not Supported, SASL negotiation Not Supported a Dialback negotiation True.

Po přidání kontaktu do Lyncu přijde na XMPP klienta standardní požadavek.

wtfismyip.com

Chtěl jsem vyzkoušet ještě jiného XMPP poskytovatele, tak jsem nalezl wtfismyip.com. Server využívá také software ejabberd a certifikát od StartSSL (další CA, kde je možno získat certifikát zdarma).

S nastavením parametrů TLS negotiation Optional, SASL negotiation Optional a Dialback negotiation True vše fungovalo bez problémů.