Authentication, Single Sign On, Directory/Password Sync: Working with Domains in Office 365

Using domains, authentication and when to use Single Sign On vs. Directory/Password Sync is one of the most confusing and misunderstood subjects pertaining to Office 365. I’ve written about this in the past, but before I delve into Office 365, I think it’s important to revisit.

I was once in a situation with a customer where they were absolutely sure they wanted single sign on. In all of our conversations that was the one thing that stood out that was non-negotiable until it came time to review the infrastructure required.

Once you have your domain added to Office 365 and you’ve decided to go Hybrid, you have one more decision to make between simply using Directory/Password Sync or using Single Sign On Federated Domains.

Microsoft has designed Azure Active Directory to be extremely flexible, much more simple to use from a users perspective than Active Directory. When you sign on to Office 365 you are given an identity that looks like You can easily overlay your domain over that and quickly start using your domain. This works much like a UPN through Active Directory, but it’s much more simplistic. Now that you have your domain and want some users in the cloud. The decision comes to behavior and authentication.

What behavior is acceptable to your clients?

Do you want or need to operate additional infrastructure?

Where do you want authentication to occur?

The answer to the last two questions will help determine your answer.

If the answer is I don’t care where authentication occurs and I don’t want to add additional infrastructure. You are going to be using directory/password sync.

Directory/Password Sync:

Directory Sync with Password Sync is a method of copying Active Directory user objects into Office 365. It is a piece of software that needs to be installed on your network, the user that installs it should be a domain administrator since it will be reading from your Active Directory. It’s sole purpose is to copy user accounts and their corresponding password hash to your Office 365 tenant. Once there you can use these accounts for authentication in Office 365. Directory Sync with Password Sync will then operate on a schedule to update your accounts if local changes are made to Active Directory. In the cloud your accounts are read only, Office 365 knows that these are synced accounts and all management is done from your local Active Directory. Your accounts may now differ somewhat in how they are logged in. Active Directory uses a domain/password format for authentication whereas Office 365 will use an email style format

The advantage to using directory/password sync is simplicity. When passwords change, the sync software will update them at set intervals. Your environment complexity is reduced as you don’t need to manage Active Directory Federation Services servers. All Active Directory management will be performed from your on premise Active Directory servers.

In most of my dealings with Microsoft SME’s, they have almost exclusively recommended using Directory and password sync to accomplish user parity with Office 365.

Dir Sync

Single Sign On:

In some cases though you might want or have to use your own site for Authentication, you might need to use Windows authentication format to authenticate and finally you might just want everything to work nicely. One of the issues with Directory and Password Sync is that your account format does change, so if you want to setup your email on Office 365 in a rich client, there will be some configuration and same for Lync. With Single Sign on all authentication requests to Office 365 are redirected to an Active Directory Federation server on your network. Active Directory Federation Services (ADFS)is a server role in Windows 2012/R2. ADFS is a standards based service that allows secure identity sharing and authentication between trusted partners (federation), in our case the trusted partner is Office 365.

The single sign on configuration is slightly more complicated and will take additional planning, it will also require additional architecture. You will need your Directory/Password Sync servers to still sync accounts to Office 365. You will also need to add at least 2 ADFS servers and possibly a SQL server if your requirement is high availability and you don’t want to use the built in Microsoft Database.

The key difference for this environment is the introduction of single sign on. Where you tell Office 365 that your tenant is a federated partner with your Active Directory, this is all done over Power Shell. When you log onto Office 365 in this instance as soon as you request Office 365 resources, Office 365 will redirect you back to your ADFS server for on premise authentication, once this authentication process is complete you will be forwarded back to your service. Single Sign On and ADFS are not only used for Office 365, there are many applications out there that can make use of your on premise identity management and allow you to single sign on to their applications.




The Decision:

Whichever environment you decide on, the important part is the be sure to step back and plan what is acceptable to your environment. The questions to ask are

  1. Do I need to authenticate every Office 365 request?
  2. Do I want or have the capacity and knowledge to add mission critical infrastructure to your environment?
  3. Do I need single sign on?
  4. Do I have other LOB (line of business) applications where it would make sense to have single sign on?

Leave a comment

Your email address will not be published.