Group Polcy Applied But Doesn't Work?

G

Guldan

Member
Joined
Apr 19, 2011
Messages
6
Location
Vancouver, BC
Hey Guys,

I'm a sysadmin currently using default GPOs on the root domain, I created a GPO specifically for password complexity and such then applied it to a new OU I made, dumped the user/computer in there and sure enough its applied via gpresult and rsop.msc.. I see it in secpol.msc

So why can I change my password to 1234?? lol. Minimum is 8 characters and complex

What would cause this?

I just noticed my XP machine shows it's applied (although not working as mentioned) but my win7 machine filters it out.. I have no WMI filter on it

Thanks
 
Guldan said:
Hey Guys,

I'm a sysadmin currently using default GPOs on the root domain, I created a GPO specifically for password complexity and such then applied it to a new OU I made, dumped the user/computer in there and sure enough its applied via gpresult and rsop.msc.. I see it in secpol.msc

So why can I change my password to 1234?? lol. Minimum is 8 characters and complex

What would cause this?

I just noticed my XP machine shows it's applied (although not working as mentioned) but my win7 machine filters it out.. I have no WMI filter on it

Thanks
Click to expand...


Hi,

What does "win7 machine filters it out" mean?

Check that the new policy is the "primary" in that OU, pay attention to LINKED GPO.

Let me know.
 
ICTCity said:
Hi,

What does "win7 machine filters it out" mean?

Check that the new policy is the "primary" in that OU, pay attention to LINKED GPO.

Let me know.
Click to expand...

Filters it out as in looks at it then ignores it. I think I figured it out.. Using Server 2003 functional level domain it only allows one password policy per domain, this is a second one on a different OU so it's just ignoring it
 
Guldan said:
Filters it out as in looks at it then ignores it. I think I figured it out.. Using Server 2003 functional level domain it only allows one password policy per domain, this is a second one on a different OU so it's just ignoring it
Click to expand...

I think you're right.

Please confirm.
 
ICTCity said:
I think you're right.

Please confirm.
Click to expand...

Sorry been busy heh, we unchecked all password settings in the default domain policy and dragged the new seperate password policy to the root domain. It worked, I know because people are pissed right off that they have to use complex passwords.

It seems to be filtering in slowly, some people (including myself) haven't had to change yet.
 
Guldan said:
Sorry been busy heh, we unchecked all password settings in the default domain policy and dragged the new seperate password policy to the root domain. It worked, I know because people are pissed right off that they have to use complex passwords.

It seems to be filtering in slowly, some people (including myself) haven't had to change yet.
Click to expand...

So, as said, you have to put this rule on the PRIMARY policy.

Regarding the delay, it could be a EXPIRE problem. I had the same "issue", because I set up a policy to change users's password every 90 days, but not every person had to change it at the same day. I think it depends on when the users has been created. Also check the "password never expires".
 
ICTCity said:
So, as said, you have to put this rule on the PRIMARY policy.

Regarding the delay, it could be a EXPIRE problem. I had the same "issue", because I set up a policy to change users's password every 90 days, but not every person had to change it at the same day. I think it depends on when the users has been created. Also check the "password never expires".
Click to expand...

Yes I figured, as time elapses more are required to change, its working itself out.
 
Back
Top