When using TLS-DSK, In Client side logs we will see 4 REGISTER Request/Responses between client and the skype server. 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. 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. TLS-DSK Authentication: In order for client to use this authentication, client should have user certificate issued by the Skype for business server. (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) 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 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. 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) Kerberos authentication: Client would reach out to AD Server and gets authentication ticket (Kerberos ticket) for accessing service on Skype for Business Server. If Client is signing in Externally, then only 2 authentication methods will be available will be available.If Client is signing in Internally, then all Authentication methods will be available.In response to this REGISTER request, Skype for Business Server would send the list of Authentication mechanisms available for Authentication in 401 Unauthorized.
Firstly, Client sends an Unauthenticated REGISTER Request to the Skype for Business Server.TLS connectivity Checks, 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.Port Connectivity Checks, TCP 3 Way Handshake.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:Īt 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.
The entire Skype for Business Client Sign in process divided into below 5 steps:
0 kommentar(er)
