Updated 10/18/2016 – Clarifications on ‘hybrid topology support’ for Skype for Business Server 2015 and Skype for Business Online

Updated 6/8/2016 – Including updated information about Modern Authentication MFA support for Lync Phone Edition clients

Updated 5/11/2016 – Including updated information about Modern Authentication support for clients

Updated 4/26/2016 – Including information about Skype for Business Hybrid support

Over the past 12 months there has been a great deal of chatter within the Office365 space with the talk about Modern Authentication, also known as Azure Active Directory Authentication Libraries.  Microsoft announced the public preview of Modern Auth back in March of 2015 and then officially announced the worldwide public release in December of 2015.  While the feature was suddenly available and activated, there wasn’t a lot of good information out there about configuration, topology supportability, and overall limitations, so many customers (and even partners) were scrambling to examine the shiny new tool we were given.  While I cannot give you a true deep-dive into ADAL, I can provide some context and some help around some core ADAL concepts and how it impacts Lync Server, Skype4B Server and Exchange Server deployments for customers using hybrid topologies to transition to Office365.

What is ADAL?

For on-premises topologies, architects and administrators have lived in the realm of Basic, NTLM and Kerberos authentication since the advent of Active Directory.  Obviously there are other protocols out there, but the core of Windows based authentication rested on those protocols and they worked well for the on-premises topology they served.  Despite the admirable job they do, those protocols either don’t work or are vulnerable when you begin moving to a cloud-based topology so protocols like OAuth and OpenID began to give rise in the market because they offered secure protocols (OAuth and SAML) for the various mixes of cloud topologies and service intermingling that exist on the Internet today.  As with anything though, things advance, and ADAL is based off the advancements offered within OAuth 2.0.  What does ADAL bring to the table, you ask?  While Microsoft offers some info here on features, I’m pulling out a few for clarity’s sake:

  • Provides uniform authentication across Office365 applications
    • No more basic authentication in Outlook!
    • Uniform smart-card or certificate based authentication across all apps/services!
  • Works with on-premises Active Directory and Active Directory Federation Services
    • AD-FS 3.0 for fullest supportability
  • Replaces passive authentication functionality that was first offered in Lync Server 2013
  • Can support qualified third-party identity providers (SAML)
  • Can enable conditional access through various health-check functionalities:
    • Verify jailbroken status
    • MDM enrollment status
    • Managed application status
    • Geofencing
  • Provides multi-factor authentication (MFA) support
    • PIN support
    • Phone authentication
    • RSA token

The biggest enhancement, in my opinion, is enabling a uniform authentication platform across all applications involving Office365.

Office2013-ADALFlow

Note:  While the picture above shows Office 2013, the same logic applies to the new Office 2016 suite of products.

For the consultants/architects out there, you are well aware of the various differences in authentication that occurred with Office365 and/or with on-premises Server products (think about what breaks when you turn on Lync Server 2013 passive authentication because the other product(s) doesn’t support that implementation), so the uniformity is a huge step forward.  Despite the improvements, there are some items to make sure you are aware of in order to utilize Modern Auth.

Skype4B Hybrid Topologies

As of March 2016, Microsoft has now updated Skype for Business Server 2015 to support Modern Authentication:

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

While the addition of this is great, there are two significant limitations to this ‘supportability statement’:

  1. You must have Skype for Business Server deployed on-premises:
    • ADAL is included in the March 2016 Cumulative Update for Skype for Business Server 2015, and the March 2016 Cumulative Update for Skype for Business must be installed and is needed for successful configuration.
  2. Modern Authentication for split-domain deployments between Skype for Business Online and Skype for Business Server 2015 on-premises is still not supported.

Lync Server 2013 also supports OAuth, but my guess is that there simply isn’t code available to support OAuth 2.0, which is used by ADAL and is the core of Modern Authentication, so the legacy Lync Server 2013 platform is left out of the fun for now.

The other significant downside is that you must manually configure AD-FS by using a script to enable ADAL with Skype for Business – something that is not required for other Office server products:

In Skype for Business Server 2015 Modern Authentication (ADAL) conversations, Skype for Business Server 2015 communicates through ADFS (ADFS 3.0 in Windows Server 2012 R2). The authentication may happen using some other Identity Provider (IdP), but Skype for Business server needs to be configured to communicate with ADFS, directly.

At the end of the day the biggest limitation is that you can’t yet have Modern Authentication enabled for a true hybrid for Lync/Skype4B involving split-domain configurations.  The KB 3126604 article makes it very clear that the only ‘hybrid’ support is really for Exchange Server hybrid deployments that are integrating with Skype for Business Server on-premises. If you are looking to enable Modern Authentication for Skype for Business Online and have hybrid enabled for your Skype for Business Server on-premises deployment, it will not work and is unsupported.

Skype4B Online Modern Auth Default State

By default, Modern Auth is not enabled for Skype4B Online tenants.  Should you choose to utilize Modern Auth, you must open a support request with Office365 to have them enable it within your Skype4B Online tenant.

Exchange Hybrid Topologies

Not living in the Exchange Server world as deeply as I did in my past, I’ll defer most of you to awesome Exchange Server guru Joe Palarchio for specific in-depth questions around Exchange Server.  That being said, a few things I can say:

  • Exchange Server 2010 does not support ADAL and likely never will
  • Exchange Server 2013 supports ADAL, but it isn’t enabled by default
  • Office 2013 supports ADAL, with the right updates, but it isn’t enabled by default
  • Office 2016 supports ADAL and is enabled by default

All things considered, Exchange Server has a much better supportability stance for Modern Auth, especially for hybrid deployments.

Exchange Online Modern Auth Default State

By default, Modern Auth is not enabled for Exchange Online tenants.  Should you choose to utilize Modern Auth, you can follow the documentation provided by MSFT to enable Modern Auth for your Exchange Online tenant.

Intersections of Exchange and Skype4B

Skype4B/Lync On-Premises but using Exchange Online with Modern Auth & MFA

Office365-ModernAuth-ExS4BHybridFlows

For enterprise voice users, this will likely be a very common scenario:  My Skype4B account is on-premises, either on Lync Server 2013 or Skype4B Server 2015, but my Exchange mailbox resides in Office365.

In the past this proved to be a very simple and workable solution – very “turn key” in fact – but when you add in Modern Auth & MFA as a requirement you’ll notice that the Skype4B clients suddenly cannot access Exchange Online via EWS…until the fix below:

AllowAdalForNonLyncIndependentOfLync

Don’t ask me about why the name is what it’s named, but the bottom line is that if you enable Modern Auth and MFA for Exchange Online you must follow the guidance in the article above to ensure Skype4B clients can successfully authenticate to Exchange Online.

  • Lync 2013 clients must be updated with the July 2015 CU
  • Skype 2015 clients must be updated with the September 2015 CU
  • Either the registry key or in-band policy setting to invoke the authentication logic change

Note:  Unfortunately I cannot confirm whether the changes above are required when Modern Auth is deployed without MFA.

Registry Info

Windows Registry Editor Version 5.00

#Lync 2013 and Skype4B 2015 Clients
[HKEY_CURRENT_USER\Microsoft\Office\15.0\Common\Identity]
"EnableADAL"=DWORD:00000001

[HKEY_CURRENT_USER\Microsoft\Office\15.0\Common]
"Version"=DWORD:00000001

[HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\15.0\Lync]
"AllowAdalForNonLyncIndependentOfLync"=DWORD:00000001

#Skype4B 2016 Clients
[HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\Lync]
"AllowAdalForNonLyncIndependentOfLync"=DWORD:00000001

Skype4B/Lync Cient Policies

$a = New-CsClientPolicyEntry -name AllowAdalForNonLyncIndependentOfLync -value "True"
Get-CsClientPolicy | Set-CsClientPolicy -PolicyEntry @{Add=$a}

Once the settings are in place, access to EWS via the desktop clients will be restored.

Note:  This setting does not appear to be applicable to mobile clients as they appear to “just work” from my testing with my current customer.

Potential Limitations of this Scenario

There are a few potential limitations/unknowns of this particular scenario when it comes to other clients:

  • Lync for Mac 2011 – this likely won’t support Modern Auth.  EVER.
  • Lync for Mac 2016 – this almost certainly has to support Modern Auth, but it isn’t available yet.
    • Update:  This is confirmed to have Modern Auth support.
  • Lync Phone Edition – I am very skeptical if LPE will ever get Modern Auth support.  My gut tells me no but I suppose it is possible.
    • Update:  LPE does work when you are using Modern Authentication in Exchange Online but don’t require MFA.  If you turn on MFA, LPE devices will be unable to access Exchange Online because it doesn’t have the capability to understand Modern Auth MFA within its client code.
  • Lync Room Systems & Skype4B Room Systems – since these systems are Windows Embedded based and run the Lync 2013 client core code, it seems plausible that they may be able to support Modern Auth.  I’ve seen no support statement, however, so I can’t say for certain whether Modern Auth support is avialable.
  • 3PIP Phones (Polycom, Audiocodes, etc) – I am very doubtful that these phones support Modern Auth at this time, but I’ve seen no support statement.  My gut tells me not currently but will be coming soon.
  • Polycom RealPresence Systems – The Group Series, DMAs and RMXs provide great functionality for bringing together disparate standards based systems and integrating them with the Microsoft UC stack but I am very doubtful those systems can utilize Modern Auth functionality to authenticate against Exchange Online.

Given those limitations above, there is a large swath of client devices that simply may not be able to access Exchange Online Web Services in a scenario where Modern Auth & MFA is enabled for the Exchange Online tenant.  I don’t have the capacity or resources to test all the scenarios unfortunately, but I will update findings as I come across them.  Bottom line:  test, test, TEST this before rolling out to production users!

Wrapping Up

There are various other scenarios that one could encounter with Modern Auth & Hybrid, but the deployment scenario above is likely to be the most common for now.  I’ll update this post with other topologies & scenarios as I come across them!

9 thoughts on “Office365 Modern Authentication, Skype4B Hybrid & Exchange Hybrid

  1. AllowAdalForNonLyncIndependendOfLync should be AllowAdalForNonLyncIndependentOfLync
    the last d to t

    1. Had to really search but I found where you were talking about. Fat fingered it – thx for the heads up.

      1. No problem. Thanks for the article, great to know there was a viable workaround.

  2. Will using the in-band provisioning method create the registry change?

    1. IF you use inband, and have clients updated to recognize the inband setting, the registry key isn’t required to be created. The inband setting will replace the need to manually create the registry key.

      1. That’s what I thought. It’s interesting, in my test lab making the registry change seems to work perfectly, but using the in-band provisioning method doesn’t.

        1. Remember though that the clients must be running the appropriate CU in order to take advantage of the inband setting. The MSFT support article makes a very specific point about the CU/PU required for inband support to work.

  3. Any insight for an On Prem deployment of both Skype and Exchange where ADAL is enabled on Skype but not on Exchange.

    1. Each service is enabled individually and independent from the others. Thus, if you enable Modern Auth for Skype4B, simply follow the TechNet article and enable for Skype. Unfortunately I don’t know what kind of gotchas you may run into having Modern Auth enabled for Skype but NOT enabled for Exchange…

Comments are closed.