Identity vs. Authentication
When working with Office 365 technologies, it is important to understand the difference between identity – an object, such as a computer, person, or group for example – and authentication, the process of proving the identity. The simplest understanding of the two are identity as a username and authentication as a password. Planning the overall identity and authentication to any of your organization’s cloud services is important to the success of your deployment.
These days, users are faced with a growing list of services, both personal and business – great for getting work done faster, but a potential security nightmare. Simply put, the more apps they have, the higher chance you have of repeat passwords, putting your entire organization at risk. All it takes is a simple password hack on a single application to suddenly hack the rest of your infrastructure.
To avoid potential breaches and company-wide aggravation, it is important to understand your options and how they affect your deployment.
Diving into Identity, organizations will need to choose when to use synchronized versus non-synchronized (called “In-Cloud” in Office 365) accounts. There are a few limitations and considerations with Office 365 for synchronized identities, including:
- Synchronized data – over the years you have built a wealth of data in your on-premise infrastructure. When moving to Office 365, it is imperative that you understand what information you have and how it will be represented, because all of your data is now available across the Office 365 stack. If you make a change to someone’s job title, that change is visible to users within OWA, Delve, etc. If that change hasn’t been communicated yet, you risk an unnecessary level of chaos.
- Routable User Principal Name – Office 365 requires all usernames (userPrincipalName or UPN) to be routable internet domains. The reason for this is so the service can route the authentication to the appropriate provider.
- Unique Values – each identity must be unique. While it is entirely possible in an on-premise environment to have duplicates in some manners, it is not possible to have duplicates in cloud services.
Identities can be changed, created, updated and deleted from either Office 365 or on-premise. However, you must know there should be a single source of authority, which is required for federated accounts. Source of authority would mean only one of the systems (Active Directory or Office 365) is the master of those changes.
You want to make sure that users know their username and that it is something easily identifiable. The most common username in any cloud service is a user’s email address, however it may not always be the case. Some organizations may require a badge ID or employee number, but understanding how this may affect the overall sign in experience will again be crucial to the success of your end users. (Take a look at how multiple domains can disrupt the user experience.)
Outlook will typically ask for a user’s email address to sign in, but it really needs their username (or userPrincipalName), not email address. When users don’t understand this, it leads to account lock outs, frustration, and lack of adoption. Additionally, some applications, like Skype for Business, rely on a user’s identity to match the userPrinicpalName and for the email address to fully and seamlessly integrate. When these don’t match, the users may see broken functionality or additional warnings/popups – ultimately leading to confusion and a bigger headache for you. For this reason, whenever possible, we suggest updating Active Directory to have matching email address and UPN prior to your sync.
Authentication, or what is commonly thought of as the process of validating a user’s password, is one of the more crucial components of the cloud service. Once users enter their username, the service needs to then prove that user is allowed to sign in.
Before you start, first figure out if you need solutions such as Single Sign On. Many organizations want it, but if you need to ensure a higher level of security, like requiring users to always log in, you may not actually be taking advantage of Single Sign On. In this case, you are adding an exponential level of cost – load balancers, SSL certificates, management, etc. while now introducing additional points of failure, administration, and complexity. Some newer toolsets, like ADConnect with Passthrough Authentication, may actually provide the same capabilities at a fraction of the cost and hassle.
To determine the best authentication for your organization, take a look at the table below and the related strengths and weaknesses of each scenario.
|Microsoft||In-Cloud Accounts||• All passwords are handled via Microsoft|
• No local infrastructure
• Users do not need to rely on other systems
|• Management of accounts is limited
• Separate identities, when name changes or offboarding happens, these are not tied together
|Microsoft||Password Synchronization from ADConnect||• Passwords are synchronized quickly (less than 2 mins)|
• Ability to synch password changes back if a user resets in cloud
• Secure copy of password
• No dependency on local infrastructure
• Less administrative overhead
|• Passwords can become in a stuck state – once a user changes it, it could possibly not get changed and be out of sync
• If the ADConnect server is down, no changes are synched
|Your Organization||ADFS||• Ability to granularly control login restrictions|
• Ability to further customize the sign in pages
• Provides Single Sign On
• Custom logging and filtering of user logins
|• Large amount of infrastructure and cost
• Creates points of failures – if a server is offline, or a site is offline, all users are potentially impacted
• Requires third party SSL Certificates (+ related Cost and Management)
|Your Organization||Pass through Authentication with ADConnect||• Less infrastructure|
• No need for SSL Certificates
• Ability to scale out lightweight, redundant nodes for high availability
• Gives users the option for Single Sign On, rather than Same Sign On
|• If Office 365 is unable to reach any of your nodes, all users are unable to sign in|
|Third Party||Using a third party for Single Sign On||• Potentially little to no infrastructure to manage on-premise|
• Third Party support and management
|• Cost can be much higher than other solutions
• Adding in another layer of finger pointing if something goes wrong
As you can see, there are several ways to have authentication verified by the Office 365 – while there isn’t always a right or wrong way, there are ways which reduce cost, infrastructure, and need for support. Identity and authentication may seem simple, but both can have a much greater impact on the overall success of your deployment.
If you’re ready to launch your migration with a partner you can count on, click here. If you have questions on the above, fill out the form below.