Link to home
Create AccountLog in
Avatar of sheila54603
sheila54603Flag for United States of America

asked on

Delegation in W2K3 AD not working as expected

In W2K3 ADUC, I ran the delegation wizard to give a new employee all rights to the Users OU. Double checking the security tab shows this user has full control of this OU; however, when they launch ADUC tools from their desktop, and goto the Account Tab of a locked out user in that OU, everything is greyed out and they cannot unlock that user.
Avatar of Paka
Paka

When you open the user object that is locked out, does it show the proper permissions?  A better way to do this would be to create a security group and delegate rights to the group, then add and remove membership to the group.
http://support.microsoft.com/kb/294952

Even though this is for win2k it still works for 2k3
Is the user being unlocked a member of any administrative groups?

Right click the OU. Delegate Control. Add the users. Create custom task to delegate. Check Only the foillowing objectgs in the folder and select User Objects. Hit next. Check Property specific and check the following permissions:

Change Password
Reset Password
Read pwdLastSet
Write pwdLastSet
read lockOutTime
write lockOutTime

This should give the ability to reset passwords and unlock acccounts.
Avatar of sheila54603

ASKER

Paka,
Under the user we were testing with, I do not see the proper permissions. There are also a few others I do not see the proper permissions but I do see the proper permissions for most of rest. Any idea what could be blocking these permissions for some users? All are in the same OU.

CptnTrips-
The "problem users" are not part of any admin groups but are members of groups the person I'm attempting to delegate this role to are not.
Sheila,
When you say some are problem users, do you mean some of the people you delegate to can not change anyone or there are people that the delegates can not reset?
There are people in the OU that the delegate cannot reset.
ASKER CERTIFIED SOLUTION
Avatar of CptnTrips
CptnTrips

Link to home
membership
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
Also, just the fact that those people are in the same OU will not mean the delegate can make changes. It depends more on what group memberships the delegate and the problem users are members of. If I am a domain admin or some other admin group member or "protected" group member and you, the delegate are not, the fact that we are in the same OU will not mean that you can reset my account. You will not be able to to reset my account.
I ran the AdminCount=1 query and the results show about 15 users that should not have any kind of admin rights (never had either).
Now that I have this info, can you guide me to how I remove this attribute?...they are not members of any admin groups
Points increased to 500 due to complexity of issue
This attribute comes from either being in a "protected group" now or having been in one at one time. The admin count not resetting to 0 once they are not in a protected group was a bug with Windows 2000 server that was fixed by SP3. So they are either in a protected group now or they were in one a very long time ago. Can you pick one user and list their group memberships? Let's make sure that they are not in a protected group. You may be surprised at what groups are. I have read some posts on this before that even indicated distribution groups have caused the problem.
Here is the Microsoft solution to this. The problem with this script is that it runs against everyone in your domain. Theorectically, anyone in a protected group should change back within an hour but I didn't like the idea of running against EVERYONE. If you would like to just run it against one person to test or would like to be able to run it only against the individuals you're having problems with, you will need to modify it. Or let me know and I will post the modified version we used.

http://support.microsoft.com/kb/817433/en-us
These are the groups that are protected. If a user is a member of these groups, the adminCount will still set back to 1 unless you turn inheritance off.

" Enterprise Admins
" Schema Admins
" Domain Admins
" Administrators
" Account Operators
" Server Operators
" Print Operators
" Backup Operators  
" Cert Publishers
I picked one of the users and checked their groups...no protected groups there. The AdminCount=1 query also returned a few groups, two of which should not be protected: Customer Service & Accounting.
All the problem user accounts are a member of OR were a member of one of those groups.
Is there a way to remove the attribute from these 2 groups & each user?...or should I simply manually add the delegate to the security of each user and be done with it....problem being then if anyone would copy one of those users, that bogus attribute will follow.
I'll take a look at the script.....looks like we were posting at the same time
SOLUTION
Link to home
membership
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
SOLUTION
Link to home
membership
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
I'm not sure about the groups returning adminCount attributes. I wouldn't mess with those just yet and I wouldn't start adding anything to individual users' security. Try the scripts first. If you still have problems after running against individuals that are members of these two groups, I would just run the one from Microsoft that runs against it all. This way you hit everyone and those that should be at 1 will change back to 1 within an hour or so.
I'm getting the following error when attempting to run the 2nd script:
Line: 9
char: 5
error: There is no such object on the server.
code: 80072030
Source: (null)

got script2 to work...I'll let you know more in a bit
Ran script2 on a few users and the delegate still could not make changes to their accounts. I dug into the security settings deeper and found "Allow Inheritable Permissions from parent...." was unchecked for these problem users and the 2 mentioned groups...no idea why. I've checked the box for all those regular users and went ahead and ran script2 on each of them as well. Delegate is now able to modify their accounts.

Thanks Cptn!


Thanks for all your help I truly appreciate it as it was a time sensitive matter. I look forward to working with you in the future.