Hybrid Modern Authentication for Skype for Business

Published 12-06-2017 11:41 AM 38.1K Views

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 Skype for Business authentication work:

  1. The SfB server needs to support HMA. Support for HMA is included in SfB server May 2017 CU5 release, build .281 or higher. 
  2. 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
  3. 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.
  4. 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.
  5. One Office 365 tenant user must be assigned a Skype for Business license in order for the service principal for the Skype for Business workload to be created in Azure AD. This does not need to be an actual production user of Skype for Business online.
  6. User accounts must exist in AAD. 
  7. 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.


    • Ensure FE servers can access whitelisted O365 URLs. If proxy servers require authentication, all internet traffic from FE server via proxy should be treated as un-authenticated. This is because all traffic to internet invoked by FE servers is under Network Service account context. There are few ways to configure proxy on servers
    • You can use netsh to configure the proxy IP and Port on each FE. Configuring netsh proxy will allow internet access to all users and services on Front-End servers:
      netsh winhttp set proxy IP:Port
    • If an organization wants to limit internet access to only SFB services, BITSAdmin can be leveraged to set proxy for the Network Service account only:
      bitsadmin /util /setieproxy networkservice MANUAL_PROXY proxysrv:8080 ";*.contoso.com"

    • We use .Net classes for HMA. On locked down servers or environments another way to enable proxy is via .Net proxy settings described here. This will only allow access to SFB web ticket service to complete authentication with O365 identity urls. You will need to add the proxy server IP and port to the internal and external web components configuration on each FE. 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(or 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, we will cover the steps here, but for full details, please be sure to refer to these instructions How To Configure Skype for Business On-Premises for Hybrid Modern Authentication.

Before configuring HMA, you first collect details for your on-premises SfB web service URL's as follows:

  1. Login to SfB Front End or Management server where SfB core components are installed.
  2. Open PowerShell, or SfB Management Shell.
  3. Confirm CU5 or higher is installed with Get-CsServerPatchVersion and confirm the Front End is listed with 6.0.9319.281 or higher. 
  4. Obtain web service URL's with Get-CsService -WebServer | Select-Object PoolFqdn, InternalFqdn, ExternalFqdn | FL. [If you any Standard Edition servers are installed, the InternalFQDN will be blank. In this case the Pool FQDN will be used for the InternalFQDN needed to define the SPN for these servers.]
  5. You will need to add https:// to the front of the pool FQDN's and "/" at the end. For example, for FQDN of lswebext01.contoso.com, the SPN will be defined as https://lswebext01.contoso.com/

Next, configure the SPN's for the SfB Service Principal in Azure AD:

  1. First, connect to AAD with these instructions.
  2. Then run the following being sure to replace sample SPN's with your actual SPN's 
    $SfBAppID= "00000004-0000-0ff1-ce00-000000000000"
    $SfBServicePrincipal = Get-AzureADServicePrincipal -Filter "appid eq '$SfBAppId'"
    Set-AzureADServicePrincipal -ObjectId $($SfBServicePrincipal.ObjectId) -ServicePrincipalNames $($SfBServicePrincipal.ServicePrincipalNames) -Verbose
  3. Then confirm you have the SPN's configured correctly with: 
    Get-AzureADServicePrincipal -Filter "appid eq '$SfBAppId'" | select -ExpandProperty ServicePrincipalNames

Before proceeding with enabling SfB for HMA:

  1. Run the following from SfB on-premises Management Shell and 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 for the Oauth Server:
  2. Be sure that you have triple checked your SPN’s, Client configuration, FE internet access, and SfB version. If the SfB version is not CU5 (.281) or higher, authentication will fail. 

Now you're ready to configure your SfB on-premises to use Office 365 Azure AD STS URL (a/ka/ EvoSTS) for Oauth tokens. 

  1. Create the EvoSTS Oauth Server:
    New-CsOAuthServer -Identity evoSTS -MetadataUrl https://login.windows.net/common/FederationMetadata/2007-06/FederationMetadata.xml -AcceptSecurityIdentifierInformation $true -Type AzureAd
  2. Cut over to HMA by setting SfB Oauth configuration to use the EvoSTS Oauth Server:
    Set-CsOAuthConfiguration -ClientAuthorizationOAuthServerIdentity evoSTS

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.

Exchange Web Services

To avoid additional prompts for authentication against Exchange Web Services, you will also need to configure Exchange for Modern Authentication. For details on Exchange, please refer to this blog on hybrid modern authentication for exchange on premises. Note that Modern Authentication is enabled for Exchange online by default. 

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 double check that you have configured all SPN's in Azure AD for internal and external web service URL's for all deployed SfB pool authentication servers, Front Ends and Directors following instructions above. 

Second, 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.


  1. What happens if the client doesn't support Oauth? If the client doesn't support Oauth, authentication will fail back to NTLM and the user will be prompted for their password in the SfB client. Fallback to NTLM will occur whenever Oauth fails as long as the administrator has not disabled NTLM authentication in SfB. 
  2. What happens if a user's account is not synchronized with Azure AD? Again, authentication will failback to NTLM.  

PowerShell Script

To automate collection of URL's and creation on SPN's in Azure AD. 

Script to Configure - Run on SfB Management server or Front End

## Requirements to run this script:

## Run from SfB Management Shell with read permissions to SfB configuration

## Azure AD PowerShell installed (Install-Module AzureAD)

## Office 365 Global Tenant Administrative Permissions


## Script Overview

## First the script will obtain SfB internal and external web service urls

## Second use these URL's to create the required Service Principal Names in the SfB Service Prinicpal in Azure in the Office 365 Tenant


## Obtain SfB web service URL's and return to array variable


$WebServices = Get-CsService -WebServer

$WebServicesFqdns = $WebServices | foreach {$_.ExternalFqdn.tostring()}

$WebServicesFqdns += $WebServices | foreach {

    if ($_.InternalFqdn -ne $null)





## Connect to AzureAD. DO NOT specify -Credential parameter. This will call Windows's native sign in dialog, where you can select and sign in with whatever method is required by your organization.




# Get/update ServicePrincipal in memory and Update SPN if it doesn't already exist

$SfBAppId = "00000004-0000-0ff1-ce00-000000000000"

$SfBServicePrincipal = Get-AzureADServicePrincipal -Filter "appid eq '$SfBAppId'"


foreach ($WebServicesFqdn in $WebServicesFqdns)


    If ($SfBServicePrincipal.ServicePrincipalNames.Contains("https://$webServicesFqdn/")) {continue}




Set-AzureADServicePrincipal -ObjectId $($SfBServicePrincipal.ObjectId) -ServicePrincipalNames $($SfBServicePrincipal.ServicePrincipalNames) -Verbose


# Confirm SPNs

Get-AzureADServicePrincipal -Filter "appid eq '$SfBAppId'" | select -ExpandProperty ServicePrincipalNames


Excellent information, Carolyn!  Thanks for sharing!


Great article Carolyn! Good news! :)

Regular Visitor

Very detailed, informative, and concise as always Carolyn.

Occasional Visitor

Thanks.  Great write up.  How does this config change when using a supported 3rd party STS rather than ADFS?

Thanks for the feedback Kevin, 


Should not be any change in configuration for 3rd party STS. When Azure Oauth (evosts) redirects user to login.microsoftonline.com, a user realm discovery occurs and if a federated domain, the user is directed to the configured STS. This part of the authentication flow is the same with/without Modern Authentication. 

Occasional Visitor

Thanks Carolyn.  It makes sense, your client is still going to get directed to login.microsoftonline.com first, regardless of what other STS or MFA is in the flow after that.  In the case of MA, the token presented back to onprem Skype is still ultimately coming from AAD so the config is the same.

Occasional Contributor

Thanks for the write up!

Would you mind sharing the output of the following command?

Get-MsolServicePrincipal -AppPrincipalId 00000004-0000-0ff1-ce00-000000000000 | select -ExpandProperty ServicePrincipalNames




This is a great article has been easy to follow.  I was curious in your configuration if you noticed the externally facing web service URLs were still using NTLM or Kerberos based authentication even though you had configured it for OAuth via a web browser instead of the Sfb client.

@Thomas Torggler


Here is the output from my test tenant configuration: 

Skype for Business Online


@Norm C


Do you mean that when connecting to external web service URL's via a browser, OAuth is not used? That would be expected as the SfB Oauth requires a supported SfB client. 


Thank you Carolyn for the clarification.


Established Member

Hi Carolyn. Thanks for the guide. I just wanted to check the SPNs you added as from the output you pasted above from your test tenant configuration I can see the Internal and External FQDNs listed by themselves and with the "00000004-0000-0ff1-ce00-000000000000/" prefix. Which is correct, or do you need both?


Hi @Antony Millington Yes we need both. The upns listed as web service urls starting with Https://... are needed when clients sent authorization requests as they will use the web service urls for these requests. The upns listed with service principal ID prefix are needed for server to server authorization requests. 

Regular Visitor

we have lots of polycom vvx deskphones that use PIN auth for signing in to onprem sfb servers, any disruption if we enabled MA onprem for these devices? 

@Chad Phillips


I believe it should work fine but I haven't test. I am successfully using Web Authentication on VVX deskphone with HMA authentication. I am running in my lab which I obtained from Polycom as I have auto update disabled for IP Phones in O365. 

Senior Member

Hi Carolyn


Great article! I have configured MA in my testlab with an On-Prem environment (all users are hosted On-Prem) and it works as expected without any issue until now. ;) There are some question about fallback scenarios in case OAuth will not work.


What about if OAuth cannot proceed? Either internet connection is broken at customer side, there is a service issue at Microsoft Datacenter in accepting MA, ADFS is from the customer is not working correcly for some reason... As far as I have tested with my On-Prem clients (Desktop and Mobile), they will no longer be able to login to SfB!


Is there a kind of a fallback scenario? Clients which does not support OAuth will fallback to NTLM. Is there something similar for MA if there is one component in the authentication flow which does not work correctly? Or do we stuck in not being able to authenticate and login to O365?



@Beni Deflorin


There is no fall back in case the clients are not able to connect to online services for authentication. You could disable HMA on SfB/Exchange to enable authentication in this case, but this is manual change. 

Occasional Contributor

Hello Carolyn,

First of all this is great article. I am planning to configure MA for my On-prem SfB, I want to know few things:

1. IS ADFS require for HMA? I have SFB On-prem and Exchange Online and all users sync to AAD, do I need ADFS? 

2. How do I test HMA with few users? because when we configure EXT and INT web services in O365 tenant all pool users will go redirect to ADD.


Thank you.


Hello @Balu N Ilag


Thanks for the feedback. Answers to your questions:


1. IS ADFS require for HMA? I have SFB On-prem and Exchange Online and all users sync to AAD, do I need ADFS? No you do not need ADFS. You can use any supported authentication method, like Azure AD connect with Password Sync. 

2. How do I test HMA with few users? because when we configure EXT and INT web services in O365 tenant all pool users will go redirect to ADD. If you don't have a test environment, there is no way really to test. You are correct that once you enable Oauth on SfB it will impact all users. The biggest negative impact would be if the clients themselves can't connect to our services for authentication which would cause authentication failures. If you confirm beforehand that all clients can connect to login.windows.net and login.microsoftonline.com, then that would help mitigate any out right failures to authenticate. Ideally you will want to cut over during a change management period, but failing that be prepared to revert back. Fallback to previous authentication method will occur as soon as replication completes in your configuration after issuing Set-CsOauthConfiguration cmdlet to revert back to previous setting. 


Typically, unless you've made other changes to your SfB configuration on premise, users will not be forced to reauthenticate until their SfB client certificate expires, so you wouldn't have all users attempting auth on cutover. 



Occasional Contributor

Thank you Carolyn, I will make sure, the client connectivity to login.windows.net and login.microsoftonline.com to mitigate connection issue. 


Occasional Contributor

 Hello Carolyn,


When I configured SPN on AAD and tries to enable MA for single SfB pool to test auth prompt, however after configuring evoSTS OAuth server is global. when i modfied below command to add identity as pool FQDN to enabling OAuth Configuration for single SfB on-prem pool server, it gives error that scope of OAuth configuration is “Global” not pool wise, so i cannot enable this for single. 

command: Set-CsOAuthConfiguration -ClientAuthorizationOAuthServerIdentity evoSTS

Do you know workaround to enable OAuth for single pool server? or test MA with single pool, so that we can do test before it enable globally



Balu Ilag

@Balu N Ilag


As discussed previously this is a Global change and cannot be scoped to a specific pool. 




Occasional Contributor

Hello Carolyn, 

I have enabled MA and auth experience as expected. One thing noticed is the sign-in information captured for an app named ‘Microsoft Office’ in AAD with an AppID that can’t find in the Azure AD portal. Looks like it’s an offline app/ID; if we want to leverage CA policies, what’s the best way to go forward? Thanks

Senior Member

Hi Carolyn


Found the following information about not supportet Clients/Devices for MA on another blog: https://techcommunity.microsoft.com/t5/Skype-for-Business-Blog/Modern-Auth-for-SfB-OnPrem-with-AAD/b...


The following Skype for Business clients do NOT support MA:

  • Skype for Business Web Chat experience hosted in Outlook Web Access
  • Skype Meeting App
  • Room Systems
  • Non-3PIP IPPhones
  • LWA
  • WebScheduler
  • Lync for Mac


Any official statement from MS which Clients are not supportet? If not is this information still valid? On Technet I found the following article but unfortunately only desktop clients are listed. https://docs.microsoft.com/en-us/skypeforbusiness/manage/authentication/use-adal.

Would be great to see a complete list here. Thanks



@Carolyn Blanding (MS TEAMS)https://techcommunity.microsoft.com/t5/Skype-for-Business-Blog/Hybrid-Modern-Authentication-for-Skyp...

We currently have HMA on our Skype on-prem and Exchange on-prem, but we're having some issues with our Polycom VVX phones. When signing in with BToE or web-sign, or username/password it EWS says is deployed, but we get errors for all the EWS functionality - like calendars, contacts, etc.


These errors are for people that are homed Skype on-prem and Exchange Online. We've manually changed the Exchange Server URL to: outlook.office365.com/EWS/Exchange.asmx/ with no luck.


Have you had luck with getting EWS fully deployed? We're on firmware and have tried many others.

Senior Member



Thanks for the amazing article!  I am receiving the following error with the execution of the last command needed for setup.   Does this command require any special privileges?   I am running under a global admin account.  All other commands previous to this completed without issue. 


PS > Set-CsOAuthConfiguration -ClientAuthorizationOAuthServerIdentity evoSTS
You are not permitted to invoke Set-CsOAuthConfiguration with the following parameters: ClientAuthorizationOAuthServerIdentity
+ CategoryInfo : NotSpecified: (:) [Set-CsOAuthConfiguration], ArgumentException
+ FullyQualifiedErrorId : System.ArgumentException,Microsoft.Rtc.Management.Internal.SetOAuthSettingsCmdlet
+ PSComputerName : admin1b.online.lync.com

Occasional Contributor

@phake Are you using Microsoft STS, or are you further sending requests to a third party like Okta?  In my lab I had no trouble with HMA Skype for Business and Exchange Online with 3PIP phones that had supported firmware (I tested Audiocodes and Polycom phones, and I am not sure if you are on supported firmware or not but you could look that up).  However, when I federated my Azure tenant with Okta I lost EWS connectivity.  I haven't gotten any good answers yet on whether or not that should work.

@oracliffe I'm using the Microsoft STS. Turns out we were having a major issue with our internal SSL decryption cert. Kind of a headsmack on my part. Once we exempted the devices we were good. Thanks for sharing your experience!
New Contributor

Nice article Carolyn


In our environment we have SFB online, Exchange Online and Exchange OnPrem (for legacy applications) and are in hybrid mode. All user mailboxes are homed in O365 and we are using MFA. We are using Polycom VVX phones


With the Oauth 2.0 change coming in January 2020 we have begun to test the supported Polycom firmware ( We have consented to the Polycom phones in our portal and it shows as an enterprise application in it. The phones log into Skype without issue, however when accessing the Exchange services we get authentication errors when accessing calendar on the phones. The only way we have been able to get it to work is when doing the web-signin on the phones. It was my understanding that by consenting to Polycom with the embedded app code in the firmware that we would be able to continue using user credentials to sign in.


From what I have been able to figure out it seems to be due to MFA being enabled as if I use a non-MFA enabled account it works. Is there something on the Exchange onPrem environment that needs to be configured in order to have it accept MFA and pass it to the online environment?


From looking at my logs from the VVX I get 


AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access......


Then appears to fall back to basic authentication and get a failed to Get oAuth Token.


Any insight would be much appreciated.

Senior Member

Hey Carolyn, thanks for such a nice article. I have one question.Is it possible to configure Modern authentication using any external IDP or federation server sitting on premise without using Azure AD(Cloud). We have vendors like Ping, IBM which supports federation server+MFA capability and client looking for only on Premise solution. Would be great if you can share your thoughts on this please.

Version history
Last update:
‎Nov 25 2019 05:18 AM