1. Home
  2. Training Library
  3. Microsoft Azure
  4. Courses
  5. Planning for Microsoft 365 Implementation and Migration

Identity Types in Microsoft 365

play-arrow
Start course
Overview
DifficultyBeginner
Duration1h 10m
Students551
Ratings
4.6/5
starstarstarstarstar-half

Description

Microsoft 365 represents a combination of Office 365, Windows 10 and Enterprise Mobility offerings – providing the most complete set of SaaS technologies that Microsoft has to offer. With Microsoft 365, organizations can deploy a complete solution encompassing both devices and applications, along with applying security and compliance policies to protect the entire suite.

This course will help you as you plan your migration of users and data to Microsoft 365, including planning your identity and authentication solution, and the on-premises infrastructure needed to support your migration. We’ll also help you understand and identify your business requirements and use cases, to help drive your decision-making process when planning to transition your infrastructure to the Microsoft cloud. We’ll spend some time focusing on networking and discuss some of the networking decisions that need to be made to ensure an optimal migration experience, as well as the best experience for your users after migration.

This course will also help you to identify which data needs to be migrated to the cloud, and what the best migration method will be based on your scenario – we’re also going to cover the different types of user identities, how your users will authenticate, and how that’s going to affect your migration planning.

In addition to talking about these different components, we’re also going to run through a few demos – showing you some of the practical steps involved, along with some tips and tricks we’ve picked up along the way. 

Learning Objectives

By the end of this course, you should be able to:

  • Plan a Microsoft 365 Implementation, including the supporting infrastructure
  • Plan your identity and authentication solution, both on-premises and in the cloud
  • Identify your users, data, and mailboxes to be migrated to Microsoft 365
  • Plan the migration of your groups and user data to Microsoft 365

Intended Audience

This course is intended for people who:

  • Want to become a Microsoft 365 administrator
  • Are preparing to take the Microsoft’s MS-100 exam 

Prerequisites

To get the most from this course, you should have a general understanding of networking & server administration as well as IT fundamentals such as DNS, Active Directory and PowerShell.

Transcript

There are essentially three types of identities in Office 365, Cloud identities, synchronized identities, and federated identities. In the cloud identities scenario, you have no on-premises servers, or at least no on-premises integration. This is best suited for companies that either don't have an existing Active Directory, or don't really require any integration with their AD accounts and their Office 365 accounts. While it's possible to operate like this, it's not optimal as your users will have two completely separate usernames and passwords, and they're not kept in sync. Of course, if you're not using AD and your users are already used to signing into a webpage for email and applications, like using Google Apps, for instance, then this option could be a good fit for you. 

Cloud identities are the easiest to set up, as you'd provision and license your users in the Office 365 portal, and you're done. However, if you have Active Directory already existing on premises, and you require integration with your line of business applications and servers, you're more than likely going to want to look at synchronized identities. With a synchronized or hybrid identity, your starting point and your source of authority is Active Directory. Rather than creating your users directly in Office 365, you would continue to provision your users as you always would through your existing AD tools. Microsoft provides a synchronization tool called Azure AD Connect, or AAD Connect for short. This tool used to be called DirSync, and you might still hear it called by that name sometimes. AAD Connect is installed on a server in your Active Directory, and it takes your users contacts and groups, and then makes a copy of them in Azure Active Directory. Azure AD Connect can also be configured for password hash sync, which essentially takes your passwords from Active Directory, creates an encrypted hash of those passwords, and then synchronizes the password hash into Azure AD. 

AAD Connect has had numerous improvements and features upgrades over the years, including the ability to now do both Seamless Single Sign On and password authentication. Seamless SSO allows your users to sign into their desktops once, obtain a Kerberos token, which is then used to seamlessly authenticate in Office 365 applications. Pass through authentication can be pared with Seamless SSO, but they're different technologies. We'll talk more about pass through authentication, ADFS and Seamless Single Sign On in a little bit. For now, just know that synchronized identities with AAD Connect are the most common identity type in use today, and probably will be for some time to come. The final identity type is a federated identity using Active Directory Federation Services, or ADFS for short. With federated identities, your authentication happens against your on-premises servers, and not in the cloud. With this identity type, you don't typically synchronize your password hash into Azure Active Directory, although you could, this scenario is used most often for giving users single sign on, and for federating with third party applications and services. 

With a minimum of five servers required to properly deploy ADFS, it is the most complicated identity scenario. As you might expect, having ADFS gives you greater control, and, in many cases, greater security options as well. However, the advantages of ADFS are being slowly knocked over by AAD Connect as Microsoft continues to build out Azure AD federation and Seamless SSO in the AAD Connect application, rather than ADFS. While you might still have a business case for needing ADFS, federated identities are becoming less and less common now.

About the Author

Jeremy Dahl is a Senior Technology Consultant who has spent the last 8 years focusing on Microsoft 365 technologies and has been an Office 365 MVP for the last 6 years. Jeremy is a self-proclaimed cloud addict who architects technology solutions that combine cloud technologies with on-premises solutions, allowing organizations to make the most of their existing infrastructure while still taking full advantage of the agility and scalability of what the cloud has to offer.

Jeremy can be found blogging about Microsoft 365 technologies on his website, masterandcmdr.com, and evangelizing the Microsoft cloud on Twitter.