Passwords: 24 hour restriction can cause COMPLETE account lock-out - what purpose does this serve?

    General discussion

  • OK, so our office has already been paying for MS Online services for SharePoint and Exchange for some months now, but we've had unbelievable amounts of difficulty in working with MS Online's absolutely ludicrous password restrictions.

    Boiling it all down and trimming away the unimportant "fat", the SINGLE MOST CRITICAL issue we've had is the "password can only be changed once per 24 hours" restriction. What the heck purpose does this serve? Security experts I've discussed this with listened on in disbelief at such a pointless and self-destructive restriction. It seems like someone just went through the password restrictions panel and "set the settings" despite the fact that some of these restrictions serve no useful purpose and should be left disabled.

    We do wish to have this single policy disabled for our users in the highest priority, however I also want the "powers that be" with MS Online to re-evaluate their product-wide decision to use this absurd policy by default! If anyone can give me a single real-world example of how this "one password change every 24 hours" policy could provide some non-redundant protection in the REAL world, I could understand using it. However, as it seems now, it's just a setting left behind by some childish and short-sighted initial setup of the MS Online policies that was never second-guessed by anyone along the way.

    If a user is forced to change their password (every 60 days as another ridiculous policy dictates)... and that user forgets their new password that same day... and the administrator didn't know the user just changed their password... the administrator sends a "password reset"... the password CANNOT BE RESET because the user already changed their password once that day. So the user is COMPLETELY LOCKED OUT. Administrator can't do anything to re-instate the account, and since the user doesn't remember (or perhaps mis-typed, with hands in the wrong position or something) their new password, the user is completely... locked... out. With no options for the administrator.

    Additionally, the error message in the MS Online Sign-In Assistant for encountering one of these errors is unusably vague: something to the effect of (from memory): "Password does not meet complexity requirements. Passwords can only be changed once every 24 hours. You cannot re-use one of your past 24 passwords". This is probably a pretty obvious question, but: WHICH ONE of those error conditions actually existed for the user trying to set their password? Was it 24 hours? Was it repeating one of their past 24 passwords? Or was it password length? I can't tell, the user can't tell, and we can't fix the error condition without knowing! For example, I often get that error when the user is setting their INITIAL password (changing it from the default random password sent in the confirmation email). So we enter the old password, and come up with a new password that meets all the requirements. THAT'S when I most frequently receive that message. The "strength" meter is all green, the passwords match, and yet we still receive that error. Why? Is it 24 hours? Is it remembering the failed (not "secure enough") passwords previously attempted? Is it still not "secure enough" itself?

    Hopefully this message isn't dismissed as some guy asking a question about how to make the current settings work. It's not about that, although we do need to get these issues resolved, otherwise we're finding a new host. I'm intending this to help Microsoft Online understand these real-world issues with the software, and in order for that to happen, this thread needs to be forwarded to a person responsible for setting these policies for the MS Online products, and the development team responsible for the MS Online Sign-In Assistant software. Answering this post with just a simple response of how to (or that it's not possible to) set the password policies would probably just result in us shopping for another host. Marking that response as the "answer" will pretty much guarantee it (I HATE when MS reps mark their own answer). ;)

    Well, that said, what can MS do to fix this password policy lockout situation?

    Wednesday, July 06, 2011 8:44 PM

All replies

  • Greetings Falcon4!

    I'm not sure how you'd like me to answer your question so I will change it to a discussion and not mark my answer as the correct one even though it will be. 

    The password policy is outlined here and have been there for as long as the product has been available.  I really don't know the reasoning behind the particular restrictions and I am certain that we couldn't go back and query the program team and developers as to why they chose this policy as it was most likely written 4 years ago. 

    The reason for the Lockout is described here:


    Lockout Policy

    Microsoft Online Services uses an account lockout policy to help protect the accounts of service administrators and end users. The user can try to sign in to the Administration Center or the Sign In application five times. After five failed attempts with an invalid user name or an incorrect password, users are locked out for 15 minutes. This condition cannot be manually reset.

    The lockout policy helps guard against malicious attacks by unauthorized users. After 15 minutes, the user can try to sign in again with the correct user name and password. If the user cannot remember the password, a service administrator can reset the user's password in the Administration Center. For more information, see Reset a User's Password.


    To that point, [a user] "You cannot change your own password more than once in 24 hours."  An administrator may indeed reset a password more than once in a 24 hour period.  At one point an Admin was able to request that users' passwords do not expire.  Due to a limitation within a shared environment, passwords are either "on" or "off" and the "on" is a 90-day expiration.  

    I agree that the Sign In Client could have been written better to help the user determine the actual error in the password.  I didn't find this request in the feature request database.  While I was looking for feature requests, I found several that asked that we only remember the past 3-6 passwords rather than 24 and MANY that requested the password expiration be changed to different lengths of time.  At anytime in the past anyone could have requested a feature change such as these.  It is then up to the program groups and developers to prioritize and then decide which of those changes will be implemented.

    Office 365 is the next version of BPOS.  Any new feature requests will actually be looked at for Office 365 rather than for BPOS.  Office 365 allows for rich co-existence which allows for better control of passwords.  Perhaps this may be an option to you.

    At this point I'll leave the discussion open to your peers.

    Vickie - BPOS Technical Support

    Friday, July 08, 2011 1:03 AM
  • Wow!! Above and beyond the typical call of duty for the norm in these MS support forums. That was very insightful!

    Admittedly I didn't have a clear plan of response when I wrote this thread. I was just tasked with finding a solution to the 24-hour lockout issue that we appeared to be consistently running into when trying to set someone's password for the first time account setup. We actually have a user in the office that's had the MS Online Sign-In application running on every startup, and on every startup it's been asking her to change her initial password! Since it requires the old password, we don't know what it was changed to, and I've been afraid to reset it for fear of triggering another 24-hour debacle, and not knowing if it's the password complexity, password repetition, or password changes, that are causing the error to appear! I don't ask people what password they're entering, of course, so it's hard to tell which rule they may be breaking when there are so many ;) I just see the "Strength" bar is green so I assume complexity is met, and they hadn't yet set a previous password so repetition is out, that only leaves one thing: an unavoidable 24-hour lockout!

    According to your response, that's not the case (Whew!! HUGE load off my mind there). I had gone through a support case with MS Online support previously, when that user's issue first came up. Their response was that there was literally nothing that could be done:

    "This is Ansey Plaisir with Microsoft Online Services Technical Support.

    Referring to your Service Request 110111-000336, it appears that we have identified a possible solution for your issue. 

    Issue Description: password lockout

    Issue Solution: Wait for 24 hours before resetting the password and i will call you tomorrow for update"

    - That was what prompted this whole password-paranoia issue! We stopped rolling out Sharepoint Online at that response, fearing that more users would be locked out if they forget their password and I wouldn't be able to fix it as the admin. If that's not the case (and it's just a bug in the sign-in application causing that error to appear for a new, "strong" password), then we can work around that if we can just know EXACTLY what causes a password to be rejected even if it's "Strong" and being set for the first time...


    Oh, and I'm OK with it being a discussion as well - seems more appropriate anyway. There's no real single question here with a single solution, so it works :)

    • Edited by FalconFour Friday, July 08, 2011 2:08 AM misplaced quote
    Friday, July 08, 2011 2:06 AM
  • OK, I'm again finding yet another lock-out problem with this PAINFULLY short-sighted and self-destructive BPOS password policy: I can't even set up a damn user account!

    Last signed in: never

    Somehow the person that set-up the account forgot the initial password. So we reset it. Now we sign-in with that new temporary password and are prompted to create a new password. OK. We have the user come up with a password that meets all the complexity requirements (it's 9 characters long, starts with a capital letter, ends with a number). The bar indiciates "STRONG" and is green. "Save".

    "Your new password did not meet password requirements. Passwords can be changed only once every 24 hours. You cannot reuse your previous 24 passwords."

    BULL! We're locked out! We can't set a password (I tried various alternatives, all within the complexity requirements, will not accept any of them). We know the password, we don't need to reset it... but we can't get this stupid error message to go away!

    REMOVE THESE COMPLETELY ABSURD PASSWORD POLICIES! I can never recommend Microsoft Online to anyone anymore, because of how absurdly restrictive and utterly pointless these policies are. It's almost worth the extra money to go elsewhere that doesn't have these ridiculous restrictions...

    Friday, August 05, 2011 10:15 PM
  • Hi Falcon - I feel your pain but I'm fairly sure Microsoft will stick to their guns with this one. I can offer you a couple of alternatives if you're interested...

    1) As an admin you could reset a users password using the following Powershell CMDlet (This should reset their password and not force them to have to change it at next logon):

    Set-MSOnlineUserPassword –Identity <user> –Password <password> -ChangePasswordOnNextLogon $false -Credential (Get-Credential) -Verbose

    This ofcource relies on you having the BPOS Powershell extensions installed on your machine.

    2) Use what we use...The MessageOps Password Syncing tool. Spin up a server an install a client on each DC that will sync each users password to the cloud when they change their domain password. This tool will essentially Invoke the above Powershell Command to change the users password with an Admin service account. Check it out here:

    3) Grit your teeth and bear with it until you're moved to Office 365 - Once you're on there you'll be able to deploy ADFS. This means that Microsoft Password Policies are null-and-void as you can create your own. All authentication is done at your end...All Microsoft does is provide the end service.

    Hope this helps...



    Patrick Squire -
    Monday, August 08, 2011 11:31 AM