Hybrid Modern Authentication for Skype for Business

Skype for Business Server (SfB) 2015 May 2017 cumulative update supports Hybrid Modern Authentication (HMA). To use HMA with your SfB on-premises, you will need to have on-premises Active Directory federated with Azure Active Directory (AAD). For more details, please see https://aka.ms/ModernAuthOverview.

Why would you want HMA? To enable SfB clients to obtain Access and Refresh Oauth tokens from AAD that SfB on-premises servers will accept and allow access. This sets the foundation for you to leverage AAD security capabilities like two-factor authentication, or Intune Modern Application Management policies. To learn more details on HMA, please take a pause and read  Deep Dive: How Hybrid Authentication Really Works.

Overview of Authentication Flow with Skype for Business

To understand what is needed for HMA to work, it’s helpful to understand the authentication flow. Let’s take a look at a common sign on scenario for hybrid SfB. In this scenario the user’s SfB and Exchange applications are on-premises and the user’s sip domain is Federated. Note that in an SfB hybrid configuration, all DNS records resolve to on-premises, therefore the authentication flow will always start there.HMASfB.pngIf the user’s SfB account is online, then after step 8, the authentication flow will continue like this:

  1. SfB on-premises validates the user and redirects user to online
  2. SfB online redirects client to AAD
  3. AAD gives client access token to SfB client
  4. Client gives client access token to SfB online
  5. User logged in to SfB and SfB certificate issued to the client.

After the client signs in to SfB the Exchange Web Services authentication flow will start.


If the user’s Exchange mailbox is online, then after step 16, the authentication flow will continue like this:

  1. Exchange on-premises redirects client to Exchange online
  2. Exchange online redirects client to AAD
  3. Client gives refresh token to AAD
  4. AAD gives client access token to the Skype client
  5. Client gives access token to Exchange online
  6. User logged in to Exchange

What you need to make this work

Bearing in mind the authentication flow, we need a few of things to make the authentication work:

  1. The SfB server configured to send authentication requests to Azure AAD. We do this in two steps:
    1. Configure evoSTS Oauth server
    2. Set the Oauth configuration to use this server
  2. SfB clients support Modern Authentication. For SfB 2016 clients, this capability will be on by default. For SfB 2013 clients, a registry entry will be required; please see https://support.office.com/en-us/article/Enable-Modern-Authentication-for-Office-2013-on-Windows-dev... for details.
  3. Azure AAD needs to accept authentication requests from SfB clients. Since the clients will be making these requests for authentication using the on-premises web service URL’s, you need to configure these web service URL’s as Service Principal Names (SPN’s) for your O365 tenant’s AAD SfB service application principal. The SPN’s need to be in the format of https://url as this is how the requests will be coming from the clients. Since clients can connect from either internal or external web service URL’s, depending on their network location, both need to be added. You need to do this for all SfB Front End (FE) servers deployed.
  4. The SfB servers need to trust the AAD tokens presented by the clients. This means that all FE servers need direct Internet access to login.windows.net which will allow then to periodically retrieve the AAD certificate against which they will verify the tokens presented by clients. If a proxy is needed for internet access to your FE servers, you will need to take some extra steps to add the proxy server IP and port information to the web components on your FE servers. To do this by inserting the following section just before the last line of the file </configuration> in both the internal and external web.config files on each FE:

c:\program files\Skype for Business Server 2015\Web Components\Web ticket\int\web.config,

c:\program files\Skype for Business Server 2015\Web Components\Web ticket\ext\web.config











How to enable Modern Authentication for SfB

For online, follow these instructions to enable your tenant for modern authentication.

For on-premises, follow these instructions to How To Configure Skype for Business On-Premises for Hybrid Modern Authentication. Before you turn on MA for SfB by running Set-CsOAuthConfiguration -ClientAuthorizationOAuthServerIdentity evoSTS cmdlet:

  • Make note of the current configuration as you may have it set to use on-premises Modern Authentication for SfB using on-premises ADFS server.
  • Be sure that you have triple checked your SPN’s, Client configuration, and FE internet access.

If you run into a problem and need a quick escape route, simply run Set-CsOAuthConfiguration -ClientAuthorizationOAuthServerIdentity and configure the Oauth server to how it was set previously.

What can go wrong

During testing of HMA for SfB, two common errors appeared:

  1. SPN’s missing or incorrectly configured. We did this too during testing because we fat fingered an entry. Hint – use copy and paste!
  2. The FE servers were not able to verify the oauth token presented by clients because they could not access login.windows.net. This typically occurs when FE servers need proxy access to the Internet.

How can you prevent these errors from happening to you?

First, obtain all the web service url’s for your FE servers before configuring the SPN’s by running this cmdlet from SfB management shell: Get-CsService -WebServer | Select-Object PoolFqdn, InternalFqdn, ExternalFqdn | FL.

Note, that if any of your servers are standard edition, the internal FQDN will be blank. In this case you will need to configure the internal SPN using the FQDN of the server. For example, https://se01.contoso.com.

Second, after configuring the SPN’s double check them against the list obtained from SfB as follows:

  1. Open PowerShell.
  2. Run Connect-MsolService and enter your tenant administrator credentials.
  3. Run Get-MsolServicePrincipal -AppPrincipalId 00000004-0000-0ff1-ce00-000000000000.
  4. Carefully compare the output against your SfB web service FQDN’s.

Third, confirm the web browser settings on FE’s do not have proxy settings and that the servers have direct access to https://login.windows.net. If the FE’s do require a proxy, follow the instructions above for configuring the web components with the proxy IP and port.


If you run into problems and are at a loss for what went wrong, then taking an HTTPS decrypted trace with Fiddler, or a similar tool, can assist in pinpointing the issue. If you have not used Fiddler before, then be sure to read the guidance on the Fiddler site for how to configure it to capture a decrypted HTTPs trace.

If you have ADFS configured for a federated domain, then be sure to set Fiddler to Skip decryption for the ADFS sign in URL defined in your deployment before capturing SfB Sign in. This is set in the HTTPS tab in Fiddler options. If you miss this step, then sign in will fail as ADFS default security for enhanced token protection will detect the Fiddler HTTPS certificate and prevent the authentication process from occurring.

Once Fiddler is installed and configured, sign out of the SfB Client, delete the sign in info, then start the Fiddler capture and sign back into the SfB client.

Oauth Policy

If SfB sever has Oauth setup correctly, you should find the Oauth_Policy in the 200 Post to the SfB Server pool web service as follows:

<wsp:Policy wsu:Id="OAuth_policy">



<af:OAuth af:authorizationUri="https://login.windows.net/common/oauth2/authorize" xmlns:af="urn:component:Microsoft.Rtc.WebAuthentication.2010" />

<af:Binding xmlns:af="urn:component:Microsoft.Rtc.WebAuthentication.2010" />

<sp:TransportBinding xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">


If you do not see this policy, then confirm your SfB server Oauth Configuration by running the following two cmdlets in SfB Management shell and confirm the output matches the expected configuration per our documentation.

  • Get-CsOauthServer
  • Get-CsOauthConfiguration

Problems with SPN’s

If the SPN’s are missing or incorrectly configured, then the Fiddler trace will show a 302 response back from login.microsoftonline.com with information that “The application named ‘https://webserviceURL’ was not found in the tenant named…”

In this case, you will want to connect to the MsolService and run the Get-MsolServicePrincipal -AppPrincipalId 00000004-0000-0ff1-ce00-000000000000 cmdlet to confirm the SPN’s configured. The devil is in the details so be sure that the problem is not a simple typo. Remember, use copy/paste!

FE Connectivity to Login.Windows.Net

If you suspect FE connectivity, you may need to run a CLS logging trace on your SfB FE pool(s). Use the UCWA scenario which includes the WebInfrastructure components for tracing. When you obtain the results search for JwtSecurityToken. If the FE server cannot connect to login.windows.net, the logs will show the request but not the response for retrieving the mex data for: https://login.windows.net/common/FederationMetadata/2007-06/FederationMetadata.xml.


Take your time, cross your t’s, dot your i’s and get ready for a more secure and seamless sign on experience for your SfB users.


Excellent information, Carolyn!  Thanks for sharing!


Great article Carolyn! Good news! :)