Re: Password never expires-can't force user to change password
From: Phillip Renouf (PhillipRenouf_at_discussions.microsoft.com)
Date: 01/11/05
- Next message: Paul Liderman: "Cannot Add user proxy object"
- Previous message: Al Mulnick: "Re: Active Directory Connector and exchange 5.5 question?"
- In reply to: Joe Richards [MVP]: "Re: Password never expires-can't force user to change password"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 11 Jan 2005 08:07:02 -0800
I figured you might be able to explain that a little better than I did :)
Phil
"Joe Richards [MVP]" wrote:
> 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 Microsoft MVP Windows Server Directory Services
> www.joeware.net
>
>
> Marsha wrote:
> > 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!
> >>>>>>>>>
>
- Next message: Paul Liderman: "Cannot Add user proxy object"
- Previous message: Al Mulnick: "Re: Active Directory Connector and exchange 5.5 question?"
- In reply to: Joe Richards [MVP]: "Re: Password never expires-can't force user to change password"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
