In this lesson, we’ll get you started adding users to your tenant. In the last lesson, you created your tenant (which included creating a single admin user), and log into your tenant. Now you want to start adding all your other users into your tenant. Unfortunately, due to the complexity of some scenarios, I won’t be walking you through adding users in the step-by-step manner I did for creating a tenant, but rather giving an overview of the considerations you want to make.
If you do want to get more details about these, in my paid membership offering (which is currently in early access sign up), you’ll have access to scripts and videos walking you through some of these options in significantly more detail!
This is one of the other most important aspects of your Office 365 configuration. While it is possible to switch between them at a later point in time, it’s always easier to choose and configure this before getting too far into your configuration. There are three “types” of users you can have in your tenant and we’ll take a brief look at each one.
- Cloud only users
- Synchronized users
- Federated users
Cloud only
This is the simplest option to choose. However, I ONLY recommend choosing this option if:
- You don’t currently have an on-premises Active Directory server
- You want to decommission ALL your on-premises servers/environment and move everything to the cloud only
In this scenario, your users only exist in Azure AD in the cloud. They have a username and password just like any account, but only exists and can only be used in Azure and Office 365. If you do have on-premises servers and an on-premises Active Directory, these users will be independent of those users. The only way for the passwords to match between on-premises and cloud is if the users set them the same. All of the password policies, expiration policies, etc are sourced from Azure AD.
Synchronized
Synchronized users are exactly what it sounds like it is. This is when your users in your on-premises Active Directory are synchronized up to Office 365/Azure AD. If you have an on-premises Active Directory environment that you plan on using for a while, I recommend you do this right away. If you wait and end up with users that have both a cloud only account, and an on-premises AD account and you decide you want to go back and synchronize them later, it isn’t nearly as easy as setting this up right away.
In order to synchronize the users, you must use Azure AD Connect. This is a relatively simple tool to set up and configure and in addition to just synchronizing users from on-premises AD to Azure AD, it allows you to do things like password write-backs, synchronize Active Directory Groups among others. This allows your users to have a synchronized account that has the same username and password that they can use both on-premises and in Office 365.
Federated
Federated is the final type of identity supported with Office 365. Microsoft will also provide instructions on how to configure federated identity with AD FS. However, this isn’t your only option. There are also third-party solutions such as Okta or BitGlass that can also be leveraged for federated identity with Office 365. Microsoft even provides an Azure AD federation compatibility list if you are using (or want to use) a third-party federation solution.
Federated identity works differently than the other two methods we’ve looked at so far. In both Cloud only and Synchronized, you actually authenticate again Azure AD. With a federated identity, your username and other properties are still stored in Azure AD. However, when you log into Office 365, it recognizes your username as a federated identity and redirects you to your authentication provider to authenticate your user. You then receive a token back from that Identity Provider (IdP) than you can pass provide to an application, in this case, Office 365, for authorization to the application.
This image shows a typical on-premises AD FS configuration
You’ll notice Azure AD Connect is still required to sync the usernames and user properties with Office 365, but the sync occurs without passwords and the authentication takes place with AD FS.
This is definitely the most complicated of the three methods to configure and even to maintain as there are many more moving pieces. However, in some scenarios, this type of configuration is what you’ll want based on SSO requirements, IdP’s already in place, or other applications that are running that already leverage AD FS.
Conclusion
So, as we said at the beginning, before getting too far into your Office 365 deployment, you’ll want to figure out which model you need and set it up right off the bat. While you can switch later, it is far easier to configure it to your needs before getting too far into your deployment.
