In Office 365, there are several different ways users can be authenticated. In this article, we’ll look at the advantages and disadvantages of each.

1. Standard Office 365 Password

This is the default method for login authentication in Office 365. Organizations create a user account in Office 365, and the user is given are given a temporary password. If the user currently has to authenticate against Active Directory (AD) to sign into their workstation, this login ID will be completely separate from their Office 365 ID, meaning a different password and username.

Now, you could set the username and password between AD and Office 365 to be the same, but the user would have to maintain keeping the passwords as they change them. If you don’t currently have AD, this is really your only option.


The main advantage here is simplicity and reliability. If a user forgets their password, the administrator signs into the portal and resets it for them. Since the Office 365 ID is completely separate from AD, if it were to go down, or there was some sort catastrophic failure of your on-premises environment (flood, fire, earthquake), users would still be able to sign into their Office 365 mailbox, assuming they had internet connectivity from their home.


First, users will be prompted for credentials, when accessing Office 365 services. Outlook users have the option to “remember my Password’, but for services like SharePoint and Outlook online, you’ll be prompted.

Second, the users have to remember another password, and the administrators will almost certainly have to perform a lot of password resets. This problem would mainly present if you are just using Outlook. If the user checks ‘remember my password’ in Outlook, it’ll never prompt them for their credentials – until their password expires. When the password expires, they’ll need to sign in the portal to reset their password. In order to reset their password they need to first know their old password, which they probably don’t know since they haven’t typed it for 90 days. The end result is an influx of password resets, every 90 days. If you are also using SharePoint or Outlook Online, it’s less likely you’ll run in this scenario, as the users will be prompted when they access those services, so they are less likely to forget their password.

This was a big problem in BPOS, and many customers simply set their passwords to never expire. With Office 365, this is still an option, using the PowerShell you can set your user’s passwords to never expire. As insecure as that might be, some organizations find it better than everyone forgetting their passwords on 90 day cycle.

Other Notes

With this approach you are tied to Office 365’s password policy which is:

  • Passwords must be between 8 and 16 characters
  • Passwords must contain a combination of upper and lowercase letters
  • Passwords must contain at least one number or symbol
  • Passwords must not contain your username
  • Password must not be the same as the previous password
  • Passwords must be changed every 90 days (unless you set a user’s password to never expire through PowerShell)

2. MessageOps password synchronization

The second option is to synchronize your user passwords from your local AD to Office 365. When a user changes their password in the local Active Directory, it is set to the same value in Office 365. This eliminates the need for the users to remember multiple passwords, and reduces help desk calls for Office 365 password resets.


The biggest advantage here is that the users only have to remember a single password. While there is some connection between the local AD and Office 365, users could still authenticate against Office 365 in the event of a catastrophic failure. It’s also fairly simple to install, configure, and troubleshoot. If one of the components of Password Synchronization failed, users could still easily sign in to Office 365.


First, users will be prompted for credentials when accessing Office 365 services. With Outlook, you have the option to ‘remember my Password’, but for services like SharePoint and Outlook Online, you’ll get prompted.

Second, to make the solution work, you do have to install an agent on all your domain controllers. So, there is software that has be installed, configured, and managed in your on-premises environment.

Other Notes

With this approach, you are tied to Office 365’s password policy, which was outlined previously. To make this work, you have to set you local AD password policy to the same levels of complexity, which is probably another disadvantage for most organizations.

In your local AD, it’s not possible with out of the box policies to disallow things like Unicode characters in passwords, or a max password character length. So, it is possible that a password could pass AD’s password requirements, but fail to be set in Office 365. For this scenario, MessageOps Password Sync notifies the user by email that the password reset failed.

3. Federated identities

One of the greatest features that people talk about with Office 365 is single sign on. ADFS is what facilitates the single sign on. With federated identities, your users are authenticated against your local AD when they access Office 365.


  • Users only have a single username and password
  • Users aren’t prompted for credentials when accessing Office 365 services, if they are logged into the domain
  • Administrators control the password policy. If you want three character passwords, three character passwords you shall have.
  • Multifactor authentication is possible


It’s our opinion that the capabilities of ADFS have been oversold a bit. In short, it doesn’t make sense for everyone, especially small organizations.

First, in order to run ADFS, you are going to need some on-premises hardware. In small organizations, you could install the ADFS roles on existing servers. More on this in a minute.

Second, AD FS is can be quite complex to deploy. Deploying a single ADFS server and ADFS proxy in a .dmz is pretty easy, but when you get into adding redundancy and failover capabilities to the solution, the complexity level can drastically increase.

Third, and this is probably the biggest for a lot of small and medium businesses, if your AD is not accessible, or your ADFS server isn’t functioning, users won’t be able to sign into Office 365.

So, if your AD is currently housed on-premises without redundant network or power, if you lose power or network, users won’t be able to access Office 365 services, even from a remote location. Consider if your accounts in Office 365 don’t have passwords, Office 365 is relying on the AD to authenticate the users, and if your AD isn’t available, nobody is getting in. In the event of a catastrophic failure where you AD or ADFS is going to be offline for an extended period, it is possible to convert back to non-federated IDs, but it would require that you distribute everyone a new password, which might be difficult if they can’t sign into email.

Given how critical the ADFS infrastructure is, you’ll probably want redundancy for each component. That would mean at least 2 ADFS servers and proxy servers. If you want geo redundancy, it’s probably going to be a matter of having a server on standby, updating DNS records, and letting them propagate. Sure, there are other ways to provide high availability, but they would either involve significant investment or placing a DC in a cloud service such as Amazon EC2, which not everyone is comfortable doing.

We also have some concerns about the supportability of ADFS. ADFS is a pretty new and somewhat complex technology. For it work, there are pieces that you control and pieces that Microsoft controls. If it suddenly stops working, we could potentially see some finger pointing occurring, with each side blaming the other. Also, our experience in dealing with Office 365 support for ADFS issues hasn’t been ideal. Again it’s a technology that even seasoned AD administrators don’t know much about, so to expect an Office 365 call center rep to know much about it, and how to troubleshoot, is probably unrealistic.

Other Notes

It may seem like we are totally against ADFS. That is not the case. It’s a great solution for enterprise customers that can deploy it in highly available configuration. Even if you don’t deploy redundancy, in an emergency you could stand up another ADFS server in under an hour to get users back up and running. The benefits are incredible, we just wanted to highlight some of the shortcomings as we have seen organizations with fewer than 100 users trying to deploy AD FS, which in our opinion is not a good idea.

Have a question or need help? The experts at MessageOps are ready to assist you. Contact us today to learn more. You might even qualify for free implementation or migration assistance.

Was this article helpful?