There are often preconceived ideas around what ADFS provides and whether it is required when you are moving to Office 365. The below points cover some common conversation that we have with customers.
Number 1: Matching Passwords with on-premises
It is often believed that ADFS is the only way to provide users with the same login and password for Office 365 that they’re using in Active Directory; this is not the case.
Using Directory Sync, you can synchronise the user password hash from Active Directory into Office 365 and provide users with the same password. Subsequent password changes are synchronised to Office 365 within a couple of minutes of changing in Active Directory. A password hash is synchronised to Office 365 in a one-way mathematical computation based on the user’s password which is non-reversible to gaining a plain text password.
Number 2: Single Sign-On End User Experience
As previously mentioned, password synchronisation provides users with the same password in Office 365 that they use for Active Directory; this is known as ‘same sign on’. With ADFS, you can sign into a workstation connected to Active Directory domain without the need to re-enter your password when you connecting to Office 365 services; this is known as ‘single sign on’. The exception is the Outlook client which does not support single sign-on. Users are prompted to enter their credentials and can choose to ‘Save My Password’.
Number 3: Infrastructure Required
When you implement ADFS with Office 365, you are passing the password authentication from Office 365 to your on-premises identity platform. If the ADFS environment becomes unavailable, users are unable to login and will be unable to access Office 365. With that in mind your ADFS infrastructure needs to be designed with resilience.
Providing ADFS redundancy requires multiple ADFS servers, load balancing and internet link failover. Choosing to host the ADFS on-premises can require additional hardware and infrastructure. Alternatively, you could choose to host ADFS in Azure or another data-centre that links into your Active Directory environment.
Number 4: Sign-in Restrictions by location or Working Hours
In order to leverage this ability to restrict access to Office 365, you will require ADFS services or a federated sign on provider. ADFS provides the ability to restrict access by network location and makes use of the restricted logon hours you can set on accounts within Active Directory.
Number 5: Ongoing Maintenance and Administration
An often forgotten point when installing a new solution is who will maintain the infrastructure going forward. If you choose to host your ADFS configuration on-premises you need the skills to administer, update and maintain an environment which is providing live sign-on services to Office 365. An alternative is looking to a third-party provider who can host your federated login infrastructure and remove the admin overhead.
Number 6: Real-time Account Disabling and Auditing
With ADFS in place, a user’s login request is passed to the on-premises Active Directory infrastructure for validation. As a result, you have the ability to disable accounts on-premises with real-time effect to Office 365 services. You also have the ability to audit login events centrally within your Active Directory event logs.
Without ADFS in place, an alternative would be waiting for Directory Sync to synchronise the change to Office 365 on its next scheduled sync, typically every 30 minutes, or manually forcing a sync to Office 365. You could also choose to reset a user’s password which will synchronise to Office 365 within a couple of minutes.
In Summary
If the main driver for implementing ADFS is providing users with matching login details, you may consider AAD Connect with password synchronisation as a better fit. This provides you with a robust solution that can be changed to ADFS at a later date if required.
Get in contact today at hello@cloudbusiness.com to discuss your requirements and see what the best fit is for you.
