Office 365 is without a doubt the single greatest cost optimization and reduction proposition for IT Pros looking to add value to their departments. Looking at Office 365 from an IT Professional standpoint, I am going to help you understand one key point for your deployment: Identity. This is the first of a three-part blog, in this first post I will discuss the basics of identity and cloud identity. In the second post, I will discuss Directory Sync and Password sync and walk through the set up. The final post will be about Single-Sign-On and configuring Active Directory Federated Services.
Let’s start with the basics first. When I write about identity I am referring to the end user’s digital name, sometimes called the “User Name”. Typically with online services this is an e-mail address. For our purposes, we will call it UPN (
User Principle Name) this is actually the name of the attribute in Active Directory used as an internet style login name. Your UPN is generally the user name followed by the domain name and ends with ".com".
Examples:
{Username}@Domain.com
Jeff@contoso.com
So if my name was Ron and I was the business owner of a beautiful antique rocking chair company called “The Rocking Chair” my UPN might look like this:
Ron@therockingchair.com
When you create a tenant in Office 365, a default UPN is built based on the information you put into the Organization name field during your sign up process. A default admin domain from Microsoft (@onmicrosoft.com) is also created.
So, if I put in “therockingchair” and my user name is ron it would look like this.
Ron@therockingchair.onmicrosoft.com
Once you verify your domain ownership of “therockingchair.com” to Office 365 you can change your UPN to
Ron@therockingchair.com.
Having that default admin domain (I call it .onmicrosoft.com) comes in handy when you have a more advanced deployment of Office 365 with Directory Sync and Password sync. We’ll discuss this in the next blog post.
Okay, so with identity there are three models for Office 365 and which one you use depends on your business requirements.
The first model is cloud Identity this is created and completed when you setup Office 365. In this model, the UPN and password for the user are located and saved in Microsoft Online Services. Once you create your account and setup your users you are in cloud identity model. This is great because the Microsoft handles everything, and it’s all online. There is a con to this model, however, because the password your users use to log on to their computers does not match their e-mail in Office 365; it creates a scenario called YAUP “
Yet
Another
Username and
Password”. This can be inefficient and cause problems if you have a large number of users. With just a few users, it’s manageable.
The second model is called Directory Sync with Password Sync. In this model, the UPN from the local Active Directory Server is replicated with the password into Microsoft Online Service for you to use with Office 365, CRM Online, and Windows Intune. With this model, you will need a server to run directory Sync and password Sync, but you only need one server. This model is great for medium and some large organizations that want passwords to match local computer logon UPN and Password.
The third model is single-sign-on, in this model you’ll need to setup several servers and know a thing or two about certificates and load balancing. This model is usually used for very large organizations that have security requirements that necessitate passwords be stored locally. For now, watch the video below to get a better Idea about the cloud identity models and check out the second blog covering Directory Sync with Password Sync before we get into the nitty-gritty of the Single-Sign-On model.
Watch the Office 365 Identity Model Video