Windows 2003 multiple password expiration policy - how ?

[Alan]

We are using a Windows 2003 AD at work and have a default domain policy which expires passwords after 60 days.

Things were good - until the auditors came

We now need to have our administration/it-staff passwords expire every 30 days, but for all other users to remain on 60 (all hell would break loose if we imposed 30 days on the users too)

Apparently Windows 2003 AD can support having two different password expiration policies but im damned if i can figure out how to do it.

Any ideas out there ?

 

[Insane]

as far as I remember (this is working off a W2k AD structure)

you create an organisational unit called something useful like "IT Department" or "Admin Staff" or other twoddle, name it something useful that you can recognise straight away and is associated with it, hell you could even use the word "30day expire" if you want

You then need to go into Group Policy editor and attach a new policy to this OU for the password settings you want to use, im not up to scratch with 2k3 but use Group Policy Management to do it all.

if your password settings are all in the default domain policy it might be useful to strip it out of it, and create two seperate "folders" for the users. then create seperate policies for each folder with the different password settings for each user, it will inherit the default domain policy and then apply the new settings with it.

 

[Alan]

Im familiar with GPO's and the settings - but can you really have two with password expiration settings in them ?

We can set a policy to apply to the top OU for 60 days, then a second policy to apply to a OU further down the chain with 30 days (to contain our admins) but i was always under the impression this would be ignored.

Time for some testing tomorrow me thinks.

 

[TdC]

depends how you design your tree. I seem to recall our admin container being outside the main user tree?

 

[Alan]

Im just going to have to set a stupidly short time like 2 days on our Admin OU and try it out i guess.

 

[Athan]

Ugh, this just enforces my dim view of auditors. It's been demonstrated time and again that if you make people change passwords regularly they'll either just use things like password01, password02, etc in sequence, or if you have checks that disallow that, they, wait for it, you know it's coming. write the password down on a post-it stuck to their monitor.

It's so much better to enforce complex passwords, with good advice like "Think of a 10+ word phrase, then take the initial letter of each word for your password", and then LET people keep the same password indefinitely. Sure, also run a 'crack' against the hashes to catch any that end up being crap anyway, and get those changed, but no need to force everyone to have to think of a new password every X days, remember it, and not write it down.

*sigh*,

-Ath, with the same root password on his machines for YEARS now, and confident it's not a problem (never logged in using it in plaintext over the network )

 

[Alan]

After spending most of today with microsoft.com and google - this to me is impossible.

For a policy to affect domain password settings it must be linked to the domain itself, if you link a password policy to an OU it will only affect local accounts on computers added to that OU.

 

[Athan]

You're sure about that ?

http://www.microsoft.com/technet/pr...ctory/activedirectory/stepbystep/strngpw.mspx

walks you through setting up a new GPO with a password policy, and:

http://www.microsoft.com/technet/pr...ectory/activedirectory/stepbystep/gpfeat.mspx

seems to make it clear that you can link separate GPOs to separate security groups:

A GPO can be used to filter objects based on security group membership, which allows administrators to manage computers and users in either a centralized or a de-centralized manner. To do this, administrators can use filtering based on security groups to define the scope of Group Policy management, so that Group Policy can be applied centrally at the domain level. Or, it can be applied in a decentralized manner at the OU level and can then be filtered again by security groups

Given:

The default order of precedence follows the hierarchical nature of Active Directory: sites are first, then domains, and then each OU.

I'd assume the way to do what you want is have the longer non-admin expiry policy on the SITE or DOMAIN, and then over-ride it for admins in an OU only they belong to ?

*shrug*. I've never adminned windows at this level (yay!) so maybe I'm reading too much into those pages.

Re-reading what you said... it's surely possible, if tedious ? Is there no easy way to say 'all computers in the domain' for an OU ?

-Ath

 

[Mellow]

I am shocked at some of your replies! lol

Password policies can only be applied at DOMAIN level! Attaching them to an OU really wont do anything at all.

Simply use GPO filtering to have the default one only apply to domain users (click deny apply policy on administrators etc) and then create another GPO at Domain level that has GPO filtering to apply only to the Administrators/IT Staff, etc

 

[Alan]

I am shocked at some of your replies! lol

Password policies can only be applied at DOMAIN level! Attaching them to an OU really wont do anything at all.

Simply use GPO filtering to have the default one only apply to domain users (click deny apply policy on administrators etc) and then create another GPO at Domain level that has GPO filtering to apply only to the Administrators/IT Staff, etc

Me too - I didn't think it was possible so asked here, and people try to give me tutorials on how to make a policy - Its not that I'm ungrateful... its just... well.... I'm not a student

Incidentally - adding a password policy to an OU sets that as the password policy for any LOCAL accounts on computers contained in that OU

 

[Athan]

Well, I did say I'd never actively adminned Windows at this level .

The most I've done is tweak local policies a little to tighten things up. I use a workgroup for simplicity's sake as my home network is just a linux server (both NFS for the other linux boxes and SMB for the windows ones) so a Domain would be overkill and too much hassle to set up.

Now, as the OP has had problems with it, how about you be a love and give him a step by step guide to achieve it ?

-Ath

 

[Athan]

Me too - I didn't think it was possible so asked here, and people try to give me tutorials on how to make a policy - Its not that I'm ungrateful... its just... well.... I'm not a student

Hey, you're the one that seemed to not be able to manage what others said was possible .

Incidentally - adding a password policy to an OU sets that as the password policy for any LOCAL accounts on computers contained in that OU

Hey, YOU'RE the one that started talking about OUs

. So, got it working now ?

-Ath

 

[Alan]

Nah its the weekend - ill be fucked if im logging on to work Then im offsite for 3 days

I vaguely remember you can restrict GPO's by groups but im sure this was a "who gets this GPO" rather than "who doesnt" so would need to change our groups around so we have a distinct "users" and "admins" rather than relying on domain admins/users. Also im sure the password policy is applied in the computer section of a GP rather than the user section (typical microsoft) so this may not work anyway.

 

[Athan]

That would be why I pointed out the thing about the priority ordering of Site > Domain > OU. So in that case you'd have, the Domain GPO have normal users in, and the Site have Administrator. That way it defaults to the more strict policy, but then non-Administrator users get it over-ridden by the Domain one. Or maybe I got that the wrong way around, but you get the idea.

*shrug*. I'll go back to happily adminning unix boxes .

-Ath