Lync Client Zertifikate

Die folgende Seite soll am Beispiel einer Anmeldung eines Lync Clients zeigen, wie ein Client zu gültigen Anmeldedaten und Zertifikaten kommt.

Wenn Sie Informationen zu den Serverzertifikaten suchen, dann ist die Lync Zertifikate wichtig

Namensauflösung

Zuerst muss der Client natürlich wissen, wo er einen Lync Server findet. Üblicherweise nutzen wir dazu DNS, damit eine "automatische Konfiguration" für möglichst viele Clients möglich ist. Wenn es der Client zulässt, können die Lync-Server-Adressen aber auch statisch hinterlegt werden oder sogar per Gruppenrichtlinie (Windows) oder DHCP-Option (Lync Phone) vorgegeben werden. Über den Namen des Servers oder Pools kommt der Client dann zu einer IP-Adresse. Einige Clients nutzen noch Optionen, um z.B. die Uhrzeit per NTP in Erfahrung zu bringen.

Erste erfolglose Anmeldung per SIP

Aber dann geht er schon direkt an den Pool und möchte sich anmelden. Hier ein Beispiel meines Lync 2013 Clients auf Windows 7 von extern

REGISTER sip:msxfaq.de SIP/2.0
Via: SIP/2.0/TLS 2.200.56.245:36299
Max-Forwards: 70
From: <sip:User1@msxfaq.de>;tag=c5e826a828;epid=2385f4c267
To: <sip:User1@msxfaq.de>
Call-ID: c7311426f0604bc3b2517cf72dbe956c
CSeq: 9 REGISTER
Contact: <sip:2.200.56.245:36299;transport=tls;ms-opaque=77a6d4f9c0>;
   methods="INVITE, MESSAGE, INFO, OPTIONS, BYE, CANCEL, NOTIFY, ACK, REFER, BENOTIFY";
   proxy=replace;+sip.instance="<urn:uuid:C2AC9957-2D32-5C48-87C9-E8F8BCB0CD28>" User-Agent: UCCAPI/15.0.4517.1504 OC/15.0.4517.1504 (Microsoft Lync)
Supported: gruu-10, adhoclist, msrtc-event-categories
Supported: ms-forking
Supported: ms-cluster-failover
Supported: ms-Userservices-state-notification
ms-keep-alive: uAC;hop-hop=yes
Event: registration
ms-subnet: 2.200.56.244
Content-Length: 0

In dem REGISTER fehlt natürlich komplett die Anmeldung. Insofern ist nur verständlich, dass der Server den Wunsch ablehnt. Aber er informiert mich, welche Verfahren ich zur Anmeldung nutzen kann. Hier ist es NTLM und TLS-DSK.

SIP/2.0 401 unauthorized
ms-User-logon-data: RemoteUser
Date: Tue, 10 Sep 2013 14:07:51 GMT
WWW-Authenticate: NTLM realm="SIP Communications Service", targetname="NAWLYNC001.msxfaq.de", version=4
WWW-Authenticate: TLS-DSK realm="SIP Communications Service", targetname="NAWLYNC001.msxfaq.de", version=4, 
                sts-uri="https://lync.msxfaq.de:443/CertProv/CertProvisioningService.svc"
From: <sip:User1@msxfaq.de>;tag=c5e826a828;epid=2385f4c267
To: <sip:User1@msxfaq.de>;tag=56F569001EB609644C7C3179016F5D0B
Call-ID: c7311426f0604bc3b2517cf72dbe956c
CSeq: 9 REGISTER
Via: SIP/2.0/TLS 2.200.56.245:36299;ms-received-port=36299;ms-received-cid=7079900
Server: RTC/5.0
Content-Length: 0
ms-diagnostics: 1033;reason="Previous hop server component did not report diagnostic information";
   Domain="msxfaq.de";PeerServer="nawlync001.msxfaq.de";source="sip.msxfaq.de"
ms-diagnostics-public: 1033;reason="Previous hop server component did not report diagnostic information";
   Domain="msxfaq.de";PeerServer="nawlync001.msxfaq.de"

Anfordern eines Zertifikats

Nun ist es an dem Client sich ein Zertifikat zu beschaffen. Die URL habe ich im "401 unauthorized" schon mit bekommen, so dass der Client nun diese URL nutzt, um über die Lync-WebDienste sich ein Zertifikat ausstellen zu lassen. Der Client rechnet also selbst ein Zertifikat und reicht den PublicKey über den Webservice an den Lync Pool ein. Auch das geht natürlich nicht anonym. Mein Client meldet sich also an der "Lync External Webseite" über die angebotenen Anmeldeverfahren an und bekommt hoffentlich ein Zertifikat. Diese Zugriffe sehen Sie natürlich im IISLog des Lync Pools.

Zuerst holt sich der Client die Servicebeschreibung für den WebService. Die wird mit einem 200 ausgeliefert

POST /CertProv/CertProvisioningService.svc/mex - 4443 - 192.168.100.12 OC/15.0.4517.1504+(Microsoft+Lync) - 200 0 0 256

In der Antwort XML-Datei (Versuchen Sie mal https://join.microsoft.com/CertProv/CertProvisioningService.svc/mex) können Sie erkennen, dass der Webservice eine Anmeldung erfordert und dazu ein OAUTH-Token erforderlich ist, welches der Client unter anderen URL bekommt.

Der Client muss sich also nun die Servicebeschreibung des WebTicketService holen und ein Ticket besorgen

POST /WebTicket/WebTicketService.svc/mex - 4443 - 192.168.100.12 OC/15.0.4517.1504+(Microsoft+Lync) - 200 0 0 44
POST /WebTicket/WebTicketService.svc - 4443 - 192.168.100.12 OC/15.0.4517.1504+(Microsoft+Lync) - 401 1 2148074254 2
POST /WebTicket/WebTicketService.svc - 4443 User1@msxfaq.de 192.168.100.12 OC/15.0.4517.1504+(Microsoft+Lync) - 200 0 0 73
GET /WebTicket/Issuer/ purpose=proof 4443 - 192.168.100.100 - - 200 0 0 99

Auch diese Servicebeschreibung können Sie einfach mal anfordern

https://join.microsoft.com/WebTicket/WebTicketService.svc/mex

Erst jetzt kann der Client mit dem Ticket einen POST absetzen um seine Zertifikatsanfrage zu stellen und das Zertifikat zu bekommen.

POST /CertProv/CertProvisioningService.svc/WebTicket_Proof - 4443 - 192.168.100.12 OC/15.0.4517.1504+(Microsoft+Lync) - 200 0 0 757

Hier sieht man aber genauer, dass es nicht mit einem Request getan ist, sondern der Client muss erst noch mal eine weitere Ehrenrunde über den WebTicketService.svc laufen. Dann greift der Client auf den Dienst zu, bekommt aber einen 401.1 mit den Informationen, wie er sich Anmelden kann. Erst dann kommt hier der richtige authentifizierte Zugriff, was sie am Usernamen erkennen können

Leider zeigt sich auf dem Lync Client selbst überhaupt keine Meldung im "Lync-UccApi-0.UccApilog". Nun könnte man sagen, dass das ja auch kein SIP-Traffic ist aber es erschwert natürlich die Fehlersuche auf dem Client, wenn der Communicator diese Kommunikation nicht protokolliert.

Erfolgskontrolle

Der Lync Server speichert das Zertifikat in der Pool-Datenbank beim Benutzer. Das können Sie einfach auslesen:

PS C:\> Get-CsClientCertificate User1@msxfaq.de

Identity        : sip:User1@msxfaq.de
CertificateType : OcsSigned
DeviceId        : {375da200-f2d3-5fd2-847f-1b14c5a9b20c}
PublicationTime : 3/15/2013 3:21:29 PM
ExpirationTime  : 9/11/2013 5:06:29 PM

Identity        : sip:User1@msxfaq.de
CertificateType : OcsSigned
DeviceId        : {48513bdd-88b6-5188-bd2d-269bc1b0841b}
PublicationTime : 5/24/2013 11:54:11 AM
ExpirationTime  : 11/20/2013 12:39:10 PM

Identity        : sip:User1@msxfaq.de
CertificateType : OcsSigned
DeviceId        : {844298fb-f1c0-544d-b7bd-452ae24ca176}
PublicationTime : 9/9/2013 11:35:01 AM
ExpirationTime  : 3/8/2014 12:20:01 PM

Identity        : sip:User1@msxfaq.de
CertificateType : OcsSigned
DeviceId        : {6a67b0ee-d47a-5225-99b3-4b32076f5a3f}
PublicationTime : 6/17/2013 9:18:14 AM
ExpirationTime  : 12/14/2013 10:03:14 AM

In der Datenbank enthaltene Zertifikate können Sie per Lync PowerShell aber auch per Lync Control Panel entfernen.

Ob der Client ein Zertifikat erhalten hat, können Sie auf einem Windows PC einfach in der MMC für Zertifikate prüfen.

Wer es lieber per PowerShell macht, kann auch das tun:

PS C:\> get-childitem  Cert:\CurrentUser\My\ | ?{$_.issuer -eq "CN=Communications Server"} | ft subject,not* -AutoSize

Subject                      NotAfter            NotBefore
-------                      --------            ---------
CN=User1@msxfaq.de 14.12.2013 10:03:14 17.06.2013 11:03:14
CN=User1@msxfaq.de 07.08.2013 13:31:04 08.02.2013 12:31:04
CN=User1@msxfaq.de 20.03.2013 10:18:29 21.09.2012 11:18:29
CN=User1@msxfaq.de 26.02.2013 16:08:10 30.08.2012 17:08:10
CN=User1@msxfaq.de 17.12.2013 07:18:21 20.06.2013 08:18:21

Diese Zertifikate sind 6 Monate gültig. Normalerweise werden diese aber auch nur alle sechs Monate erneuert. In meinem Beispiel habe ich aber auf dem Server Zertifikate gelöscht, so dass ich eben früher neue bekommen habe.

Zertifikatkonflikt

Die Ablage der Zertifikate im Benutzerspeicher hat einen unschönen Effekt: Wenn Sie z.B. sich bei einem WiFi Anmelden, welches mit Client-Zertifikaten arbeitet, dann bietet ihnen der Auswahlassistenz für die Zertifikate eventuell auch das Lync-Zertifikate an. Das ist soweit verständlich, das der Windows Client nach Zertifikaten zur Authentifizierung sucht und dazu gehört das Lync Zertifikate. Wenn der WiFi-AP zur Anmeldungsaufforderung keine Liste der vertrauenswürdigen Stammzertifizierungsstellen mit sendet, dann kann der Client das Lync Zertifikat nicht herausfiltern.

Der WiFi-Client durchsucht aber nur den persönlichen Speicher unter "Zertifikate - Eigene Zertifikate - Zertifikate"

Wer genau hinschaut findet aber auch einen "LyncCertStore"-Eintrag. Der Lync Client kann auch dort Zertifikate ablegen und von dort lesen. Allerdings ist dazu ein Registrierungsschlüssel bzw. eine Policy erforderlich, damit neue Zertifikate auch dort abgelegt werden.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Office\15.0\Lync]
"UseLyncCertStore"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Office\16.0\Lync]
"UseLyncCertStore"=dword:00000001

Danach schreibt Lync/Skype für Business die Zertifikate in den neuen Bereich und sie stören nicht mehr bei einer 802.1x Authentifizierung oder Anmeldung an Webseiten mit User-Zertifikaten:

Ich frage mich natürlich, warum Microsoft diese Logik nicht zum Default gemacht hat und man erst per Policy diese Verhalten aktivieren muss

Anmeldung per SIP

Und dann das ganze bitte noch mal aber diesmal mit einem Zufallswert, der durch den private Key signiert wurde. (nur die letzte Antwort)

REGISTER sip:msxfaq.de SIP/2.0
Via: SIP/2.0/TLS 2.200.56.245:36299
Max-Forwards: 70
From: <sip:User1@msxfaq.de>;tag=c5e826a828;epid=2385f4c267
To: <sip:User1@msxfaq.de>
Call-ID: c7311426f0604bc3b2517cf72dbe956c
CSeq: 13 REGISTER
Contact: <sip:2.200.56.245:36299;transport=tls;ms-opaque=77a6d4f9c0>;
   methods="INVITE, MESSAGE, INFO, OPTIONS, BYE, CANCEL, NOTIFY, ACK, REFER, BENOTIFY";
   proxy=replace;+sip.instance="<urn:uuid:C2AC9957-2D32-5C48-87C9-E8F8BCB0CD28>" User-Agent: UCCAPI/15.0.4517.1504 OC/15.0.4517.1504 (Microsoft Lync)
Supported: gruu-10, adhoclist, msrtc-event-categories
Supported: ms-forking
Supported: ms-cluster-failover
Supported: ms-Userservices-state-notification
ms-keep-alive: uAC;hop-hop=yes
Event: registration
ms-subnet: 2.200.56.244
Proxy-Authorization: TLS-DSK qop="auth", realm="SIP Communications Service", 
   opaque="B24DFAAE", targetname="NAWLYNC001.msxfaq.de", crand="a4993ebc", 
   cnum="1278", response="1ae25e33e76918d931c5d65d2711d3a91506d79e"
Content-Length: 0

Der Server kann dann mit dem in der Datenbank hinterlegten PublicKey sicherstellen, dass ich es wirklich bin. Dann kommt auch das 200 OK

SIP/2.0 200 OK
ms-User-logon-data: RemoteUser
ms-keep-alive: uAS; tcp=no; hop-hop=yes; end-end=no; timeout=300
Authentication-Info: TLS-DSK qop="auth", opaque="B24DFAAE", srand="FDCF28DB",
   snum="1267", rspauth="08b804584258245", targetname="NAWLYNC001.msxfaq.de", 
   realm="SIP Communications Service", version=4
From: "Carius, Frank"<sip:User1@msxfaq.de>;tag=c5e826a828;epid=2385f4c267
To: <sip:User1@msxfaq.de>;tag=56F569001EB6
Call-ID: c7311426f0604bc3b2517cf72dbe956c
CSeq: 13 REGISTER
Via: SIP/2.0/TLS 2.200.56.245:36299;ms-received-port=36299;ms-received-cid=7079900
Record-Route: <deleted>
Path: <deleted>
Contact: <deleted>
Contact: <deleted>
Contact: <deleted>
Contact: <deleted>
presence-state: register-action="refreshed";primary-cluster-type="central";is-connected-to-primary="yes"
Expires: 7200
Allow-Events: vnd-microsoft-provisioning,vnd-microsoft-roaming-contacts,
    vnd-microsoft-roaming-ACL,presence,presence.wpending,vnd-microsoft-roaming-self,vnd-microsoft-provisioning-v2
Supported: adhoclist
Server: RTC/5.0
Supported: msrtc-event-categories
Supported: ms-keepalive-deregister
Supported: ms-Userservices-state-notification
Content-Length: 0

Ich habe hier ein paar Pakete zur Übersichtlichkeit entfallen lassen. Wenn Sie mit Snooper das Logfile anzeigen, dann sehen Sie immer drei fehlgeschlagene "REGISTER", eher erst der vierte Versucht ein OK liefert.

Die HTTPS-Anfragen an den Webservice um das Zertifikat zu erhalten, ist allerdings kein SIP-Paket und daher hier nicht sichtbar. Die Folgepakete sind dann natürlich die Anforderungen zu den Policies, Buddyliste etc. die mit der eigentlichen Anmeldung nichts mehr zu tun haben.

Warum das Ganze ?

Nun könnte man sich fragen, warum Microsoft diesen Weg gewählt hat. Der "Umweg" über einen WebService und lokale Zertifikate ist erst mal komplexer und damit störanfälliger. Dennoch gibt es einige Gründe, die genau diesen Aufwand sinnvoll sein lassen. Hier eine Auwahl:

  • Performance: Weniger Anmeldetraffic auf dem DC
    SIP sind sehr viele kleine Pakete und Verbindungen und wenn viele Clients sich anmelden und der Lync Server dazu einen DC per NTLM fragen muss, dann kann das ein Ressourcenengpass werden. Der Einsatz von Kerberostickets funktioniert nur mit Clients, an denen ein AD-Konto angemeldet ist und die an den KDC kommen. Das ist für mobile Anwender schon mal gar nicht möglich.
    Die zusätzliche Rückfrage beim DC würde zudem Zeit kosten. Ein Grund warum Kerberos bei vielen anderen Diensten von Vorteil ist.
  • Sicherheit: Keine lokal gespeicherten Kennworte und Pin Auth
    Wollen Sie auf einem Telefon morgens immer ihr Kennwort eingeben? Ein Zertifikat erspart ihnen das. Zudem kann der WebService auch andere Authentifizierungsverfahren unterstützen. So ist es erst möglich, dass z.B. ein LyncPhone sich auch mit Durchwahl und PIN anmelden kann. Der WebService kann unabhängig von einer AD-Authentifizierung die übermittelten Daten prüfen und das Zertifikat ausstellen
  • Sicherheit: Anwendungsspezifische Anmeldung
    Das Zertifikat eignet sich nur zur Anmeldung an der Lync-Umgebung, von der es ausgestellt wurde. Zumindest wüsste ich nicht, warum irgend jemand anderes diesem Zertifikat einer nicht vertrauenswürdigen CA vertrauen sollte. Insofern kann jemand, der das Zertifikat entwendet, nicht wirklich viel damit anfangen außer damit IMs zu senden und zu telefonieren. Er hat aber keinen Zugriff auf Dateiserver, Postfächer o.ä.
  • Funktioniert auch nach KennwortÄnderung
    Das Zertifikat ist 6 Monate gültig. Wenn Sie ihr Kennwort in der Windows Domäne ändern, wird das Zertifikat davon nicht berührt. Ein Telefon oder Lync-Client kann sich also unbehelligt weiter damit anmelden und arbeiten
  • Funktioniert ohne DC (SBA, WAN-Link)
    Wenn keine Rückfrage an einen DC erforderlich ist, dann vereinfacht dies natürlich auch die Bereitstellung in kleineren Standorten, in denen z.B.: kein Domaincontroller installiert ist. Das ist der klassische Ort für eine SBA, die auch beim Ausfall der WAN-Leitung weiter die Basistelefonie bereitstellen muss. Auch beim Pool-Failover muss kein DC erreicht werden.

Das Verfahren, dass eine Anwendung sich erst ein Zertifikat holt und lokal ablegt, ist nicht so weit verbreitet. Dass aber mit Tickets gearbeitet wird, ist bei ADFS und Office 365 schon länger üblich und kommt auch immer mehr in internen Netzwerken zum tragen, wenn über Forest-Grenzen hinweg ein Single-SignOn erfolgen soll.

Debuggen

Mit dem Wissen um die Abfolge der Anmeldung können Sie nun natürlich auch ganz einfach die Stellen ermitteln, an denen Sie nachschauen können. Zuerst sollten Sie natürlich schauen, ob Sie der Einzige mit dem Problem sind, oder andere Personen auch betroffen sind. Vielleicht ist es ja "nur" ihre Netzwerkverbindung und nicht gleich ein großes Problem.

  • MMC
    Schauen Sie in den lokalen Zertifikatspeicher, ob dort ein Zertifikat gefunden wurde
  • Lync Client Log mit Snooper
    Wenn Sie nur auf dem Client zugreifen können, hilft auch dort das Client-Logging schon weiter, um den "REGISTER" und die Rückmeldungen zu analysieren
  • IISLog und FREB
    Die Webservices können einfach im IISLog überprüft werden. Sie sollten hier den Client sehen, der nach einem ersten anonymen Zugriff mit einer 404 als Antwort dann mit einer 200-Meldung bedient wird.
  • Server Debugging mit Snooper
    Auf dem Lync Server können Sie ebenfalls ein Logging einschalten, um den Fehler einzukreisen. Speziell für die Zertifikatsdienste ist dies hilfreich, da sie hier im IISLog nicht genug sehen

Weitere Links