Fine-Grained password policy

We are a school district and need to have different password policies based on user.  (Staff/Student)

We are using server 2012 and have setup fine-grained password policies.  The policies are applied to either a Staff or Student global security group.  The domain password policy is set to a minimum length of 7 and password must meet complexity requirements.   The Student password is set to minimum length of 4, (first graders have a hard time typing complex passwords).

So far everything is working if a user already existed in AD.  However, when adding new users we receive the message “Password does not meet the password policy requirements”.  

I really don’t want to change my domain password policy to anything less than it already is, however, that is the only option I have been able to come up with.

Is there a way to add a user and not have the system check a password policy?

-Lee
LVL 3
MadisontechAsked:
Who is Participating?
 
Cliff GaliherConnect With a Mentor Commented:
Not if you have a password policy defined in the default domain group policy.
0
 
helpfinderIT ConsultantCommented:
and is newly created user a member of appropriate security group?
0
 
MadisontechAuthor Commented:
Yes they are a member of the student security group.  A FG security policy for the student group is a of minimum length of 4.  But the domain is 7 and complex.  When adding a user it check the domain security policy.   So if I add a user with Hello.123 it meets the domain requirements.  Once the user is added I can change the password to '1234'.   I would like to be able to add the user with '1234' as their password to begin with.
0
Free tool for managing users' photos in Office 365

Easily upload multiple users’ photos to Office 365. Manage them with an intuitive GUI and use handy built-in cropping and resizing options. Link photos with users based on Azure AD attributes. Free tool!

 
Cliff GaliherCommented:
You'd have to have the default policy be unset and nonexistent.
0
 
MadisontechAuthor Commented:
I set the domain default policy to match the student policy.  

See original post:
I really don’t want to change my domain password policy to anything less than it already is, however, that is the only option I have been able to come up with.

I think I am stuck with this for now.
0
 
Cliff GaliherCommented:
I saw your original post. And I did comment on it right away. But since you asked again in follow-up, I figured it was worth reiterating. Sometimes the answer is "you can't do that." You've requested two contradictory things. You want a specific behavior, but you want to keep policies that prevent that behavior. In this case, getting both is "you can't have that."
0
 
McKnifeCommented:
Form a new group "stronpw" instead of using the domain group and untie the strong PSO from the non-student group. So existant users go to the students group (weak policy) or to the strongpw group. When created new, they are not member of any of them yet so you can set whatever pw you like and afterwards add them to a group.
0
 
McKnifeCommented:
May I ask why you could not use my solution?
0
 
MadisontechAuthor Commented:
McKnife,
Existing users were not an issue.  No mater what, the default domain policy is in effect when adding a user because a new user does not belong to anything otherwise.
-Lee
0
 
McKnifeCommented:
Wrong. You would not use the ddp for restrictions but the PSOs.
0
 
MadisontechAuthor Commented:
McKnife,
Read the orgional post:
"I really don’t want to change my domain password policy to anything less than it already is, however, that is the only option I have been able to come up with."

The goal was to keep the DDP in place.  Not reduce it or remove it.  I know how to do it without the Domain Password Policy.
0
 
McKnifeCommented:
You are limiting your possibilities.
PSOs can achieve just the same pw security as the DDP, only better with precise assignment.

Let's say we completely disable all settings of the DDP - what keeps you from using the PSOs to achieve just the same as your DDP did?
0
 
MadisontechAuthor Commented:
We are using PSOs (3 of them). But the issue is we don't want to reduce the safety of the domain policy requirements should a user not be assigned to a PSO.  PSOs only apply to Global Security Groups.  The issue is you have to reduce or kill the DP to add a user.   We were looking for a way so we did not have to do that.
0
 
McKnifeCommented:
I see. Please read http://technet.microsoft.com/en-us/library/cc770394(v=ws.10).aspx

Are there any special considerations?
--------------------------------------------------------------------------------
Fine-grained password policies apply only to user objects (or inetOrgPerson objects if they are used instead of user objects) and global security groups. By default, only members of the Domain Admins group can set fine-grained password policies. However, you can also delegate the ability to set these policies to other users. The domain functional level must be Windows Server 2008.

Fine-grained password policy cannot be applied to an organizational unit (OU) directly. To apply fine-grained password policy to users of an OU, you can use a shadow group.

A shadow group is a global security group that is logically mapped to an OU to enforce a fine-grained password policy. You add users of the OU as members of the newly created shadow group and then apply the fine-grained password policy to this shadow group. You can create additional shadow groups for other OUs as needed. If you move a user from one OU to another, you must update the membership of the corresponding shadow groups.

Are shadow groups an option?
0
 
MadisontechAuthor Commented:
Already read that too.   Like I said.  We have it working.   BUT, the goal was to keep the Domain Password Policy in place.  "The domain password policy is set to a minimum length of 7 and password must meet complexity requirements."   AND use a weak policy for our students.   You can't add a user with a simple password if the DPP is complex and a min of 7.
0
All Courses

From novice to tech pro — start learning today.