SFB online Client Sign in and Authentication Deep Dive ;Part 1

First published on TECHNET on Apr 09, 2018
Scenario: Pure Online (O365) environment, SFB user is homed Online, NO ADFS, MA (Modern Auth) is Disabled in O365

NOTE:

I have tried my best to ensure the information below is accurate. Some of the terms I use to describe things like Modern Auth provider, O365 AD, Org ID etc. may not be standard terminology, I use them solely to make the understanding simpler. My intention here is to explain what happens in the background when a SFB client signs in so that it helps engineers and customers troubleshooting issues related to Sign in and Authentication.



How Does it Work?

Below is a High level explanation on how the SFB online Client Sign in process works



SIP URI of the user - e1@mshaikh.onmicrosoftcom

1. SFB client Queries DNS for Lyncdiscover.domain.com. This should point to Webdir.online.lync.com


2. SFB Client then sends a unauthenticated GET request to Lyncdiscover.domain.com


3. The Client is then redirected to Autodiscover ( https://webdir2a.online.lync.com/Autodiscover/AutodiscoverService.svc/root/user?originalDomain=mshaikh.onmicrosoft.com )


4. SFB Client then sends a Request to Autodiscover to discover its pool for sign in.


5. The Client is then challenged and is provided the URL for Webticket service ( https://webdir2a.online.lync.com/WebTicket/WebTicketService.svc ) where it can request a Webticket


6. The Client then sends a POST request to Webticket Service which requires the client to provide a Token from Org ID (login.microsoftonline.com)


7. Now in order to authenticate the client reaches out to Ord ID and requests a Token


8. The Client may receive a Password prompt and once the correct password is provided Org ID will issue a Token


9. The Client then submits this token to Webticket Service


10. Webticket service now will grant a Webticket to the Client


11. The client then submits this webticket to Autodiscover


12. In Response Autodiscover will provide the Pool names (sipfed2a.online.lync.com" port="443) where the client can send Register to Sign in


13. The SFB client now sends a SIP register to the Online Edge pool (sipfed2a.online.lync.com" port="443)


14. It is then challenged for authentication again, here the ONLY supported method of authentication is TLS-DSK, The client is provided a Cert provisioning URL ( https://webdir2a.online.lync.com:443/CertProv/CertProvisioningService.svc ) in the 401 unauthenticated response


15. The SFB client then sends a request to Certprov


16. Here again the Client is challenged for authentication and is redirected to webticket service to get Webticket


17. The Client had already Obtained a webticket in step 10 above


18. The client will submit the same webticket obtained in step 10 to the Cert provisioning service


19. The Client then receives a certificate


20. The SFB client can now send a Register again and use the certificate it downloaded for authentication

Below is a graphical representation of the SFB online Client Sign in process









Detailed Explanation of SFB online Client Sign in process with LOG Snippets:

SIP URI of the user - e1@mshaikh.onmicrosoftcom

When a SFB client wants to Sign in, It needs to know where it can send its request to be able to Sign in. Whenever a user enters his SIP URI to sign in to the SFB client, The client forms an autodiscover URL using the domain name that it extracts from the users SIP URI to start the discovery process and then it sends an Unauthenticated Get request to the URL, lyncdiscover.domain.com. The response code for this request will be '200 ok' and in the response we should receive the external webservices URL for autodiscover.

You can see the request and Response below



The SFB Client learns that it needs to Contact https://webdir2a.online.lync.com/

It then tries to Do a TCP handshake with webdir2a.online.lync.com

You can see that in a Network trace, refer Screen shot below



Once the Initial TCP handshake is Complete, The Client will perform a TLS Handshake,

You can see that in a Network trace, refer Screen shot below



The client then sends a request to the Autodiscover URL for its own domain (in this case @mshaikh.onmicrosoft.com) and in Response it receives the Autodiscover URL's specific to the users Tenant. You can see the request and Response below



The client then sends a request to the user URL. We are here trying to discover a specific users home pool, hence the request will go to the “User” URL.

In the response, the Client receives a Web ticket URL, which provides the location of the WebTicketService.

You can see the request and Response below



The Client then needs to send a Request to the Web ticket service URL in order to obtain a Web ticket. The client will send this request in a POST message to the web ticket Service and in response it receives the actual individual Web ticket service URL's



The Client has to submit a Request to this web ticket URL now in order to obtain a web ticket. But if it does that then it will need to authenticate first, unless the Client authenticates itself it will not be issued a web ticket. Since this user is Homed in SFB online and was created directly in O365 AD the Client needs to reach out to O365 AD (also known as Org ID) to get authenticated first. Once it is authenticated by Org ID then the Client will receive a Token from Org ID that will prove that the client has been authenticated. The Client will then reach out back to the Webservice URL and submit the Token it received from Org ID.

SO right now the Client has to First reach out to Org ID in order to authenticate and Get a Token.

The process of reaching out to O365 AD is initiated with the help of Microsoft Online Sign in Assistant that is installed on the Computer. You can find logging for this in C:\MSOTraceLite\MSOCredprov.txt

The Org ID is located at https://login.microsoftoline.com

You can see the Client reaching out to https://login.microsoftoline.com and requesting a Token and subsequent responses will show that it receives a Token from https://login.microsoftoline.com after entering the password when prompted.





Once the Client receives a Token from Org ID it then submits this token to the Web Ticket Service https://webdir2a.online.lync.com/WebTicket/WebTicketAdvancedService.svc/WsFed_bearer

In Response the Web Ticket Service will now Issue the Client a Web Ticket. You can see this in the Trace below



The Client will Then Submit this web ticket back to the AutoDiscover User URL - /Autodiscover/AutodiscoverService.svc/root/user?originalDomain=mshaikh.onmicrosoft.com&sipuri=e1@mshaikh.onmicrosoft.com

In response it will now receive the Internal and External addresses of the Pool names where the user is Homed.

You can see this in the trace below



Once the Client receives the pool names it will then Send a SIP REGISTER message to the SFB pool in order to sign in. Depending on the Users location this will ideally be sent to the SFB online Edge pool. You can see that in the Client UCCAPI log file. This is shown in the snippet below



In response the Client will now receive a 401 Unauthorized message again and the server will again ask the client to authenticate itself. Here the ONLY method of authentication that is available is TLS-DSK (Cert based authentication)

The SFB online server will provide the Client a Cert provisioning URL in the 401 you can see that in the snippet below



This means that the Client now needs to present a Certificate that can then be used to authenticate the client. Since this is the first time the client is signing in it will NOT have the certificate installed. This certificate is ideally downloaded after the client signs in for the first time and is valid for about 8 hours.

Since the client does not have a valid certificate it now has to Re-Authenticate to the Cert provisioning service.

The Process for this will again be the same, the client has to first get a Web ticket, to get a web ticket it needs to get a Token from O365 AD, but we know that the client has already done these steps earlier. SO it already has a Web Ticket from the Web services URL. The Client needs to submit this same web ticket that it had obtained now to the Cert provisioning Service and once it submits the web ticket it will serve as a proof of authentication.

The Client learns about this by first sending a Mex request to the Cert provisioning URL. You can see that in the Trace below



The Client then submits the Web Ticket that it had received to the Cert provisioning URL it received above, after this it receives a 200 OK and a Certificate is now downloaded.



The clients will then send a SIP REGISTER again to the SFB Pool in which it submit this certificate the pool and in response it will receive a 200 OK.

Sign in is NOW complete!!!