Chris is a Senior Software Engineer at ThreeWill. His area of focus is consulting in the development of Microsoft .NET and SharePoint technologies. His primary role has been development lead in recent projects. Project roles have ranged from Development/Technical Lead to Development Resource.
User Management / Authentication in Microsoft 365
It is important to understand how and where your users will be managed when planning for Microsoft 365.
Users must have a cloud identity in Microsoft 365 in order to assign licenses and services. How users are established in Microsoft 365 is the tricky part… at least in the beginning.
Note: The following paragraph is only important if you plan to use your company’s domain within Microsoft 365 (see Verify your domain in Microsoft 365 for more information).
I know when we (ThreeWill) initially decided to configure Microsoft 365, we jumped the gun a bit… and went ahead and set up a few users directly in Microsoft 365 BEFORE pulling in the WordPress-647099-2144346.cloudwaysapps.com domain. When we added the domain and began working through the email/Exchange migration, duplicate user names were created in Microsoft 365. Basically, we had a threewill.com users (email@example.com) and similar threewill.onmicrosoft.com users (firstname.lastname@example.org). Cleaning things up required folks that we already kicked the tires in Microsoft 365 to stop using their identities with threewill.onmicrosoft.com and switch to using the new WordPress-647099-2144346.cloudwaysapps.com user. Licensing for the duplicate accounts had to be moved around and the threewill.onmicrosoft.com accounts had to be removed. All in all, this was not a big deal and was easy to tidy up. I am mentioning it here in case it helps you avoid a similar situation. Get your user identities set up correctly before turning them loose on Microsoft 365.
There are several identity models to consider when configuring your users (user identities).
The following description comes directly from Understanding Microsoft 365 identity and Azure Active Directory. The configuration for each of the identity models listed below gets more complex based on the order of the items listed.
Cloud identity. Manage your user accounts in Microsoft 365 only. No on-premises servers are required to manage users; it’s all done in the cloud.
Synchronized identity. Synchronize on-premises directory objects with Microsoft 365 and manage your users on-premises. You can also synchronize passwords so that the users have the same password on-premises and in the cloud, but they will have to sign in again to use Microsoft 365.
Federated identity. Synchronize on-premises directory objects with Microsoft 365 and manage your users on-premises. The users have the same password on-premises and in the cloud, and they do not have to sign in again to use Microsoft 365. This is often referred to as single sign-on.
Can your user identities live in Microsoft 365 alone?
This may well be the case if you are a small company and want to keep user management completely based in the cloud with no need for on-premises Active Directory (AD). Cloud identity may be a great fit here. It is a great way to keep things simple.
Do you have to have on-premises AD (maybe for on-premises Exchange, Lync, or purposes related to user policy) and require user profile details remain in synch with Microsoft 365?
If so, do you require a single-sign-on (SSO) experience?
If yes, Federated identity is likely the best fit. This is the most complex of the identity models because it requires use of an on-premises Active Directory Federation Services (ADFS) or a third-party identity provider. The user password is verified by ADFS or the third-party provider.
If not, Synchronized identity is likely a good fit. This will require the use of a directory synchronization tool, such as Azure Active Directory Synchronization Tool (or DirSync). DirSync is used to synchronize passwords, along with other AD attributes.