Link to home
Start Free TrialLog in
Avatar of dgreer1201
dgreer1201

asked on

Multiple Password Policies

We are currently in a situation where I think we will need multiple domain password policies.  Let me tell you our situation, and you give me advice.

We have had our normal domain password policy setup for a year or so.  Everything is normal here (password complexity, account lockout, etc.)
However..........we are now adding a barcoding inventory system.  These use Symbol RF scan guns.  These scan guns will be using Terminal Services to remote back into the TS server for the application.  However..........being a handheld, we do not need the normal complexity that our desktop users have.  Being that it has a very small keypad, we need to have a seperate password policy just for the handheld user accounts.
I have created a new OU for the handheld accounts.  But, I know that this OU is still inherting the domain password policy from the Default Domain Policy.  

This is Server 2003.  I'm going in through the Group Policy Management Console to try to block inheritance...........but this isn't working.  Of course, I'm still not overly familiar with the GPMC.  I'm still used to going in to ADUC to edit Group Policy.
Any advice here?
Is it possible to do this?
SOLUTION
Avatar of Darius Ghassem
Darius Ghassem
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Unfortunately in 2003 and 2000 you can only have one password policy per domain linked at the domain level.  You can right your own filter (not recommended and rarely done) or use third party tools to help    http://www.specopssoft.com/products/specops-password-policy

Microsoft did listen and in 2008 and later fine grained passwords were introduced which will let you have different policies for groups and/or users.

Thanks

Mike
You need to upgrade to Windows Server 2008 functional level to support Fine Grained Password Policies
Avatar of dgreer1201
dgreer1201

ASKER

We do not have any 2008 boxes.
So.............we are pretty much stuck having all of the scan guns to have long passwords as well, correct?
Anything else you can think of?
The only way to do this in a Windows 2003 domain would be to create a separate child domain. This would allow you to have a separate password policy for users created in that child domain.
Nothing else you are stuck. Or like hypercat said you can setup a new child domain for them but seems extreme.
ok , you can there is simple solution, make multip OU on your domain , put the user in its own OU , by using group policy management , create group policy for each OU it will be applied on every user.
Just out of curiousity...........
Not sure if this will work or not..........but it's a thought.
What if I (temporarily) disable the Default Domain Policy password complexity and password length..........then go ahead and prestage all of the handheld scan gun accounts with a simple password (setting password to never expire).  Then log into each of the guns to make sure the password is working.
Then...........go back and enable the Default Domain Policy password complexity and password length.
Would that work?
yes but what is benifit of doing such that everytime? why you don't create policy for each OU? its best
OU can't have it's own policy.
jordannet,

Yes, please read above.  They have all confirmed that you cannot have multiple password policies on a Win 2003 domain
am sorry i missed that you are talking 2003 , i thought its 2008
That actually worked very well.
I went into the Default Domain password policy, and temporarily disabled password length and complexity.  I then proceeded to setup a new scan gun user account with a very simple password, and set it to not expire.  Then, I logged into the new account and everything worked perfectly.
After I was sure the new account was working with the new simple password, I then went back into the Default Domain password policy, and re-enabled the password length and complexity.
This seems to be working well so far.
ASKER CERTIFIED SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
i still doubt there is a solution
Hypercat,
Yes...........that is exactly what I am doing.  I only need to setup about 6 or 7 of these scan guns initially...........and then they will (hopefully) never have to be touched again (at least in regards to a domain account).  And yes........that was the very first thing I did after setting up the scan guns accounts...........was to re-enable the complexity requirements for the domain.

Jordannet,
Yes.........you are correct.  According to everyone else's comments and the research I have been doing, there is not a solution to this problem.
However...........this is just a workaround for the issue.
and am insist that there is a solution this challenge , nothing can not be solved in the world ..!!! just wait me am doing something
You didn't have to go that far:

Setting up a user account with "PASSWORD NEVER EXPIRES" overrides the domain password policy.

With that said, I should warn you:
I would STILL have a complex password for these users. Dictionary attacks and typically used passwords could be used to INFECT an entire domain (depending upon the user's credentials). Viruses are now using the Remote Procedure Call (RPC) service to run infected scripts using guessed admin passwords to all computers within the domain. An example of this type of virus is the Conficker/Downadup virus or variants. Remember to use Least User Privileges, AND strong passwords to help secure your domain.
Does the application need to access data outside of the terminal server?
If not you could use local user accounts on the terminal server.
You can apply OU level password policies to machines which then effects local accounts.
It is only for domain accounts that you can only have one policy.
I just ran the following experiment:
Created a policy in the default group policy to allow for 0 length passwords
Created an OU and moved a domain member computer to it
Created a policy bound against the OU requiring 5 character passwords, checked block inheritance
Ran gpupdate /force on DC and member server
Ran gpresult on member server - it showed domain policy was filtered out and that the 5 character password policy was applied
Tried changing password from p to q - it worked

Logged out of domain and logged on local machine
Tried changing local password from p to q - it didn't work and told me I needed a 5 character password

I'll work on this some more, but those were my initial results...

Next round of experiments.
Ran DCGPOFIX to reset default domain policy - 7 characters

Created two policies: 6char (bound against domain) and 5char (bound against OU)
Blocked inheritance on the 5char; ensured no override was not checked on the 5char
6char policy moved higher in priority against domain

Ran GPUPDATE /force on DC and member server
Ran GPRESULT on DC and verified 6char policy was applied
Ran GPRESULT on member server and verified 5char was applied
Ran RSOP.MSC on member server and verified 5char was the Source GPO

Hit control-alt-delete and c for change password.
Tried to enter a password of 12345
Received message indicated my password needed to be 6 characters long

Moved the 6char policy to a lower priority than the default domain policy and repeated steps above.
Received message indicating it need to be 7 characters long, didn't meet complexity, etc

Just for grins, I removed all password policy requirements except character and complexity in the default domain policy and set them to 7 and enabled respectively.  I moved 6char up in priority (all of the rest of the settings were not defined).

I tried to change the password and the effective settings were 6 characters and complex password required - meaning that normal group policy inheritance rules applied at the domain level but were ignored at the OU level.
Temporarily disabling the domain password requirements, and then prestaging the handhelds and then re-enabling the password requirements seemed to be the best route to go in the situation.
Not the perfect solution.........but it worked when we were in a tight.