Password never expires-can't force user to change password

Discussion in 'Active Directory' started by Marsha, Jan 10, 2005.

  1. Marsha

    Marsha Guest

    I have a user's password set to never expire and Active Directory is telling
    me that because of that, I can't force the user to change their password at
    next logon. I understand the concept, but can someone verify that in fact if
    a password never expires you can't force a password change? Is this how AD
    handles passwords? Must there be a potential expiration date in order to
    force a user to change their password? Thanks for the help!
     
    Marsha, Jan 10, 2005
    #1
    1. Advertisements

  2. Marsha

    Paul Bergson Guest

    Works as you explained.

    Just temp set it to expire and then go back a week later and make it
    non-expiring again.
     
    Paul Bergson, Jan 10, 2005
    #2
    1. Advertisements

  3. Marsha

    Mental Floss Guest

    Hi Marsha:

    When the checkbox to "Password Never Expires" is set, a user can change
    their password from any PC connected to the domain (CTRL+ALT+Delete | Change
    Password). Setting that checkbox means that the current password cannot be
    changed by user. You have to remove the checkbox in Password Never Expires",
    set the "Change Password At Next Logon" and then reset it after the user has
    changed their password.
    Refer to article: http://support.microsoft.com/?kbid=282479

    As an aside, it is not good Security practice to set the option of "Password
    Never Expires" for any user.

    -MentalFloss
     
    Mental Floss, Jan 10, 2005
    #3
  4. The mechanism for forcing a user to change password is a password expiration. It
    actually forces a zero into the pwdLastSet attribute. This forces the system to
    require a new password UNLESS the account is set to never expire.

    There is almost never a good reason to have an account set to never expire and
    tons of good reasons not to do it. You should probably reconsider your stance on
    having that set. It is usually only laziness that causes it to be set in the
    first place.

    joe
     
    Joe Richards [MVP], Jan 10, 2005
    #4
  5. Marsha

    Marsha Guest

    Thanks for the help. Unfortunately, I have to set it to never expire so that
    I can control the implementation of our password policy. Hopefully it won't
    take long to roll it out and the 'password never expires' checkbox will not
    be an issue. I appreciate the feedback!
     
    Marsha, Jan 10, 2005
    #5
  6. Marsha

    Marsha Guest

    Please see my previous post. At this time, I am unaware of any other option
    to control a domain password policy than at the user account level. If
    anyone knows of another way, please let me know. We want to implement it OU
    by OU or user by user is requested. This is the only method I know of at
    this point.
     
    Marsha, Jan 10, 2005
    #6
  7. Marsha

    Mental Floss Guest

    Hi Marsha,

    Your post confuses me a little. You can set any subset of your password
    policy in the GPO for the domain or per OU (Computer Configuration/Windows
    Settings/Security Settings/Account policies/Password Policy) and enforce it
    to your users. If you are in the process of implementing this policy,
    leverage your GPO's for most effective distribution of your policies.
    Unless I am missing something in your post!

    -MentalFloss
     
    Mental Floss, Jan 10, 2005
    #7
  8. I'm a little confused by all this too, but you can not set password policy at
    an OU by OU level. The password policy is domain wide.

    What part of the password policy are you trying to set differently for each
    OU? Why are different OUs requiring different password policies?

    Phil
     
    Phillip Renouf, Jan 10, 2005
    #8
  9. Marsha

    Marsha Guest

    Sorry for all the confusion. Here's the overview of what I have been asked
    to do. We want to implement a domain wide password policy. However, we want
    to implement it one department at a time. For example, we're staring with
    our dept as a pilot department. Once we're sure everything is ready, then
    we'll do another, etc. The objective is to stagger expiration dates and not
    overtax our staff with help desk calls all on the same day. If we turned it
    on for everyone on a single day, it could be unmanageable. Also, management
    wants to test the behavior of the policy before sending it live. This could
    take an additional month or so after they feel comfortable. If there is a
    way to do this without setting the password never expires checkbox, please
    let me know!! OU password policies do not overwrite a domain wide policy
    according to my understanding and posts I've read here. Thanks.
     
    Marsha, Jan 10, 2005
    #9
  10. You are correct, you can not set password policy at an OU level.

    My recommendation is that testing should be done in a test environment where
    you can display how the policy will work and can test various aspects of the
    policy as it effects your environment. You can use that testing to show
    management how the policy that you have developed will behave. Once you get
    their buyin you can go forward with the policy in production.

    As for not wanting everyone to change their password at once when the policy
    is enforced that shouldn't be a major issue. When you set the complexity and
    length requirements etc. it will not force users to change their passwords
    right away. They will expire based on your password expiry policy so a good
    way to stagger the users is to take groups of users and set their password to
    expire on different days, that way you don't overload your DCs and it spreads
    the password changes out over a longer time frame. If your password expiry is
    something like 90 days then you have a good amount of time to spread the
    password changes out across.

    Joe, you have anymore input?

    Phil
     
    Phillip Renouf, Jan 10, 2005
    #10
  11. Marsha

    Marsha Guest

    Thanks for the input. I have tested it thoroughly in a test environment, but
    they want to see it live with our department. And as for staggering on an
    individual basis, how would you do that? Doesn't the password expiration
    date depend on either when the policy is applied or when the person last
    changed their password? In my situation, we're starting with a clean slate.
    There is no policy in place right now. I want to make sure that password
    expiration dates are staggered by department. You stated that the way to do
    that is to set the expiration differently for OU's or users beyond the domain
    policy. How can I override the domain policies expiration timeperiod on an
    individual basis? If i implement a domain policy today that says passwords
    will expire in 90 days and I want to stagger that for each OU, where do I set
    that? I guess that's been my dilemma all along. That's why checking the
    password never expires box allows me to control it. If you can give me
    specifics on how to implement this better, please do. i've run out of other
    options. Thanks.
     
    Marsha, Jan 10, 2005
    #11
  12. You don't set a policy on an OU to change the 90 day password policy setting.
    What you do is use a script to change the password expiry date for a number
    of users. Basically what you are doing is setting the time that AD will tell
    them their password has expired. This has nothing to do with the 90 day
    password policy other than the fact that instead of thinking that UserA has
    90 days until their password expires, after you run the script UserA's
    password now has 7 days until it expires.

    For some reason I think I am doing a very bad job of explaining this.

    Another option is to use a tool like dsmod to set a number of users to force
    them to change their password at next logon. A little easier than trying to
    find a script to expire users passwords. Basically you would just pick a
    number of users and set them to change their password at next logon. Do
    different groups each week and you have staggered your password changes.
    Whether you want to do random groups of users, or whether you want to do it
    by department is up to you. Both options have their pros and cons, but either
    will be the same result: staggered password changes.

    Phil
     
    Phillip Renouf, Jan 10, 2005
    #12
  13. Marsha

    Marsha Guest

    Thanks a lot for the input. Do you think they way I'm doing it is incorrect
    then? Shouldn't it give the same result? Or not? I absolutely like your
    ideas, I'm just not a very good script writer and am not very confident. I
    know I can find numerous examples on the net. I guess I'm just not sure what
    the best route would be. I will take a look to see if I can find scripts
    that do what you say.
     
    Marsha, Jan 10, 2005
    #13
  14. Ok this has been a confusing chain but I think I got it.

    1. Password policy on the domain for domain users is all or nothing. You set the
    policy for everyone or no one. You can override expiration or requiring a
    password at all but that is about it. Doing either is generally a bad security move.

    2. You want to implement a new password expiration policy. Assuming you can do
    it all in less than 90 days here is the method I would recommend

    Expire your departments manually. I wrote a tool a long time ago that can help
    with this. It is located on www.joeware.net and is called expire and it takes a
    text list of domain\userid to expire. I used it in a Fortune 5 company and was
    expiring thousands of passwords a day with it and it worked great. The script
    can be configured to not to expire passwords if they are in the list but have
    already changed their password in the last x days.

    At the end of the expiration of all users, kick in the new password expiration
    policy.

    joe
     
    Joe Richards [MVP], Jan 11, 2005
    #14
  15. Marsha

    Marsha Guest

    Thank you! I will try it. I'm sorry this was so confusing, but you have it
    right. I appreciate everyone's help on this. Its been a pain for me.
     
    Marsha, Jan 11, 2005
    #15
  16. I figured you might be able to explain that a little better than I did :)

    Phil
     
    Phillip Renouf, Jan 11, 2005
    #16
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.