Summit 7 Team Blogs

O365 Mac Logins and You

You’ve probably figured out by now that I’m Summit 7’s problem child. I love Macs and use them to get through my day. I don’t want to start a holy OS war, I just prefer to do my work with Macs. I honestly don’t care what operating system anyone uses, so you won’t find me hammering you with Apple propaganda.

You will, however, find me writing blog posts from time to time about issues that flummox Mac users every now and then... especially as they relate to SharePoint. Let’s talk about one of those.

We do a lot of work with Office 365. We even use it for our Summit 7 Systems work. I took it upon myself one day... week... month... some indefinite time period based on priorities... to set up our domain to synchronize with O365. The goal here is to make Single Sign-On work, of course. After you get through the white papers and blog articles on implementing it, your Windows users will be happy to learn that they no longer have to manage their passwords via the O365 portal. That might be a huge plus and it certainly serves to reduce confusion. Mac users, on the other hand, may experience significant confusion.

All of this is based on the health of your Active Directory and kerberos environment. I’ll spare you the long articles about how to get all of this set up. Let’s just assume that you have your Active Directory synchronizing with Office 365 and your Windows users are happy. Since you’re visiting this blog article we may be assuming that your Mac users are either unhappy or confused, however.

First thing’s first: your Mac users should also be joined to the domain. That part of the setup is also a little out of scope of this post because there’s plenty of information on that. Let’s talk about the first symptom of trouble. Your Mac users may report that they were prompted to change their password by the local domain controller. Let’s say they followed instructions and changed the password. A few days later, they discover that O365 is telling them to change the password too. Better yet, perhaps the mail client (Outlook 2011 or Apple Mail, whichever) or Lync are telling them the password is expired or invalid. What’s happened here?

Until just recently Office 365 did not synchronize passwords with your local Active Directory. Macs are rarely joined to a Windows domain in small businesses like ours, so this means the Mac users at Summit 7 have mismatched passwords. You’ll have to manage passwords in two different places - the domain and O365. That’s probably sub-optimal, isn’t it? As a matter of fact, it can happen to Windows users as well. When you combine the mismatched passwords with mismatched password policies, your users can stand to get quite confused. Also consider whether or not you will have an O365 hybrid deployment. A password mismatch between O365 and a local hybrid deployment can lead to sub-optimal results.

If you implement the password sync tool, be careful. A few things happen immediately:

1. Users with “User must change password at next login” checked on the local Active Directory account will be LOCKED OUT of O365 until the password is changed.

2. The ability for users to change passwords at portal.microsoftonline.com is now gone. You MUST have a process or password management solution locally at your business. Your Active Directory will be the master of your policies and passwords. This means...

3. Anyone that is not on the domain will be unable to change their password. This includes Mac users.

4. Administrators of your O365 deployment cannot change passwords with portal.microsoftonline.com even though the system continues to let them do this.

You have a few choices here. You can either get all of your workstations on the domain (Macs included, as I noted above) or you can implement a password management page on your local network.

A few other tips to prepare for this deployment:

  • Make sure you have alternate email addresses and/or phone numbers for all of your users in case they are locked out of O365.
  • Make sure you are in close touch with users who are remote and have a method for them to change passwords without administrative or help desk assistance.

Microsoft’s online documentation about the “interesting” aspects of this isn’t completely up to date. Be sure to test, test, and then after you test, test more. Think about your requirements (always with the requirements!) and your business processes that are impacted before you inflict this change on your users.