LyncDiscover Client / Autodiscover

ähnlich wie Outlook und ActiveSync Client den Weg zum Postfach über Autodiscover automatisch allein anhand der SMTP-Adresse ermitteln können, kann auch ein Lync Client anhand der SIP-Adresse den Zugang zum Lync System finden. Lange Zeit waren dazu DNS-Einträge das Mittel der Wahl um den Client zum Server zu lenken. Einen alternativen Weg über "Lyncdiscover" haben die mobilen Clients für Lync 2010 und höher eingeführt und dieser Weg wird mittlerweile auch vom Lync 2013 Communicator als auch der Windows Store App verwendet. Diese Seite beleuchtet die Hintergründe.

Lync 2013: Determine DNS Requirement
http://technet.microsoft.com/en-us/library/gg398758.aspx

Warum der Wechsel ?

Zuerst habe mich mich natürlich gefragt, warum Microsoft eine neue Methode ersonnen hat, um dem Client den Weg zum Server zu eröffnen. Die Nutzung von SRV-Records hat doch wunderbar funktioniert. Das ist aber nur die halbe Wahrheit. Es gab durchaus Argumente von den SRV-Records abstand zu nehmen, z.B.

  • SRV-Records und DSL-Router
    Es mag unglaubwürdig klingen aber es gibt durchaus DNS-Forwarder, die keine SRV-Records verstehen. Es besteht daher durchaus ein Risiko, dass eine SRV-Record hinter einer Firewall oder einem DSL-Router nicht aufgelöst werden können.
  • SRV-Einträge im externen DNS-Server
    Nicht alle Firmen verwalten ihre DNS-Zone auf ihrem lokalen Server sondern nutzen eine DNS-Dienstleister. Und da gibt es durchaus Dienste, die es einfach nicht erlauben SRV-Records anzulegen. Sicher kann man immer noch mit "SIP.<sipdomain>" als Fallback arbeiten aber hier sind keine Prioritäten möglich.
  • SRV-Records und Windows 8.1 Store Apps
    Ich habe es nicht selbst geprüft, aber angeblich können Windows 8.1 Store Apps keine SRV-Records auflösen. Damit ist zumindest der Lync App Client auf A-Records und Lyncdiscover angewiesen
  • Hybrid-Mode
    Wenn ihre Benutzer z.B. sowohl auf Lync On-Premises als auch in der Office 365 Cloud sind, dann leitet der DNS-Eintrag den Anwender auf den On-Prem-Edge. Der Client muss sich da erst mal anmelden ehe er dann einen Redirect auf die Cloud erhält. Da kann eine Anfrage per HTTP viel schnelle den "richtigen" Zugangspunkt für einen User in der anderen Welt liefern.
  • Sicherheit
    DNS-Anfragen kann jeder stellen. Eine Lyncdiscover-Abfrage erwartet eine Authentifizierung. Der Sicherheitsgewin ist aber gering. Auch eine Sicherung per HTTPS ist gegenüber einem DNS-Records nicht vorhanden, da hier dann auch bei der Datenverbindung mit SIP/TLS gearbeitet wird
  • Datenumfang
    Per DNS und Zugriff auf den Edge/SIP-Server ist aber auf jeden Fall erst einmal ein SIP-Stack erforderlich. Dienst wie UCWA, die nur HTTP sprechen, müssten dazu mit Code aufgebläht werden, der gar nicht erforderlich ist.

Es gibt also schon den ein oder anderen Grund, warum ein DNS-Eintrag, der auf einen SIP-Server verweist, nicht mehr ausreichend ist. Letztlich können wir schimpfen aber es nicht ändern, so dass wir und überlegen müssen, wie diese neue Herausforderung integriert wird.

Intern und Extern

Eine Schlüsselkomponenten ist die Möglichkeit des Clients sehr früh zu unterscheiden, ob er "intern" oder "extern" ist, d.h. ob er im in internen gerouteten LAN ist und vermutlich keine Firewall die Kommunikation behindert und z.B. Kerberos verfügbar ist oder ob er von extern über Tunneltechnologien und strengere Zertifikatchecks eine Verbindung aufbauen muss. Outlook und Exchange unterscheiden hier erst einmal nicht. Autodiscover liefert einfach die internen und externen URLs und der Client versucht dann eine Verbindung.

Bei Lync werden für die interne Auflösung zusätzliche DNS-Einträge verwendet, die idealerweise aus dem Internet nicht auflösbar sind. Das widerspricht nicht der Funktion, dass ein Mobilclient über Lyncdiscoverinternal.<sipdomain> intern den Lync Pool erreicht und dann in der Antwort dennoch externe URLs bekommt. Das ist erforderlich, damit gerade die "springenden Clients", die mal intern mal extern sind, immer über den gleichen Weg zum Server kommen und so Sessions weiter verwendet werden können.

Lync Client prüfen also immer zuerst die "Internen" Namen, ehe sie dann die externen Namen abfragen.

Wenn Sie keinen SplitDNS nutzen, dann schauen Sie sich die Option PinpointDNS / Geo-DNS an.

Viele Firmen nutzen intern für das Active Directory eine "private Zone", z.B. "domain.intern" und der interne DNS-Server betreibt auch nur diese Zone. Die offizielle DNS-Zone, die auch für die Bildung der SIP-Adressen und Mail-Adressen zuständig ist. wird aber nur im Internet "gehostet". Dann ist es ungünstig in dieser externen Zone auch die internen Namen zu veröffentliche. Dabei stört weniger die "Sichtbarkeit" der internen Namen, da Sicherheit durch eine korrekte Konfiguration und Firewalls erreicht wird und nicht durch "Verbergen". Aber es stört das ein externer Client ohne direkten Zugriff auf die internen Server dennoch die internen Namen auflösen kann und daher einige Zeit versucht so die Dienste zu erreichen.

In so einem Fall ist es besser in der externen Zone auch nur externen DNS-Einträge vorzunehmen und von intern die Zone als Kopie parallel zu führen (SpitDNS/Split Brain DNS, DNS) und dort die internen Einträge zu addieren. Alternativ können Sie zumindest für die A-Records auch mit PinpointDNS die internen Einträge nur von intern auflösbar machen.

Abfragen und Clients

Nicht alle Lync Clients verhalten sich gleich. Je nach Client kommt das eine, das andere oder sogar beide Verfahren zum Einsatz. Die Clients arbeiten die Optionen von oben nach unten ab und sobald ein "Match" vorhanden ist, wird diese Option gezogen und weitere nicht mehr evaluiert. Ein Lync 2013 Client, bei dem ich Lyncdisover und Lyncdiscoverinternal per "hosts"-Datei ins Leere gesendet habe, zeigen im Fiddler sehr gut, dass sie zuerst intern per HTTP und dann per HTTPS eine Verbindung versuchen und dann extern:

Die letzte Antwort enthält als JSON-Struktur die Daten für den Anwender:

Microsoft beschreibt dies auch auf der TechNet:

The decision about whether to use subject alternative name lists on reverse proxies is based on whether you publish the Autodiscover Service on port 80 or on port 443:

 "Initial Autodiscover Process using Port 80

 we support the initial automatic discovery connection over port 80, which is then redirected to port 8080 on the Director or Front End Server.

Quelle: http://technet.microsoft.com/en-us/library/jj945616.aspx

Wenn man mit NetMon 3 oder Wireshark die DNS-Anfragen für eine nicht existente SIP-Domain mitschneidet, wird auch ersichtlich, welche Abfolge der Lync 2013 Client durchläuft:

Das ganze lässt sich dann in eine Tabelle bringen, in der pro Client die Zugriffe aufgezeigt werden.

Protokoll Record Name Lync
2010
Win		 Lync
Mac		 Lync
2013
Win		 Lync Mobile
IOS/WP/Android		 Lync Phone
(Aries)		 Lync
StoreApp
(Win RT)		 LyncWeb
App		 UCWA

http

A

lyncdiscoverinternal.<sipdomain>

Nein

Nein

Ja

Ja

Nein

Ja

Ja

Ja

https

A

lyncdiscoverinternal.<sipdomain>

Nein

Nein

Ja

Ja

Nein

Ja

Ja

Ja

http

A

lyncdiscover.<sipdomain>

Nein

Nein

Ja

Ja

Nein

Ja

Ja

Ja

https

A

lyncdiscover.<sipdomain>

Nein

Nein

Ja

Ja

Nein

Ja

Ja

Ja

sip/TLS

SRV

_sipinternalstls._tcp.<sipdomain>

Ja

Ja

Ja

Nein

Ja

Nein

Nein

Nein

sip/TLS

SRV

_sip._tls.<sipdomain>

Ja

Ja

Ja

Nein

Ja

Nein

Nein

Nein

sip/TLS

A

sipinternal.<sipdomain>

Ja

Ja

Ja

Nein

Ja

Nein

Nein

Nein

sip/TLS

A

sip.<sipdomain>

Ja

Ja

Ja

Nein

Ja

Nein

Nein

Nein

sip/TLS

A

sipexternal.<sipdomain>

Ja

Ja

Ja

Nein

Ja

Nein

Nein

Nein

Es ist ebenfalls gut zu sehen, dass Einträge von OCS, z. B. _SIP._TCP gar nicht mehr abgefragt werden.

Die Tabelle gibt den Stand Jul 2014 wieder. Updates auf dem Client können das Verhalten ändern.

Lyncdiscover, Zertifikate und Redirect

Wenn immer mehr als eine SIP-Domain ins Spiel kommt, stellt sich die Frage der Zertifikate. Auf der Seite Viele SIP-Domains habe ich das Thema aus der Brille eines Hosters beleuchtet und Firmen mit vielen SIP-Domains haben durchaus die gleiche "Herausforderung".

Die Auflösung über LyncDiscover erlaubt dem Client nun per HTTP eine Verbindung zum Server aufzubauen, der dann ohne Zertifikatsprobleme bei einem Lync Server landen kann und per JSON-Antwort natürlich die weitere Daten erhält. Beim Zugriff per _sipinternaltls._tcp.<sipdomain> ist es bislang immer erforderlich, dass das Zertifikat auch einen Hostnamen mit der SIP-Domäne enthält oder auf dem Client eine "TrustModelData" gepflegt wird.

Das ist bei Lyncdiscover leider nicht anders. Wenn der Zugriff per HTTPS erfolgt und der Name nicht im Zertifikat ist, dann bekommt der Client eine Zertifikatswarnung. Die ist unerwünscht und sollte nicht genutzt werden.

Fordern Sie bitte nie einen Anwender auf, eine Zertifikatwarnung zu ignorieren.

Wenn Sie aber Lyncdiscover per HTTP nutzen, dann entfällt zwar die Zertifikatwarnung aber wenn der Hostname der LyncWeb-Dienste in einer anderen Domäne ist, dann bekommt der Client einen Hinweis, dass seine Anfrage "umgeleitet" wird. Hier z.B. ein Lync 2013 Communicator und einem Lync Mobile auf IOS.

Diese Meldung sollten die Anwender können und bestätigen. Auf Windows Clients können Sie diese Meldung durch eine Gruppenrichtlinie vermeiden, indem Sie über den Schlüssel "TrustedModelData" addieren.

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Communicator\TrustedModelData

Wenn der Anwender bei der Rückfrage zustimmt, trägt der Communicator die Adresse an folgender Stelle ein.

HKEY_CURRENT_User\Software\Microsoft\Communicator\<sipaddress>\TrustModelData

Leider kann so eine "Vorgabe" nicht auf dem mobilen Client hinterlegt werden. Hier ist es als "Normal", dass die "Umleitungswarnung" kommt.

Lync Discover "Antwort"

Es ist relativ einfach, eine LyncDiscover-Anfrage zu analysieren. Die erste Anfrage ist eine HTTP-Anfrage um die Zugänge zu erhalten. Das können Sie auch mit einem Browser einfach durchführen.

http://lyncdiscover.netatwork.de/?sipuri=Useristegal@netatwork.de

Die Antwort ist einen XML-Struktur, die dem Client die weiteren URLs vorgibt

Damit kann der Client dann direkt diese URLs weiter ansprechen um die übrigen Daten zu ermitteln. Um dann die HTTPS-Anfragen zu analysieren ist wieder Fiddler das Mittel der Wahl. Sehr viel einfacher geht aber der Zugriff z.B., mit dem :Lync Connectivity Analyser, welcher nach Eingabe der Daten ebenfalls die Checks durchführt und die Ergebnisse anzeigt:

 

Hinweis: Die Daten sind nur bedingt "geheim". Die meisten Informationen lassen sich auch lyncdiscover auch anonym ermitteln. Genau genommen ist es nur der interne Name des Lync Server, der nur als authentifizierter Benutzer ermittelt werden kann. Der Server ist aber sowieso nicht aus dem Internet erreichbar.

LyncDiscover Konfigurationsplanung

Webseiten unterliegen oft eine Änderung und das folgende Diagramm habe ich auf "Determine DNS Requirement" (http://technet.microsoft.com/en-us/library/gg398758.aspx) gefunden und hier als Kopie bereitgestellt. Es beschreibt sehr gut den Ablauf bei einem Lync 2013 Client.

Ich habe das Bild allerdings etwas gestaucht.

LyncDiscover Ablauf

Ausgehend von dem obigen Flussdiagramm und den Ausführungen können Sie ja schon erahnen, was Lync beim Start treibt. Um nicht alles erneut zu beschreiben, habe ich hier ein paar Links gesetzt, die mehr oder weniger alle das Gleiche beschreiben.

Deep Dive Into The Microsoft Lync 2013 Client Sign In Process
http://channel9.msdn.com/events/TechEd/NorthAmerica/2014/OFC-B412
http://channel9.msdn.com/events/Lync-Conference/Lync-Conference-2014/CLNT400

Deep Dive Into The Microsoft Lync 2013 Client Sign In Process
https://www.youtube.com/watch?v=hRMDjv7pAGM 

Weitere Links