The Office 365 Partner Community is led by National Partner Technology Strategists from the Microsoft US Partner Team. Partner Community activities include blog posts, discussions on Yammer, newsletters, and community calls.
- Read the US Office 365 Partner Community blog posts, including the September series about FastTrack
- Join the US Office 365 Partners Group on Yammer
- Sign up for the US Office 365 Partner newsletter
- Register for the November 6 US Office 365 Partner Technical Community call
An important consideration in helping your clients onboard to Office 365 is providing guidance about choosing the right identity model for a given scenario for your customer. This month, the Office 365 Partner Community focus is on Identity Integration and User Management. In my first post in this month's series, I introduced the three identity models: Cloud Identity, Synchronized Identity, and Federated Identity. In this post, I will go into more detail on Cloud Identity and Synchronized Identity.
Cloud identity model
With cloud identity, as the name suggests, all identities are in the cloud. A user signs in with a user name and password which lives in Azure Active Directory (AAD) in the cloud. AAD validates the user and signs him or her into Office 365. I should note here that regardless of the identity model chosen, Office 365 always uses AAD to store the user information.
Cloud identify is the simplest of the identity model options. There are no servers required and typically no on-premises directory. If there is an on-premises directory, the customer is probably using cloud identities for the purposes of an Office 365 trial or POC. With no existing directory to synchronize, you have three options to add users.
- Using the interface in the Office 365 Admin Center, you can add users by typing them in manually.
- To add several users at a time, you can select the "bulk add" option, and upload a CSV file with a spreadsheet of users. On the bulk upload page, you can download a blank template or a sample CSV file that includes the different properties you can add.
- You can use Windows PowerShell to license users. On TechNet, the article Windows PowerShell cmdlets for Office 365 management and deployment explains how to get started and provides some sample scripts.
Pros and cons of cloud identity
When to use cloud identity
- When there is no on-premises directory
- When Office 365 is being used as a pilot
- If your client is undergoing an on-premises directory restructuring
Synchronized identity model
In the synchronized identity model, there is an on-premises Active Directory, and your on-premises users (and optionally, their passwords) are synchronized with those in the cloud. As an admin, you manage your users on-premises and will synchronize those users to Office 365 with the DirSync tool. You can download DirSync from Office 365. You will need one server (either on-premises or in Azure IaaS) that does the syncing and sends the changes. Installing this on the domain controller is supported, but not recommended. DirSync will not synchronize a directory if it contains any errors or inconsistences, so before you install and run it, you will want to run the Office 365 IdFix tool.
Many organizations have had Active Directory for a long time and it is a core part of their operations, with many of their systems relying on it for identity services. Over time, organizations conduct many projects that integrate with Active Directory, adding customizations, dependencies, modifications, and upgrades that can lead to data inconsistencies. Those inconsistencies may be acceptable on-premises, but will not be accepted when you attempt to synchronize that with Azure Active Directory (AAD). Examples of potential problems for AAD are the use of non-routable domains, duplicate email addresses, or invalid characters in required attributes. The process of cleaning up and repairing your directory for synchronization is called Active Directory remediation, and Office 365 IdFix is the tool you use to do the cleanup. Keep in mind that DirSync only works with Active Directory, will not work with multiple forests, and you must have at least a Windows Server 2003 cross-functional level specified. If you find your customer in one of these scenarios we will be taking a look at some new alternatives to DirSync in my next post in this series.
One of the options you have when you run the DirSync tool is to synchronize user passwords where AAD will keep a hash of the password. This means that a user can sign in to Office 365 with the same username and password as is used on his or her on-premises PC. If you don’t synchronize those passwords, the user will need to create a new one in the cloud, and while the passwords may be the same, you still need to create and manage it, and any changes made will not be synchronized.
In my next post I will explain the federation identity model, share information about new tools and capabilities for managing identities, and provide scenario guidance on when choose the federation identify model instead of the synchronized identity model.
I’m looking forward to the US Office 365 Partner Community call on November 6, where we’ll bring all of this together. Register today to join me for that call.