More important than storing and having access to business documents, appointments and contacts from anywhere, whenever necessary is to secure that none of that information ends-up on the hands of strangers or publicly available.
One of the most important tools to secure the data and the accounts are multiple-factor authentication methods (MFA). MFA ensures that even if any password is leaked or weak, the system will ask a second authentication method that can identify the person requesting access. This is usually done by security tokens or mobile apps that the proper user has physical access to.
LinOTP comes into play on this scenario by providing means for the company to maintain private MFA methods and integrate with Windows Servers, local Active Directories, Linux and Mac OS machines, RADIUS and also with online Azure Active Directories and the Office 365 suite.
By using LinOTP in with Office 365 and Azure Active Directory the company moves the authentication from the cloud to on-premise servers and maintain total control over the data and authentication process, including the ability to add MFA to any user that is necessary.
User Directory Integration Concepts
There are mainly three ways to setup an on-premise directory integration with Office 365 and/or Azure Active Directory. Two of them are simpler to setup but lack custom MFA providers support. I will briefly describe each one but hold in mind that only one of these methods can be used to integrate with LinOTP: The Active Directory Federation Services (ADFS) integration as it is the only one that supports Multiple Factor Authentication (MFA) providers. These are the options:
- Directory and Password Hash Synchronization with Single-Sign On (PHS with SSO)
- Pass-Through Authentication with Single-Sign On (PTA with SSO)
- Active Directory Federation Services (ADFS with SSO) integration
In order to integrate with LinOTP the company must migrate from PHS or PTA setups to the ADFS setup.
Password Hash Synchronization with Single-Sign On (PHS with SSO)
On this scenario, a user logs on to the company on-premises environment with their user account (domain\username) and when they go to Office 365, they must log on again with their work account (email@example.com). The user name is the same in both environments. When you add password hash sync, the user has the same password for both environments, but will have to provide those credentials again when logging on to Office 365.
Every two minutes, the Azure AD connect server retrieves password hashes from the on-premises AD and syncs it with Azure AD on a per user-basis in chronological order.
The password hashes are stored on the cloud, what makes this also the most insecure option. User data and password hashes travel the Internet and are stored somewhere on Microsoft Cloud servers.
Pass-Through Authentication with Single-Sign On (PTA with SSO)
When the Seamless Single-Sign On (SSO) is enabled on the synchronization agent, the user will not need to enter his/her password again and sometimes not even the user name. The SSO option enables Kerberos authentication from the Azure AD against the on-premise Windows Server AD, automatically signing in into both on-premises and cloud-based applications.
Azure Active Directory Pass-through Authentication allows users to authenticate in to cloud apps using same passwords they are using in on-premises without syncing their password hash values to Azure AD. There is a lightweight agent installed on the company servers that uses the same underlaying technology as the Active Directory Federation Services (ADFS) to authenticate cloud users.
On-premises passwords are never stored in the cloud in any form, but the passwords are entered on Microsoft servers and websites, hashed and then the authentication proceeds using Kerberos. Although no password or hashes are stored on Microsoft Cloud servers, the data is entered on services that could be running anywhere on the world and are not only on-premises.
Active Directory Federation Services (ADFS) Integration
The third and most complete integration solution uses a full fletched ADFS integration. This requires at least two extra servers as well as CA recognized certificates for secure communication purposes. This is the most powerful and flexible solution of all three and the only to support third-party Multiple Factor Authentication (MFA) providers, like LinOTP ADFS Connector. Other examples of features that can be only used with this configuration are: the use of smartcards for authentication, enforcing conditional access rules (on ADFS) and on-premises Windows 10 conditional access based on device profiles and certificates.
This is by far the most secure of all three options. If the corporate security policy requires that passwords always remain on premises, this is the only option because PHS stores the hashes online and in PTA the user’s password is entered into Azure AD before it goes on premises.
The ADFS integration does not support the Kerberos integration used on the Seamless SSO. At the same time, by using federated sign-in, all users can sign in to Azure AD-based services with their on-premises passwords. While they are on the corporate network, they don’t even have to enter their passwords.
How does LinOTP integrate with ADFS
This advanced setup starts the authentication on Microsoft Cloud and services with the identification of the user on the Azure AD and flagging it as an integrated user. All non-integrated users are authenticated on the cloud servers while the flagged users are redirected to the authentication portal provided by the on-premise Web Application Proxy.
From now on the user is actually using on-premise servers and network and the data will not be routed through Microsoft Cloud servers. On the authentication portal the user enters his on-premise password and, if valid, the ADFS server will trigger the LinOTP plugin to validate the MFA data.
Our plugin looks for the user on LinOTP using the User Principal name or SAM Account name, accordingly to the plugin configuration. The plugin returns the MFA input form to the ADFS server, which will embed on the login portal as a second authentication step.
After the user enters the MFA token the plugin will validate it with the LinOTP server and return to the ADFS server an authentication status. With a valid MFA authentication the ADFS generates a token that will be sent back to Microsoft Cloud servers and will be used to validate the authentication on the online services, like Office 365, from now on.