There has been a fair amount of confusion and misinformation surrounding authentication for Microsoft cloud services such as Office 365. The intent of this post is to help get us all on the same page on this issue, especially when it comes deploying solutions for authentication to cloud services.

Let me set the stage.

An organization wishes to subscribe to Office 365. They do not want their users to have new usernames and different passwords. Is Single Sign-On or SSO an option?? To achieve SSO, a federated endpoint at the customer site would be necessary. In the case of Microsoft’s Active Directory Federation Services (AD FS), this would typically require at least four servers for full functionality and high availability.

For many organizations, particularly smaller ones, this needs some clarification.

There is a difference between single sign-on and same sign-on. When an organization subscribes to Office 365, for either single or same sign-on, they will deploy a DirSync server. This DirSync server will sync users and distribution groups from the organizations on- premise Active Directory Domain Services (AD DS) up to Microsoft Office 365.

More accurately, it will sync the users and groups into an instance of Windows Azure Active Directory (WAAD or simply referred to as AAD) that is used by Office 365 for authentication. Furthermore, they may also enable the syncing of passwords, which the DirSync server does NOT do by default. When they enable password sync, the DirSync server will initially do a full sync of all user passwords.

Password Sync Confusion/Misinformation #1: People may be concerned that passwords are flowing across the connection between DirSync and Microsoft. The password sync does NOT sync passwords. It actually syncs the hash of the password. So no passwords travel across the connection, and there are no notable security risks involved with password sync.

Password Sync Confusion/Misinformation #2: People may be concerned about password expiration policies and passwords getting out of sync. In fact, if you enable password sync with the DirSync connector, it then disables password expiration policies in the AAD instance, and leaves all password expiration up to the settings in the organization’s local instance of AD DS. So the only time an individual may receive a password expiration warning is when ther local AD DS password is about to expire or already has expired.

Password Sync Confusion/Misinformation #3: When the local password gets changed, the user will not be able to log into Office 365, because the sync of the hash has not occurred. This may happen, IF the user changes their password and attempts to immediately authenticate to Office 365. The default password hash synchronization interval is every two minutes. (The default DirSync interval for syncing users and groups is every three hours) Both intervals are configurable.

So, what is same sign-on? When a user attempts to access a resource in Office 365, they WILL be prompted for authentication, that is, a username and password. HOWEVER, the username and password are the SAME (same sign-on, eh…) as their normal everyday AD DS username and password. Once they enter their username and password, the name and the hash of the password are sent across the Secure Sockets Layer (SSL) connection to Office 365, where the username and hash are checked against the values in the organization’s AAD instance for validation.

What about single sign-on? If the organization wants a true SSO experience, it will need to deploy a federated solution, such as AD FS, Ping, Centrify etc. Then, after a user logs on to the PC, there are no subsequent authentication prompts to access Office 365 resources.

There are user experience differences which the organization must consider (for example, an additional login prompt for same sign-on). If organizations have software-as-a-service (SaaS) requirements beyond Office 365 (Salesforce, Box etc.), then that might justify a federated solution.

IF the organization does not want to deploy a federated solution THEN simply deploying the DirSync server with password sync will allow same sign-on.

To wrap this up, organizations may choose to deploy DirSync with password sync, achieving same sign-on, and NOT choose to deploy AD FS or any other federated solution.

I hope this helps clear up some of the confusion around single sign-on, same sign-on and password sync. The DirSync solution that has been in place for the past couple of years for Office 365, and with the addition of password sync, provides a simpler alternative for authentication than federation particularly for smaller organizations.


2 thoughts on “What is Same Sign On Anyway?

Comments are closed.