Can I replace ADFS with AD Connect Seamless Sign-On?

Can I replace ADFS with AD Connect Seamless Sign-On? The simple answer is ‘yes’! Microsoft released an update to Azure AD Connect in June 2017 called Seamless Single Sign-On (also known as SSO) that offers a simpler and more cost-effective SSO solution for Office 365 than ADFS.

AD Connect Seamless Single Sign-On can replace your costly (and potentially complicated) ADFS infrastructure with an additional ‘tick in a box’ on the AD Connect wizard.

Problem

Microsoft’s Single Sign-On solution for Office 365 has traditionally been Active Directory Federation Services (ADFS). ADFS offers the following benefits:

• Single Sign-On for Office 365/other apps
• Authentication is on-premise. Login to Office 365 is dependent on Active Directory Account
• ADFS allows administrators to restrict access to Office 365 using Claim Rules (only allow specific groups/locations access to Office 365 via certain clients)

However, ADFS also brings the following problems:

• Costly and complicated ADFS setup. The diagram below shows a typical ADFS environment for Office 365 SSO. This is in Azure to provide HA/DR. This structure requires six servers (two DCs, two ADFS Backend and two WAP Front End) just to provide SSO internally for on-premise users accessing Office 365. The Azure infrastructure alone for ADFS for Office 365 needs six Servers (two each for HA).
• Single Sign-On with ADFS only works internally! For example, John would get SSO in the diagram below as he hits the ADFS Servers when signing into Office 365. Clare would not get SSO, as she hits the WAP Servers when signing into Office 365.

• Requires technical knowledge to setup and support going forward. Servers also need to be backed up.
• Additional complicated Claim Rules are required for lockdown of services (only allow specific groups/locations access to Office 365 via certain clients).
• This almost defeats the object of moving to the cloud, e.g., moving email to Office 365 but being totally reliant on servers (either on-premise or in Azure). If your ADFS Servers are down, no one can sign into Office 365!

The solution? Azure AD Connect with Seamless Sign-On

The solution to having Single Sign-On without ADFS is AD Connect Seamless Single Sign-On.

Azure Active Directory Seamless Single Sign-On (Azure AD Seamless SSO) automatically signs users in when they are on their corporate devices connected to your corporate network. When enabled, users don't need to type in their passwords, or even their usernames, to sign in to Azure AD. This feature provides users with easy access to cloud-based applications without needing any additional on-premise components.

Benefits of Seamless SSO

The diagram below summarises the Seamless SSO progress:

The following are the benefits of Seamless SSO:

• Works in combination with Password Hash Synchronization or Pass-through Authentication
  • Core recommends running Seamless SSO in combination with Password Hash Synchronization. This ensures that users on the corporate network get SSO, but users can still sign into Office 365 if the corporate network/AD Connect is down using the Password Hash Method.
• Users are automatically signed into both on-premise and cloud-based applications when on the corporate network.
• Users do not have to enter their passwords repeatedly.
• Users outside the corporate network can sign in using the normal username and password method required with Password Hash Synchronization.
• No additional components/servers are required. AD Connect Wizard with tick in a box (see below) and a GPO.

• Allows you to register non-Windows 10 devices with Azure AD without ADFS. This allows you to use it with Azure Device Based Conditional Access.
• Seamless SSO is an opportunistic feature. If it fails for any reason, the user sign-in experience goes back to its regular behavior, i.e., the user must enter their password on the sign-in page.
• It’s free! Seamless SSO is a free feature and you don't need any paid editions of Azure AD to use it.
• Sign-out is supported. This allows users to choose another Azure AD account to sign in with, instead of being automatically signed in using Seamless SSO.
• You don’t need to open any inbound ports. Web Application Servers need inbound 443 traffic to them. This could be seen as a security risk and will require protection; possibly a Web Application Firewall and maybe even a Pen Test.
• Seamless SSO is supported on web browser-based clients and Office clients that support modern authentication on platforms and browsers capable of Kerberos authentication.

The table below shows supported browsers.

(* Requires additional configuration)

Technical Details

How does the sign-in on a web browser with Seamless SSO work?

Below details the sign-in flow on a web browser:

• User tries to access a web application (for example, Outlook Web App https://outlook.office365.com/owa/) from a domain-joined corporate device inside your corporate network.
• If the user is not already signed in they are redirected to the Azure AD sign-in page.
• The user types their username into the Azure AD sign-in page. (For certain applications the user gets a silent sign-on experience (i.e., no need for your users to even input their usernames)
• Using JavaScript in the background, Azure AD challenges the browser via a 401 unauthorised response, to provide a Kerberos ticket.
• The browser, in turn, requests a ticket from Active Directory for the AZUREADSSOACC computer account (which represents Azure AD).
• Active Directory locates the computer account and returns a Kerberos ticket to the browser, encrypted with the computer account's secret.
• The browser forwards the Kerberos ticket it acquired from Active Directory to Azure AD.
• Azure AD decrypts the Kerberos ticket which includes the identity of the user signed into the corporate device, using the previously shared  key.
• After evaluation, Azure AD either returns a token back to the application or asks the user to perform additional proofs, such as Multi-factor Authentication.
• If the user sign-in is successful, the user can access the application.

The diagram below shows the flow and steps:

FAQs

Below are some of the most common issues put to Core around replacing ADFS with AD Connect Seamless SSO…

We use ADFS Claims Rules to restrict access to Office 365

Core Answer: Conditional Access should be used to restrict access to Office 365 via Device/Location or MFA. Please note: requires Azure AD Premium License.

We use ADFS for SSO to external hosted applications

Core Answer: Replace this with Azure Single Sign-On for Enterprise Apps. This ensures the SSO solution is truly in the cloud. Many vendors already offer a template for Azure SSO in the Azure Portal Gallery. If the 3^rd party app is not listed, Azure provides instructions on how to develop Azure SSO for non-gallery apps. This also ensures the 3^rd party app can have Conditional Access Rules.

We use ADFS for our own on-premise applications...

Core Answer: Could this be replaced with Azure Application Proxy to ensure a single-pane (myapps.microsoft.com) for getting access to applications?

We use ADFS for authentication of older applications, e.g., Office 2010

Core Answer: With Office 2010, ADFS does not offer full SSO. It uses basic authentication and actually goes via the WAP servers, so your experience is no different than using Password Hash Synchronization. ADFS works with modern authentication applications. It is 2018! Time to move away from Office 2010 to applications that support modern authentication, for example, Office 2016.

Isn’t ADFS more secure than using Seamless SSO with Password Hash Sync?

Core Answer: Why? ADFS requires inbound 443 access to a server in the corporate DMZ. AD Connect only requires outbound traffic. Also, connections to Office 365 can be restricted to only corporate devices using Conditional Access.

Is it a big project to replace ADFS with AD Connect Seamless Sign-On?

Core Answer: No. We would normally recommend POC stage with a test domain to test user experience. Once this is done, the cut-over can be done out of hours on the live domain.

User Experience of Azure AD Connect Seamless SSO

The following section shows the end user experience of Azure AD Connect Seamless SSO from a domain joined machine (Windows 10).

User logs onto Windows 10 domain joined machine. This is their first time logging onto this machine, and they open up Internet Explorer.

Internet Explorer opens

User enters the address https://outlook.office365.com. User is signed straight in- no username or password.

Gotchas

As with most Microsoft solutions, Azure AD Connect Seamless SSO does have some flaws, although these are relatively few. Issues include:

Client App

• Not all client apps support AD Connect Seamless SSO. The Client App needs to support Modern Authentication, e.g., Outlook 2016 or Outlook 2013 (with a reg key change).
• It is supported on web browser-based clients and Office clients that support modern authentication on platforms and browsers capable of Kerberos authentication.
• Upgrade to Office 2016 if your business is still using this; it is 2018 after all! Any third party apps (e.g., Outlook plugins) that do not support above Outlook 2010.  Don’t let this hinder your cloud SSO solution journey.  Contact the vendor to discuss why their application/plug-in needs to be future proof.

Alternate ID

• When using Outlook for connecting to Office 365, Microsoft’s documentation states the following:

“Seamless SSO supports Alternate ID as the username when configured in Azure AD Connect as shown here. Not all Office 365 applications support Alternate ID.”

• From Core’s experience, AD Connect Seamless SSO for Outlook with Office 365 works best with the default ‘User Principal Name’ for Azure AD Connect Username.
• Although Alternate ID is possible, the user experience is poor as Outlook is hardcoded to use the User Principle Name from Active Directory on initial autodiscover/setup.
• This meant that, during setup, although we did not have to enter the password we did have to change the username to match the email address. We are, of course, happy to be proven wrong, but this is our experience to date.

Core’s advice? Use the User Principle Name as the Azure AD sign-in.

For more information on how to make your Office 365 environment as secure as it can be, download Core's FREE Office 365 Security Best Practices. It's full of useful tips and information to help you maximise the security of your Office 365.