SFB online Client Sign in and Authentication Deep Dive ;Part 7 (Hybrid)
Published May 20 2019 05:55 PM 10.4K Views
First published on TECHNET on Apr 13, 2018
Scenario: SFB Hybrid environment, SFB user is homed Online, ADFS is Configured, MA (Modern Auth) is enabled ON premise through On premise AD (NOT Hybrid MA EVOSTS) and also enabled 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 - ex3@cloudsfb.com

  1. SFB client Queries DNS for Lyncdiscover.domain.com. This should point to External web services URL (ON Premise Reverse Proxy) which in this case is webext.cloudsfb.com

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

  3. The Client is then redirected to Autodiscover

  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 where it can request a Webticket

  6. The Client then sends a POST request to Webticket Service

  7. Webticket Service Redirects the Client to ON PREM Modern Auth Provider ( https://sts.cloudsfb.com/adfs/oauth2/authorize )

  8. Now in order to authenticate the client reaches out to https://sts.cloudsfb.com/adfs/oauth2/authorize and requests a Token, The intention here is to Get a Token from https://sts.cloudsfb.com/adfs/oauth2/authorize

  9. The Client may receive a Password prompt (or previously saved password from credential manager is passed) and once the correct password is provided, https://sts.cloudsfb.com/adfs/oauth2/authorize will issue the modern Auth Token to the client

  10. The Client then submits this token that it received https://sts.cloudsfb.com/adfs/oauth2/authorize to Webticket Service

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

  12. The client then submits this webticket to Autodiscover

  13. Since the SFB user is homed Online, In Response Autodiscover will provide the Online Autodiscover webservices URL's names ( https://webdir2a.online.lync.com/Autodiscover/AutodiscoverService.svc/root?originalDomain=clou... )

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

  15. The Client is then challenged and is provided the URL for Webticket service where it can request a Webticket

  16. The Client then sends a POST request to Webticket Service

  17. Webticket Service Redirects the Client to Modern Auth Provider (login.windows.net)

  18. Now in order to authenticate the client reaches out to Login.windows.net and requests a Token, The intention here is to Get a Token from login.windows.net

  19. From this point onwards we will see that login.windows.net will redirect the client to login.microsoftonline.com

  20. Since the tenant is enabled for ADFS the client is then redirected to the ON Premise ADFS server

  21. SFB client will then send a request to ADFS server and request a token

  22. The Client may receive a Password prompt (or previously saved password from credential manager is passed) and once the correct password is provided, ADFS will issue a Token to the client

  23. The Client then submits this token to login.microsoftonline.com which in turn passes the client to Login.windows.net

  24. Login.windows.net will now issue the Modern Auth Token to the client

  25. The Client then submits this token that it received from Login.windows.net to Webticket Service

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

  27. The client then submits this webticket to Autodiscover

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

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

  30. 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

  31. The SFB client then sends a request to Certprov

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

  33. The Client had already Obtained a webticket in step 26 above

  34. The client will submit the same webticket obtained in step 26 to the Cert provisioning service

  35. The Client then receives a certificate

  36. 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



clip_image001



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

SIP URI of the user - ex3@cloudsfb.com

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 the SFB 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.

clip_image002

The SFB Client learns that it needs to Contact https://webext.cloudsfb.com/ (This is the External webservices URL for autodiscover on the ON Premise SFB environment)

It then tries to Do a TCP handshake with webext.cloudsfb.com, Followed by a TLS handshake. (I haven't included the TCP and TLS handshake screen shots here, you can see those if you collect a Network trace while signing in)

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

clip_image003

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.

Now since we have Modern Auth enabled ON Premise the Web Ticket Service will redirect the client to the MA provider URL for ON PREM - <af:OAuth af:authorizationUri= https://sts.cloudsfb.com/adfs/oauth2/authorize xmlns:af="urn:component:Microsoft.Rtc.WebAuthentication.2010" />

We can see this below

clip_image004

The Client will Now send a Request to https://sts.cloudsfb.com/adfs/oauth2/authorize to get the MA Token, You will see several HTTP GET and POST messages exchanged between Client and https://sts.cloudsfb.com/adfs/oauth2/authorize during this process. Below screen shot lists some of them

clip_image005

During the above process the Client will be challenged for password by MA or if the user had signed in before and the password is saved in Credential manager then this password will be passed and user may not see the Prompt.

Finally the Client will receive a Token from MA provider, you can see this below

clip_image006

The Client will then Submit this token to the Webticket service which will then issue a Webticket, This can be seen below

clip_image007

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

In response it will now receive the Online Autodiscover webservices URL names

You can see this in the trace below

clip_image008

Now the Client will send a Unauthenticated Get request to Webdir2a.online.lync.com and in Response it receives the Autodiscover URL's specific to the users Tenant. You can see the request and Response below

clip_image009

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

clip_image010

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. Now since Modern Authentication is enabled on the Tenant, in order to grant the webticket the client will first need to get a Token from the Modern Auth provider so the client is redirected to the Modern Auth provider URL - <af:OAuth af:authorizationUri="https://login.windows.net/common/oauth2/authorize" xmlns:af="urn:component:Microsoft.Rtc.WebAuthentication.2010" />

clip_image011

The Client then sends a request to the MA/Oauth URL to request a Token, The intention here is to Get a Token from login.windows.net

From this point onwards we will see that login.windows.net will redirect the client to - login.microsoftonline.com.

Below is the Request that client sends to the MA/OAUTH URL and in response it is redirected to AD - login.microsoftonline.com

clip_image012

We have to remember that "The intention here is to Get a Token from login.windows.net" we will see several exchanges happening between client to login.microsoftonline.com. Below are screen shots showing these exchanges.

clip_image013

Now, Since the customer has ADFS, the Modern Auth provider will redirect the client to the ADFS Server. Below is the screen shot showing login.microsoftonline.com redirecting the client to ADFS

clip_image014

The Client will then reach out to ADFS to get an ADFS Token. The Next Two Screen shots show that;

(This is where the user might get prompted to enter credentials or if his credentials are already stored in credential manager then those credentials will be passed in the background and the user may not see the prompt)

clip_image015

clip_image016

The Client will then Submit this Token to Login.microsoftonline.com, where it will be redirected again to https://Login.windows.net and https://Login.windows.net will finally provide the client with the Modern Auth Token, This is shown in the two screen shots below

clip_image017

clip_image018

Now the client will submit this token to the webticket URL, and the Webticket service will issue the webticket, Shown below

clip_image019

The client will then submit this webticket to Autodiscover and in return it will receive the POOL names where it has to send the Register to Sign in.

clip_image020

Once the Client receives the pool names it will then Send a SIP REGISTER message to the SFB pool in order to sign in. . You can see that in the Client UCCAPI log file. This is shown in the snippet below

clip_image021

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

clip_image022

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 will send a request to the Cert Provisioning URL where it will be challenged to get a Webticket. The client has to first get a Web ticket from the webticket service URL, to get a web ticket it needs to get a Token from Modern Auth Provider, 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 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

clip_image023

The Client then submits the Web Ticket that it had received previously to the Cert provisioning URL it received above, after this it receives a 200 OK in which it receives the Certificate

clip_image024

The clients will then submit this certificate back to the pool and will receive a 200 OK in response. The Sign in is then complete

clip_image025

clip_image026



Sign in is NOW Complete!!!
Version history
Last update:
‎May 20 2019 05:55 PM
Updated by: