Skype for Business Desktop client sign in issue is one of the most common scenario for Helpdesk or Admins or Support Folks who are working in Messaging or Unified communication field. While there are lot of awesome blogs right from the OCS Days explaining about the client sign in call flow, troubleshooting, Log Analysis and etc. I always use to prefer my OneNote page created by taking bits and pieces from different places that covers all these details. I thought sharing the info here might help in getting all the details in one go.
Before entering the troubleshooting phase, one should first understand the Skype for Business Client Sign in process flow to identity what’s expected and act accordingly. In this article, we will focus mainly on the Call flow when Skype for business Desktop Client login.
For simplicity, we could divide the entire Skype for Business Client Sign in process into below 5 steps:
- Server Discovery
- Connectivity Checks
- Authentication
- Optional Redirection
- Retrieve Settings and Policies
1 : Server Discovery
Skype for Business Client is hardcoded to query certain DNS records to locate the Skype for business server information, which is required for Automatic Client sign in, below are the list of DNS records that client would query in order for Server discovery.
Lyncdiscover Records
Lyncdiscoverinternal.contoso.com
Lyncdiscover.contoso.com
SRV Records
_sipinternaltls._tcp.contoso.com
_sip._tls.contoso.com
DNS A Records
Sip.domain.com
Sipinternal.domain.com
Sipexternal.domain.com
At the End of this step, if we have DNS Records configured, skype for business client will get the FQDN/IP Address & Port combination of Skype for business server where it can reach to login.
2 : Connectivity Checks
Once Skype for Business client identified the Server Information, Client performs Network Connectivity checks to see if it can reach the server on identified IP address & Port combination and also it verifies if it can establish a TLS secure connection to the FQDN that it got in first step.
Port Connectivity Checks
Client attempts Network connectivity check to see if it can reach server on required port
In Networking terms this is termed as TCP 3 Way Handshake [ACK–SYNC–ACK]
TLS connectivity Checks
Client attempts to check if it can establish a secure connection with the server
In this, basically client will check if the certificate presented by server is being trusted on client or not; and it also includes Cipher Selection.
In order for Client to be able to trust the presented certificate, client should have the Root CA Cert of the Certification authority that has issued the certificate to the server in its Certificate Trusted Root Store.
3 : Authentication
This is the actual step where client interacts with the Skype for business server using SIP protocol and authenticates itself. Overall process involves Client learning the set of supported Authentication mechanism on the Skype for Business Registrar Servers and Selecting appropriate Authentication methods and getting authenticated.
Firstly, Client sends an Unauthenticated REGISTER Request to the Skype for Business Server:
In response to this REGISTER request, Skype for Business Server would send the list of Authentication mechanisms available for Authentication in 401 Unauthorized:
Client would then select one of the authentication methods and gets authenticated (depending on whether signing in internally or externally, first time sign in or subsequent sign in). By default, Skype for Business Registrar Configurations has below 3 Authentications enabled:
If Client is signing in Internally, then all 3 above listed Authentication methods [Kerberos/NTLM/TLS-DSK] will be available.
If Client is signing in Externally, then only 2 authentication methods will be available [NTLM/TLS-DSK] will be available.
If client uses Kerberos authentication
This is the default one that client uses internally during first time sign in I.e. when they don’t have user certificate to sign in using TLS DSK.
Client would reach out to AD Server and gets authentication ticket (Kerberos ticket) for accessing service on Skype for Business Server. Once it gets the Kerberos ticket, it submits that to Server in next REGISTER request, and server would authenticate the user and signs the user.(In Kerberos method, there is an interaction between clients and AD Servers, this is the primary reason why Kerberos Authentication isn't available for Remote Sign in)
When using Kerberos, in client side logs we will see 2 REGISTER Request/Responses between client and the skype server.
If client uses NTLM Authentication
This is the default one that client uses externally during first time sign in I.e. when they don’t have user certificate to sign in using TLS DSK
Client would send information/details required for authentication in the next REGISTER Requests to the skype for business server, skype for business server in turn talks to AD Server and validates the submitted information/details.
If the Validation succeeds then, skype for business server would consider user authentication as valid/genuine and signs the user. (In NTLM method, All the interaction is between client and the Skype for business server and Skype for business Server to Active directory, but no interaction from client directly with Active Directory)
When using NTLM, In Client side logs we will see 3 REGISTER Request/Responses between client and the skype server.
If Client uses TLS-DSK Authentication
In order for client to use this authentication, client should have user certificate issued by the Skype for business server.
Below is how client connects to the Skype for Business Web Services and gets the user certificate issued.
Client would get the location/URL of web services to get the user certificate from, this would be sent by server in first response for anonymous REGISTER sent. (Ex for URL : https://SFB-SEWeb.Contoso.com:443/CertProv/CertProvisioningService.svc)
Client would connect to skype for business Web Services and authenticates itself using Kerberos/NTLM depending on whether its connecting internally or externally and gets the user certificate issued.
Once user certificate is issued, Client would submit the user certificate details to the skype for business server in the next REGISTER and authenticates itself.
When using TLS-DSK, In Client side logs we will see 4 REGISTER Request/Responses between client and the skype server.
4 : Optional Redirection:
This step is optional, we might or might not see, depending on which server client reached.
If client reached out to Front End Server, where he is homed, then we wouldn’t see this step at all, however, if client reaches out and authenticates against any other front end server (within same pool or different pool) we will see this step, where server would identify where user is homed and redirects to the home Pool Accordingly.
In the above Example, Client reached SFB-FE1.contoso.com (since DNS was pointing here), which inturn redirected to User's home server "SFB-SE.Contoso.com"
5 : Retrieve Settings and Policies
This Step is post Successful Authentication where client/user retrieves different information such as Server side Settings, Policies applied to the user which includes details like normalization rules, what all features allowed, URLs to use when client needs to leverage certain services or modalities and so on.
In this step we would see client sending SERVICE/SUBSCRIBE SIP requests and getting required responses.
SERVICE Requesting for Normalization rules (Location Profile).
SUBSCRIBE Requesting for contact lists
SUBSCRIBE Requesting for Server side configurations/policies (Inband)
SUBSCRIBE Requesting for Presence info of users in the contact list
If we understood above call flow, then below story will sum it up on what happens when user tries to sign in:
- User provides the sip uri Mouli@contoso.com on the skype for business desktop client and clicks on sign in.
- Client first performs “Server Discovery step” and tries Lyncdiscover Records, if it’s not available, then it will failback to SRV Records and then host A Records.
- At the end of Server discovery stage, client would get “Server FQDN/IP and the Port to be connecting to”.
- Client would now attempt and check if it can establish Network connectivity and TLS Connectivity.
- Post successful connectivity checks, client would now send the first anonymous sign in Request “REGISTER” to the server, to learn what all authentication methods are available.
- Server would present the available Authentication methods and respective target/service name and other info.
- Client now selects one of the Authentication methods depending on whether signing in internally or externally, first time sign in or subsequent sign in.
- Upon successful authentication, if it’s not a home server, then Authenticated server will determine the user’s home server and redirect the user to go user’s home pool/Server.
- Post successful sign in, client would send subsequent SERVICE/SUBSCRIBE requesting for inband configuration, policies & etc.
In my Next Article, I will be discussing in detail on Troubleshooting approach when dealing with Skype for business client sign in issues.
'IT이야기 > S4B&Lync' 카테고리의 다른 글
| LyncServer2010의 SecurityGroup (0) | 2019.07.17 |
|---|---|
| Troubleshooting Skype for Business Client sign in issues (0) | 2019.07.09 |
| Deep Dive into the Microsoft Lync 2013 Client Sign-in Process (0) | 2019.07.01 |
| Skype for Business SIP, Media and various Call Flow scenarios (0) | 2019.03.18 |
| #Lync and Remote PowerShell (0) | 2019.02.15 |