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

From: Marsha (Marsha_at_discussions.microsoft.com)
Date: 01/10/05 

Date: Mon, 10 Jan 2005 13:23:03 -0800

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.

"Phillip Renouf" wrote:

> 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
>
> "Marsha" wrote:
>
> > 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.
> >
> >
> > "Phillip Renouf" wrote:
> >
> > > 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
> > >
> > > "Marsha" wrote:
> > >
> > > > 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.
> > > >
> > > >
> > > > "Phillip Renouf" wrote:
> > > >
> > > > > 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
> > > > >
> > > > > "Mental Floss" wrote:
> > > > >
> > > > > > 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
> > > > > >
> > > > > >
> > > > > > "Marsha" wrote:
> > > > > >
> > > > > > > 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.
> > > > > > >
> > > > > > >
> > > > > > > "Joe Richards [MVP]" wrote:
> > > > > > >
> > > > > > > > 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 Microsoft MVP Windows Server Directory Services
> > > > > > > > www.joeware.net
> > > > > > > >
> > > > > > > >
> > > > > > > > Marsha wrote:
> > > > > > > > > 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!
> > > > > > > >

Relevant Pages

  • Re: Expiration dates without AD
    ... Password never expires is not related to account expiration. ... I need to run a script to enumerate objuser on expiration dates, ...
    (microsoft.public.windows.server.scripting)
  • Re: scripted logon
    ... Why can't you launch all the scripts from a Group Policy based Logon script. ... Here's the policy settings (I sure hope word wrap doesn't mess it up too ... Windows Components/Windows Installer ...
    (microsoft.public.windows.terminal_services)
  • Re: Group Policy Timeout on one server in an OU.
    ... inheritance of that login script and placed myself in the OU. ... On Error GoTo 0 ... Group Policy Information Hub: ... Group Policy Management solutions athttp://www.sdmsoftware.com ...
    (microsoft.public.windows.group_policy)
  • Re: Password Policy
    ... You minimum password age is badly high. ... Steve Riley wrote an excellent article on why password complexity is not so ... allowed to change their password before it expires. ... You can circumvant a bit the password policy by having 'password never ...
    (microsoft.public.windows.group_policy)
  • Re: Startup Bat File
    ... Link the policy at/above where their accounts reside in the AD tree. ... So it looks like it needs to be moved to the logon script within the ... registry settings and such for mapping drives, ... Domain Admins - Read, Write, Create All Child Objects, Delete All ...
    (microsoft.public.windows.group_policy)