How to use Modern Authentication (ADAL) with Skype for Business

This article explains how to use Modern Authentication (which is based on the Active Directory Authentication Library (ADAL) and OAuth 2.0) that can be found in the March 2016 Cumulative Update for Skype for Business for Skype for Business Server 2015, or from initial release for Skype for Business Server 2019.

What's in this article?

Configure ADAL in your pool and set ADFS as security token server

Other Options for Enabling ADAL sign-in (like Office client apps)

Clients where Modern Authentication / ADAL isn't Supported

Configure ADAL in your pool and set ADFS as security token server

In this process, you connect your installation of ADFS to a Skype for Business Server pool that is configured for ADAL.

  1. Install the March 2016 Cumulative Update for Skype for Business Server 2015 to your Skype for Business Server pool or Standard Edition server. (Schedule maintenance windows, as needed, to run Windows Update for the automatic installation.)

  2. On your on-premises ADFS server(s), download the Setup-AdfsOAuthTrustForSfB script. (This needs to be done per ADFS farm or independent ADFS server(s). It does not need to be done on ADFS Proxy or proxies).

  3. Make a note of the internal and external Web Service fully qualified domain names (FQDNs) for your Skype for Business Server pool or Standard Edition server. This needs to be done for all the Skype for Business Pools.

  4. From PowerShell on the ADFS Server(s), run the Setup-AdfsOAuthTrustForSfB. You will need to enter the proper URLs for the internal and external Web Service FQDNs. Here's an example:

    Setup-AdfsOAuthTrustForSfB.ps1 -poolIDs https://contosoSkype.contoso.com,https://contoso01Skype.contosoIn.com

    For any additional pools, you will need to add the Pool Web Services URLs manually to the Skype for Business Server Relying Party Trust in ADFS.

    Important

    It isn't possible to use Passive Authentication for a Pool and also use ADAL. You must disable Passive Authentication in order to use ADAL. For PowerShell cmdlets on how to set authentication for a Pool see this article.

    Tip

    If you have additional pools you need to add them as Identifiers to the Relying Party Trust in ADFS.> Go to your ADFS server and open ADFS Management. Expand Trust Relationships > Relying Party Trusts. Right-click the Relying Party Trust that's listed and right-click for Properties > Identifiers > type the additional Pool URL(s) > click Add.

  5. Return to your Skype for Business Server Front End or Standard Edition server server. From here you must run cmdlets that create an OAuth server and modify that OAuth configuration to work with Skype for Business. You only need to do this step once per Skype for Business Server deployment. Here is an example:

    New-CsOAuthServer -Identity sts.contosoIn.com -Type ADFS -MetadataURL https://sts.contosoIn.com/FederationMetadata/2007-06/FederationMetadata.xml

    Tip

    The 'Identity' URL you see in this command is actually the ADFS Federation Service Name you can see in ADFS Management when you right-click Service > Properties. The 'Type' is always ADFS, and the 'MetadataURL' is always <Your ADFS service name> + "/FederationMetadata/2007-06/FederationMetadata.xml".

    Set-CsOAuthConfiguration -ClientAuthorizationOAuthServerIdentity sts.contosoIn.com

  6. Still on your Skype for Business Server Front End or Standard Edition server, test the new configuration by entering the SIP address of a user and the pool FQDN. You only need to do this step once per Skype for Business Server deployment. This is an example:

    Test-CsRegistration -UserSipAddress AyakaY@contosoIns.com -TargetFqdn Pool1.contoso.com -Authentication OAuthInteractive

  7. When prompted, be sure to enter the credentials of the test user. Verify that the test completes successfully.

    Note

    When your STS URL resolves to ADFS internally , the prompt you will see will be a Windows Security prompt. If the URL resolves externally, you'll see a prompt named Sign in. Typically, we would want a Windows Security prompt here. Note that this behaviour varies, particularly if you implemented Forms-Based Authentication (or FBA).

Also be aware, when the STS URL resolves to an internal ADFS server and Windows Integrated authentication is enabled in browsers, computers where many different users sign in to client applications may have failures to authenticate unless the browser is explicitly configured to prompt users for their credentials in a given browser Security Zone. Think of a kiosk as an example. The account that is logged in to the Operating System may be different than the user account logging into the Skype for Business client. If this is the case, you may see the failures described here.

You can see and change this browser setting in Internet Explorer by clicking > Tools (or the Gear) > Internet Options > Security tab > and the Security Zone (such as Local Intranet). From this dialog, click the Custom level button and scroll to the end of the list in the Settings dialog. Under User Authentication > Login > you'll see an option to 'Prompt for user name and password'. If you have kiosks where the user who starts the Skype for Business client is different (has a different account) from the user logged into the computer, you may want to test setting this option to 'ON' for these machines in a Group Policy.

Finally, and importantly, you may experience more than one prompt as the security system collects the information it needs to authenticate or authorize your account.

Other Options for Enabling ADAL sign-in (like Office client apps)

Now that ADAL is configured for your Skype for Business and (automatically) for Office 2016 client apps across platforms, you may want to leverage it for Exchange Online (where it is not 'On' by default), or in Office 2013 clients.

Important

Need to know what to expect from Modern Authentication sign-ins from your client apps? Take a look at How modern authentication works for Office 2013 and Office 2016 client apps.

To turn Modern Authentication on for Exchange Online, you'll need to run some PowerShell cmdlets. In the case of Office 2013 client apps, you will need to change some registry keys on client machines.

  • Connect to Exchange Online and run the following cmdlets:

    Set-OrganizationConfig -OAuth2ClientProfileEnabled:$true

    Get-OrganizationConfig | ft name, *OAuth*

  • Set these registry keys for every device or computer on which you want to enable Modern Authentication. You will need a GPO in larger organizations. For information on how to make a GPO, see the 'Create a Group Policy Object to modify the registry on a domain joined computer' of this article.

Registry Key
Type
Value
HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Identity\EnableADAL
REG_DWORD
1
HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Identity\Version
REG_DWORD
1

Once these keys are set, set your Office apps to use Multifactor Authentication (MFA) with Office 365.

Tip

To disable Modern Authentication on devices for Office 2013, set the HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Identity\EnableADAL registry key to a value of zero. Be aware that a similar Registry key (HKCU\SOFTWARE\Microsoft\Office\ 16.0 \Common\Identity\EnableADAL) can also be used to disable Modern Authentication on devices for Office 2016.

Clients where Modern Authentication / ADAL isn't Supported

Some client versions don't support OAuth. You can check your version of Office client in Control Panel where you Add and Remove programs in order to compare your version number to the versions (or ranges of versions) listed here:

  • Office Client 15.0.[0000-4766].*

  • Office Client 16.0.[0000-4293].*

  • Office Client 16.0.6001.[0000-1032]

  • Office Client 16.0.[6000-6224].*