As an Office 365 admin, you might feel the only way to manage users (on occasions!) is with the whip. Unfortunately, that’s not allowed anymore, so you’ll have to get a bit more sophisticated with your management skills.
When users want to access Office 365, they have to be authenticated. Users in your organization will already have a username and password, most likely while using an internal Active Directory. Of course, you could create separate Office 365 user accounts for your users, but ideally you would make them “reuse” existing on-premises accounts.
I’ve put “reuse” deliberately between quotation marks, as technically speaking this is not entirely true for all possible scenarios. More about that later.
User management is very important. You don’t want the wrong users to have access to the wrong resources, or even worse, have hackers gain access to internal data by hacking user accounts. So, think carefully about authentication and authorization options when using Office 365.
Single Sign-On with Your Existing Active Directory
As mentioned above, you can make use of your existing authentication system (like Active Directory) when implementing authentication for Office 365. Before I explain the possible options, you must know that behind the scenes Office 365 uses Azure AD for authentication. Every Office 365 tenant has a separate Azure AD.
There are two possible options:
- Synchronized identities: Accounts are synchronized between Azure AD and your On-Premises directory. You can choose to sync passwords as well, or let users have a different password for both.
- Federated identities: In this model, users always authenticate against your internal directory. When signing into Office 365, users are redirected to your internally hosted identity provider, like ADFS. When signed in successfully, users are redirected to Office 365 and are logged in.
Option 2 is the preferred option and is the only option that allows for a seamless, single sign-on experience. However, Option 2 also requires additional on-premises configuration for the identity provider and is therefore the more complicated option.
Option 1 is the easiest solution to set up. In most cases, organizations begin with Option 1, and eventually move to Option 2. See this excellent Office article for more information.
Multifactor Authentication
Besides the two authentication options for identity management, the third way to manage your users is multifactor authentication.
The idea behind multifactor authentication is that a physical item is required when signing in. In most cases this will be a code sent via text or phone call, or is generated by a mobile app. When logging in with your username and password, a key generated by the multifactor device must also be entered.
In the scenario in which a hacker gains the username and password, they still cannot log in unless they have access to the user’s phone. It’s not impossible, but it makes it much harder for hackers to gain access to a user’s account.
In Office 365, you can configure multi-factor authentication from the Office 365 Admin Center. You can choose which users you want to enable it for, and what to do if the client does not allow multifactor authentication. For example, non-browser clients like Outlook don’t support multifactor authentication yet, but by configuring a so-called app password, users can still use the application.
Office 365 multifactor authentication is based on Azure AD as explained before, and therefore also uses Azure multi-factor authentication. See here for more information.
Options, Options, Options
When it comes to managing your Office 365 users, you have three options:
- Synchronized Identities: User accounts are synchronized between your internal directory and Azure Active Directory. Users have to login twice: once to your internal systems, and secondly to Office 365. Passwords can be synchronized between the two, so users don’t have to remember two separate passwords.
- Federated identities: There is only one user account, which in most cases will be your On-Premises directory account. When logging into Office 365, your identity provider (e.g. ADFS) will be used to authenticate a user. Single sign-on can be implemented such that users have to log-in only once.
- Multifactor authentication: After logging in successfully to Office 365, multifactor authentication requires them to enter a challenge response sent to them via text, a phone call, or generated by a mobile app. Only after entering the code, they can log into Office 365.
There is a fourth option I mentioned briefly earlier – namely, using separate Office 365 accounts, (so-called “onmicrosoft”-accounts, as the format is username@tenant.onmicrosoft.com. This is only useful in demo purposes, or when you don’t have an internal directory, which is unlikely.
What Should YOU Choose?
As discussed, federated identities are, in most cases, the best solution, but it requires more configuration. When you initially sign up for Office 365, you may not want to do all of that right away. Beginning with synchronized identities and moving to federated identities at a future stage is a very solid approach.
Finally, multifactor authentication is a good thing, but requires users to enter a code every time they log in. You may want to restrict this to admins only however, in order to have the best balance between usability and security. Office 365 has awesome features like document management, version control, workflows, team sites, email, Lync, and more. However, if nobody uses it because of overly strict or overly complicated authentication requirements, it is useless.
What do you use to authenticate Office 365 users?
