Skype for Business (SFB) Registration Procedure

Sudhir Aggarwal

Sudhir Aggarwal

Acquaintance Consultant at HCL Technologies

The entire Skype for Business organisation Client Sign in process divided into beneath 5 steps:

  1. Server Discovery
  2. Connectivity Checks
  3. Hallmark
  4. Optional Redirection
  5. Think Settings and Policies

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 Automated Customer sign in, beneath are the list of DNS records that client would query in club 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 nosotros have DNS Records configured, skype for business customer will get the FQDN/IP Accost & Port combination of Skype for business concern server where it can reach to login.

Connectivity Checks

  • Port Connectivity Checks, TCP three Mode Handshake [ACK–SYNC–ACK]
  • TLS connectivity Checks, in order for Client to be able to trust the presented certificate, customer should have the Root CA Cert of the Certification dominance that has issued the document to the server in its Document Trusted Root Shop.

Authentication

  • Firstly, Client sends an Unauthenticated Annals Request to the Skype for Business Server.
  • In response to this Annals request, Skype for Concern Server would send the list of Hallmark mechanisms bachelor for Hallmark in 401 Unauthorized
  1. If Client is signing in Internally, and so all Authentication methods [Kerberos/NTLM/TLS-DSK] will exist bachelor.
  2. If Client is signing in Externally, then but 2 authentication methods will be available [NTLM/TLS-DSK] volition be available.

Kerberos authentication: Client would achieve out to AD Server and gets hallmark ticket (Kerberos ticket) for accessing service on Skype for Business Server. Once it gets the Kerberos ticket, it submits that to Server in adjacent REGISTER request, and server would authenticate the user and signs the user.(In Kerberos method, there is an interaction betwixt clients and AD Servers, this is the principal reason why Kerberos Authentication isn't available for Remote Sign in)

NTLM Authentication: 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 Advertizement 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 betwixt client and the Skype for business server and Skype for business Server to Active directory, but no interaction from client directly with Agile Directory)

TLS-DSK Authentication: In guild for client to use this hallmark, customer should accept user document issued past the Skype for concern server. Client would get the location/URL of web services to get the user document from, this would exist sent by server in first response for anonymous REGISTER sent. 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 iv REGISTER Asking/Responses between customer and the skype server.

Optional Redirection

If client reached out to Front end End Server, where he is homed, then nosotros wouldn't encounter this step at all, however, if client reaches out and authenticates confronting any other forepart finish server (within same pool or dissimilar pool) nosotros will run into this step, where server would place where user is homed and redirects to the abode Pool Accordingly.

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 utilize when client needs to leverage certain services or modalities and so on.

In this step we would meet 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

Registration Procedure - Scenario-i - SFB Online user residing in on-premise network.

No alt text provided for this image

  • Keith, Online SFB user, logs into his computers, and his SFB client is configured to automatic configuration. For automatic login, there will be an SRV tape created on the SIP domain, for example, _sipinternaltls._tcp.contoso.com or lyncdisover.contoso.com.
  • Keith'southward client performs a DNS SRV record lookup.
  • Because Keith is accessing from inside the corporate network, the internal DNS SRV record will be returned.This resolves to the on-premises SFB deployment. Keith will then cosign to the on-premise pool.
  • Keith will then register against SFB Online surroundings.
  • For Keith to successfully register with the SFB Online service, he needs to have access to the Internet so that he can reach the service.

Registration Procedure - Scenario-2 - SFB Online user residing on public Internet.

No alt text provided for this image

  • Keith, SFB Online user logs into his computers, and his SFB client is configured to automatic configuration. For automatic login, in that location volition be an SRV record created on the SIP domain, for example, _sipinternaltls._tcp.contoso.com or lyncdisover.contoso.com.
  • Keith's client performs a DNS SRV tape lookup.
  • Because Keith is accessing from outside corporate network, the external DNS SRV tape volition be returned. This resolves to the on-bounds Edge server. Keith will then authenticate to the on-premise Frontend server through Edge server.
  • The SFB on-premise pool volition redirect Keith with a SIP 301 to the SFB Online service. It knows to do this because of Keith's Advertising aspect, "msRTCSIP-DeploymentLocator"
  • Keith will then register confronting SFB Online environment.
  • For Keith to successfully annals with the SFB Online service, he needs to take access to the Cyberspace so that he tin attain the service.

Orang lain juga melihat