To ADFS or not to ADFS that is question… So this is a topic that frequently comes up in discussion with customers and I thought that it would be good to put something together where we discuss the business benefits of both identity solutions.
Something I find missing from most technical articles that talk about ADFS or Synchronised or even cloud identity for that matter is why you might choose one method over another. I think that it is really important to keep in mind as a consultant that every customer has a unique set of requirements and a solution which might fit one customer is not necessarily going to suit another.
I realise that for the most part that this is a given, but you would be surprised at how often I see a consultant design a solution based primarily on their knowledge of having done something similar before and therefore defaulting to this, instead of considering other possibilities and working in consultation with the customer to determine exactly what they need as opposed to what they tell you that they want!
There are some key questions I believe should be asked first to determine what are the primary driving factors for choosing one identity model over the other. These questions need not be from a technical stance, but more from an operational approach and most importantly should focus on what long term aspirations the business has. What is their 5 year roadmap, do they want to ultimately be on the cloud or do they see themselves operating in a hybrid model with some services still on-prem?
So what are these questions, what do I need to be asking my customers? Well we need to be asking the type of questions that make them consider what their non-negotiables are, what type of user experience they are chasing and what value proposition they expect to get from the project.
To summarise, here are some template questions that are a good starting block to make the often blurred line of what the customer wants versus what they need clearer.
- Would you consider your user base to be fairly comfortable with the concept of logging into and authenticating to multiple systems. – Use examples to make them really think about what you are asking them. Most users are comfortable using for example Facebook, LinkedIn, Gmail, etc. and so the process of logging into another system is not going to be something that is new to them. We as consultants tend to forget that most of our user base are becoming more and more comfortable with technology as a service and how it is becoming much more commonplace in our day to day world.
- Consider the type of support calls that you receive from your user base, what percentage of them are related to lost passwords, forgotten usernames, etc.
- What security do you require? This is a rather pointed question but is essential in understanding the type of identity model to implement. For example is there a requirement to restrict users to accessing Outlook whilst on the corporate WAN only, or do you want to limit when users are able to use ActiveSync?
- Do you have a current multi factor authentication model in place, is there a plan to continue to use this and try and integrate this with Azure AD, or would you be happy implementing the multifactor offering provided in Azure AD premium?
- Is there a concern over syncing password hashes to the cloud, could this be mitigated with a simple information session where you as a consultant explain exactly what this means and how this process happens.
- Do you have the in-house capability to support a complex identity model, is your IT department skilled in this particular area. Could your IT department recover from an outage or a system failure within a specified time frame. Could you hold them to an SLA to support this system?
- What are the infrastructure requirements, do you have the bandwidth to spin up new servers?
- What is the desired user experience, would your user’s be comfortable with entering their login details and selecting “remember my password” at first login and then at subsequent password changes?
- How much of your user base work from the office on a regular basis, how many of them work from home or off site?
I am certain that there will be a host of other questions that need to be asked, the above are however a good starting point to engage the customer and get a conversation happening.
Let’s now move onto looking at the different identity models themselves in more detail.
Cloud Identity is the simplest method for providing user authentication in Office 365. Users are completely managed and stored in the cloud. Specifically, users are stored in the cloud in Windows Azure Active Directory and managed via the Office 365 Admin Portal or via PowerShell. In this model users are only stored in the cloud and are not associated with any on-premises identity provider like an on-premises Active Directory.
AAD Connect (Directory Synchronization with Password Sync)
Directory Synchronization is used when you have an existing on-premises directory and you want those same users to have access to Office 365. By installing AAD Connect, this tool will sync the user accounts up to Office 365 every 3 hours. It eliminates the need to manually create and manage users in the cloud. And with Password Sync, it also eliminates the need to manage user passwords in two different locations. User identities and passwords are created and managed on-premises and synchronized to the cloud.
With Federated Identity, also known as Single Sign-On, you authenticate to Office 365 using your on-premises identities. This is commonly done with on-premises Active Directory using Active Directory Federation Services (ADFS). ADFS requires deploying additional servers both internally and Internet-facing. In this scenario, if for any reason users are unable to authenticate via their local AD, then users will not be able to authenticate to Office 365 and will not be able to access any of the Office 365 services. It is therefore highly recommended that you deploy this particular scenario with high-availability / redundancy in mind. With the release of Azure IaaS, we are seeing more customers beginning to consider and start hosting ADFS infrastructure within Azure to solve the high-availability issue. This approach can also be beneficial when there are environmental considerations to keep in mind, for example we have a customer in Brisbane who lost access to their entire infrastructure during the 2011 floods. By making the decision to position their ADFS servers in Azure they were able to mitigate this risk and could should an incident like this happen again continue servicing users.
If you want to know more about hosting ADFS infrastructure within Azure then I would highly recommend that you have a read of this white paper, take it to bed with you and a hot cup of jo. Office 365 Adapter: Deploying Office 365 Single Sign-On using Windows Azure. This content looks set to move soon so here is another link which also has some good reading points. Understanding Office 365 identity and Azure Active Directory
So this gives you a good overview on each of the identity models, what’s interesting is that with each release of the directory synchronisation tool AAD Connect more features become available that begin to make synchronised identity a more appealing option to many businesses particular SMB clients. The reason for this is largely due to the additional cost and complexity of deploying the required additional servers and high-availability that comes with a Federated Identity model.
There are a number of arguments to support both models, I believe that each model has its place and neither should be overlooked as a solution but perhaps what would be helpful would be to understand the different options from different perspectives, which is what the following aims to do.
The User Experience:
We can see in the table above which compares the user experiences that whilst ADFS does offer a more seamless sign on experience it does not differ greatly from directory synchronisation in applications like SharePoint online. It is important to understand that whilst many tout ADFS as being SSO (Single Sign On) it is in fact not and the SSO experience is limited to the service offering in question. For example SharePoint and CRM online are not single sign on aware applications, and users will still need to authenticate to these even when a domain joined workstation is connected to the internal network.
Skype for Business (aka. Lync) is really the only application where single sign on offers that seamless experience for the end user. So, therefore one of the questions when considering ADFS should be, “is the additional infrastructure, resources required and extra spend justified knowing that it is not a true SSO solution?”
Fun Fact: Did you know that Skype for Business (aka. Lync) is what we call an active requestor application, it is aware of the ADFS server and talks directly to it to get a token to be used to connect to Office 365. Outlook on the other hand is not and any token retrieval is handled under the hood by Office 365.
The branding is another hot topic, we would like to brand our sign on page, we can only do that with ADFS…. Mmmmh not so, once upon a time branding was only available to customers using Azure AD Premium or ADFS. It is now a feature that is available for free and allows customers to brand their Office 365 sign on page with their corporate logo and images, you can even put a disclaimer or a hello at the bottom of the sign on page. And get this, it’s available to you without ADFS. Yes that is right you can brand the sign on page when using AAD Sync for all of your users.
I don’t know about you but in my experience most users won’t remember a seamless migration to the cloud nor will they have any knowledge of the fact that you may have picked up your entire organisation and moved them to exchange online. What they will remember however is a new experience, something that is different from what they do everyday and this is something that be achieved easily and for free!
Moving on, there are some reasons that customers will still prefer ADFS and directory federation over AAD Sync with Password Sync. Some of these reasons include:
- ADFS can be configured such that users who are already logged on to a domain joined and connected machine do not require any password re-entry to sign in to Office 365. (Arguably thought if you select remember my password the same can be said for AADSync with password sync.) This gives you true single sign-on since re-entry of the password is not required. With AADSync and password sync a user must still re-enter their password, although it will be the same password as the one that they use on-premises.
- ADFS allows for client access filtering, which restricts access to Exchange Online to users based on their IP address, you can also limit when users are able to use ActiveSync, when they can access Outlook etc. using Client Access Policies.
- ADFS will honour Active Directory configured login time restrictions for users.
- ADFS has the ability for users to change their passwords whilst they are outside the corporate network. (Cloud Auth also does this, but that is another post for another day)
- ADFS permits use of on-premises deployed multi-factor authentication products.
The Admins perspective
As many of you reading this blog post would know implementing ADFS using traditional methods means a lot of additional infrastructure, it also requires additional technical knowledge that not all in house IT departments have. In addition there is a requirement to ensure that the ADFS infrastructure is highly available at all times, an outage of ADFS can be compared to that of a domain controller going down. It is a serious outage and would result in users being unable to authenticate.
There is also a common misconception that by installing directory synchronization with password sync that if the ADFS servers were to go offline then users could still authenticate using password sync. This is not the case, it would take approx. 3 hours to cut over to password sync and in that time the ADFS servers could have been brought back online. This is a caveat that is worth bearing in mind when considering using ADFS.
Another frequent complaint is that the support desk is inundated with I’ve forgotten my password requests and I need users to be able to reset their passwords on the fly. Did you know that this functionality is available for subscribers to Azure AD Premium using directory synchronisation with password right back. Previously a feature that was limited to ADFS.
Azure AD Premium, you hear me say… mmmh that sounds expensive! Well its pricey compared to the free version of course, however it is a lot cheaper than implementing ADFS and it may just offer some of the key services that your customer was previously considering ADFS for!
So what are some of the cool features? Well there is:
- Microsoft Identity manager or Forefront Identity Manager
A whole other topic!
- Self Service Password Reset (write back to on premises)
Enabling your users to manage their own cloud Azure Active Directory or on-premises Active Directory passwords takes just a few simple steps.
- Advanced Security Reports
You can use Azure Active Directory’s access and usage reports to gain visibility into the integrity and security of your organization’s directory. With this information, a directory admin can better determine where possible security risks may lie so that they can adequately plan to mitigate those risks.
In the full Azure Management Portal, reports are categorized in the following ways:
- Anomaly reports – Contain sign in events that we found to be anomalous. Our goal is to make you aware of such activity and enable you to be able to make a determination about whether an event is suspicious.
- Integrated Application report – Provides insights into how cloud applications are being used in your organization. Azure Active Directory offers integration with thousands of cloud applications.
- Error reports – Indicate errors that may occur when provisioning accounts to external applications.
- User-specific reports – Display device/sign in activity data for a specific user.
- Activity logs – Contain a record of all audited events within the last 24 hours, last 7 days, or last 30 days, as well as group activity changes, and password reset and registration activity.
- Multi Factor Authentication
Azure Multi-Factor Authentication helps safeguard access to data and applications while meeting user demand for a simple sign-in process. It provides additional security by requiring a second form of authentication and delivers strong authentication via a range of easy verification options:
- phone call
- text message
- mobile app notification—allowing users to choose the method they prefer
- mobile app verification code
- 3rd party OATH tokens
If you want to learn more about Azure Active Directory Premium I would encourage you to take a look a session that a colleague of mine did, Mark Rhodes at the Ignite conference on the Gold Coast.
So in summary what are we saying… We are saying that when it comes to choosing an identity model go with the simplest solution that suits your requirements. You are not locked into any of these identity models and should you find that your requirements change down the track then going to ADFS from synchronised is a doable exercise as is going to a synchronised identity from ADFS.