When I wrote about the differences between Office 365 Plans P and E and the choice that small businesses make when they decide which plan to use, I omitted to discuss the question of password policies. For users of Plan P (for professionals and small businesses), the policy is simple: your password never expires - at least, I thought that this was the case until Monday, December 12, when my password expired! More on this below.
However, for users of Plan E (for enterprises), passwords have always automatically expired after 90 days. This is the standard policy applied across all Office 365 tenant domains that use Plan E and is in line with the general Microsoft security recommendation for Windows deployments to change user account passwords on a frequent basis.
Expiring user passwords (except mine) after 90 days sounds like an excellent idea as it will force users to consider the small matter of security and cause them to figure out what their new password should be. And when they’ve done that, they can paste another Post-It note pasted with care and dedication under their keyboard as a service to all those who need to know their password.
The small problem in all of this is that most users don’t know what to do when their password expires. Even worse, rich clients like Outlook 2010, Outlook 2011, and ActiveSync mobile devices stop authenticating correctly and might not provide their users with sufficient information for them to realize that the root of their problem is an expired password. By comparison, Outlook Web App users will understand exactly what’s happened and be able to take immediate action. I think this points to a slight problem in that clients that connect indirectly were all designed to authenticate in an environment where Active Directory reigns supreme. It’s not quite as simple as that inside Office 365 where the authentication chain also involves a Microsoft Online identification.
Office 365 was released on June 28, 2011 and since that time many small businesses have migrated to the new cloud platform. And sod’s 14th law of computing states that unexpected problems are always around the next IT bend, and the time now elapsed since the move to Office 365 began means that many users are now in imminent danger of experiencing the unique joy of being detached from Office 365 without understanding quite why. Cue a flood of support calls to the local IT administrator, who often knows just a little more about Office 365 than a normal user, meaning that the calls are passed to Microsoft.
Assuming that they realize the root of the problem, administrators can reset user passwords (for details, see this web page). The alternative is to take some form of proactive action. Changing the password policy would be best, but there’s a dearth of advice as how to manipulate the password policy for an Office 365 domain. So you’re left with the prospect of doing what happens with Plan P, which is to allow everyone’s password to never expire.
Updating everyone’s password expiration is a simple matter if you are familiar with PowerShell. Essentially, the steps are:
- Log onto a computer (Windows 7 or Windows 2008 R2) that has Version 3.5.1 of the .NET Framework, the latest version of the Microsoft Online Services Sign-In Assistant, and the Microsoft Online Services Module for PowerShell installed.
- Open the Microsoft Online Services Module for PowerShell and run the Connect-MsOlService command to connect to Office 365. It’s also possible to fire up a regular PowerShell session and import the MSOnline module so that you have access to the commands that you need to manipulate Office 365 accounts.
- If you want to update just one user, run the command Set-MsOlUser –UserPrincipalName UserID –PasswordNeverExpires $True
- If you want to change the password expiration for everyone, run Get-MsOlUser to return the complete set of user objects and pipe them to Set-MsOlUser
- Get-MsOlUser | Set-MsOlUser –PasswordNeverExpires $True
BPOS includes a cmdlet called Set-MSOnlineUserPasswordNeverExpire to do the same job. I haven't seen this in Office 365 yet, but maybe I have been looking in the wrong place! In passing, I note that moving users from BPOS to Office 365 might require a review of account settings such as password expiration to ensure that users have the same experience in both environments.
Clearly this isn’t the kind of smooth operational environment that you’d prefer to have within Office 365. I'm pretty sure that Microsoft is aware of the issue and is working on the problem so that domain administrators will have better control over password policy in the future than exists today. At least, I sure hope so!
December 12 update: Something changed in Office 365 land. At least, that's what I concluded when I discovered that I was being forced to change my password for my Plan P subscription. I was in France over the weekend and had used Outlook quite happily to connect to my mailbox. All went well until I landed in Dublin and switched on my iPhone to connect. The iPhone refused to connect and politely told me that it was unable to connect to the server. I blamed transient network conditions, my phone provider, or the time of the year but never twigged that it might have been a password failure and of course, iPhone (running IOS 5.0) didn't let me into the mystery.
I arrived home and plugged in Outlook and the problem became very clear. A couple of moments later I was back online with a new password. It only took me a few more minutes to follow my own advice given above to log onto Office 365 with PowerShell and run the Set-MsOlUser cmdlet to set my account so that its password would never expire. So my problem is fixed - I wonder how many other Plan P users will run into the same issue?
All of this came about due to some changes made by Microsoft to improve the capabilities of Plan P and make it more attractive for professionals and small companies. For more information, see my comparison between Office 365 Plan P and Plan E.
Follow Tony's ramblings on Twitter!