Skype for Business Autodiscover & Authentication–Revisited

Howdy,

It has been a while since my last “Simple Understanding” article, so as the year getting to an end, I decided to address a topic that is already address before in many great blog articles, but hay… you know me, it is important to me that my followers and readers can have everything they look for in my blog as well as I’m addressing this topic, and as I always do with my simple understanding series, I will be using non-technical words as much as I can, easy to understand phrases and explanation and of course videos shows the flow under the hood, so let’s get cracking 🙂

In this article I will revisit the Autodiscover and Authentication process of the Skype for business clients. Will start with explaining how SkypeFB client locate the frontend, then moving forward will explain the Authentication process, this will be very handy for you when troubleshooting.

Skype4b Client – Locating the Frontend

So let us say that a new Employee joined the company, got his/her new company’s laptop and sitting in the office, fired it up and started Skype for business client, wrote the SIP-address and password and clicked “Sign-In”, now what? What is happening in the background? Following video shows a step by step of the discovery mechanism that Skype for business client conduct to locate the frontend.

Skype for business client autodiscover logic

 

Note: in real life not all mentioned steps are conducted by the Skype for Business client.

So as you see in the video, the Skype4b client is designed to search for the frontend pool using pre-coded DNS records, it gets the domain name from the user’s sip-address one in red (user@sip-domain) then start adding to it pre-coded values in the following order:

  1. Lyncdiscoverinternal.sip-domain
  2. Lyncdiscover.sip-domain
  3. SRV _sipinternaltls._tcp.sip-domain
  4. SRV _sip._tls.sip-domain
  5. Sipinternal.sip-domain
  6. Sip.sip-domain
  7. Sipexternal.sip-domain

I did a test using a fake sip-domain to show you the logic in how Skype4b client discover the frontend IP-addresses, following screenshot is taken from MS Network Monitoring tool

clip_image001

When the client cannot resolve the first DNS records it tries the second one, if not then the third if not then…. Well you get the idea 🙂

Back to our example let’s consider that all your DNS requirements are there, what happens then is because the new employee sitting inside the Corp network, the client will get a response for the lyncdiscoverinternal record and then will contact the frontend pool and authenticate with it.

Locating Frontend inside Corp Network

 

In case you did not already catch on that, skype4b try to resolve either lyncdiscoverinternal or lyncdiscover which will let the client to know if it is inside or outside the Corp-Network.

Just for your information the second time the user will try to sign-in the client will go directly to the Frontend pool, not going through the whole process again unless it cannot discover the lyncdiscoverinternal or you flushed the DNS.

Skype4b Client – Authenticating

Ok so the Client successfully located the frontend, now comes the fun part, authenticating against the frontend there are a number of scenarios to consider here:

  • User inside the Corp-Network using a domain joined laptop
  • User Outside the Corp-Network using a domain joined laptop
  • User using a non domain joined laptop

before we dig in, understand that Skype for business as well as previous version of Lync uses 3 different methods of authentication:

  • Kerberos
  • NTLM
  • Certificate (TLS-DSK) << most preferred one

User Inside Corp-Network with domain joined laptop:

P.S I will be using the word “Pool” a lot, and by pool here I mean your frontend or director pool depending on your deployment type.

so this employee we are talking about above is signing in for the first time using the Active directory username and password and the client resolved the lyncdiscoverinternal DNS record successfully, now what?

  1. Client will try to locate the Auto discover services, the use of the Autodiscover services is to tell the client where is the user is homed, client does that by sending two parallel HTTP and HTTPS GET requests to the Autodiscover services running on the pool and as following:
    • HTTP://pool.domain/Autodiscover/AutodiscoverService.svc/?sipuri=user@sipdomain
    • HTTPS://pool.domain/Autodiscover/AutodiscoverService.svc/?sipuri=user@sipdomain
    • this is a screenshot take by Fiddler for a real life example with office 3651
  2. Client will get back a response with two HTTPS URLs in it
    • HTTPS://pool.domain/Autodiscover/AutodiscoverService.svc/root/ domain
    • HTTPS://pool.domain/Autodiscover/AutodiscoverService.svc/root/user
    • /root/domain URL accessed without need to authenticate and used to get general information about the Topology
    • /Root/user URL need authentication and used information about the user’s home pool and frontend.
  3. Client will try to use the /root/user/ URL to get the info it need about the home pool, but first it will try to authenticate using the AD username and password (NTLM) which will return a 401 Unauthorized and attach the Web ticket services URL in the response for the client to go and obtain a certificate from it.
    • another capture of my office 365 traffic
    • 2
  4. Client will start talking to the web ticket services running on the pool and try to get a certificate by authenticating using NTLM, the pool will authenticate the user and create a self signed certificate for him/her that is valid for 180 days.
  5. Client then try again to authenticate with the Autodiscover services to obtain the information about home pool, but this time it will authenticate using the TLS-DSK method (Certificate)
  6. Client will get a response with where the user’s home pool is.
  7. Client start communicating to the user’s home frontend and go through step 3-5 again
  8. Client authenticate successfully and get a response from the Autodiscover services with the information needed in the format of xml, below is a real life capture from my office 365 account
    • image

and here is a short video to show the work flow of how authentication works

Skype for business authentication overview

User Outside Corp-Network with domain joined laptop:

External users trying to sign in from outside the Corp-Network using a domain joined machine, lets assume that the user never signed in before and have no certificate from Lync.

Lync uses two method of authentications here:

  • NTLM
  • Certificate TLS-DSK

assuming that the Lync Edge and the reverse proxy servers are deployed and have no problem the authentication process will be same as scenario one but with the following differences:

  1. Authentication traffic will be proxy via the Edge pool to the Pool (Director or Frontend)
  2. Skype4b Client will try to authenticate using NTLM, which will return Unauthorized
  3. Edge will redirect the Client to the external web services URL, this services usually published by the Reverse Proxy
  4. using NTLM  authenticate against the Web services a self signed certificate is issued and stored in the client “Personal Store”
  5. now back again to proxy traffic via the Edge server, the Skype4b client will authenticate against the pool using TLS-DSK which will work and the user sign-in.

following is a video showing the steps of singing in.

User Outside Corp-Network with none domain joined laptop:

so last scenario is user trying to sign in to Skype for business client on a none domain joined machine, assuming that the machine is not connected to the corp-network because allowing none domain joined machines to the internal corp-Network will be a stupid thing to do for so many reasons I won’t discuss here, so let’s say the user will connect from a guest Wifi or a home which is considered a none corp-Network, the process will be same as scenario two with user and domain joined machines, the authentication traffic will be proxy to the pool via Edge, and then redirected to the Reverse proxy server to obtain and download certificate which will be stored in the personal store on the machine.

the credentials will be saved in the Windows Credentials manager if you choose to save my credentials when signing in to Skype for business.

Skype4b Mobile – Locating the Frontend

Skype for business Mobile and windows Metro app clients are different in the discovery method than normal desktop clients, the Mobile clients try to resolve two DNS records to locate the pool:

  • Lyncdiscoverinternal.sip-domain
  • Lyncdiscover.sip-domain

as best practice you should always point the lyncdiscover to the reverse proxy of your infrastructure where the services is published using a public SSL certificate, why you ask, because Skype4b mobile and windows app cannot request and download self signed certificate like normal desktop clients, that’s why the public SSL certificate deployed on your reverse proxy is used.

if the Mobile client or windows metro app client cannot resolve those two DNS records, the discover simply fail and user cannot login, the clients won’t fail back to SRV records like in desktop client.

Skype4b Mobile – Authenticating

Mobile client authentication is very much the same as Scenario one

 

that’s all, a quick deep dive into autodiscover and authentication of Skype for business clients, this article if understood can help you troubleshoot future problems with signing in and discovery.

wish you all and your families a very merry Christmas and happy new year.

Advertisements

Author: Lyncdude

A Senior Microsoft Unified Communications Consultant with more than 9 years of experience in Microsoft Exchange and Microsoft Lync Server / Skype for Business. Egyptian guy lives and works in Frankfurt - Germany. Worked Closely with Microsoft Dubai for 3 years designing , building and supporting Exchange and Lync Infrastructures. A Microsoft Certified ITP in Lync, Exchange and also attended Microsoft Partner Primer Filed Support Engineer T1 Training for Microsoft Lync 2010.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s