Unable to unlock peer group members ' accounts

[Jason]

I have 2 global security groups , group A can manage computer accounts and
group B can manage User accounts. But after I put group A as a member of
group B , everything thing works ( ie, group A people can manage computer
and user accounts ) except that they are unable to reset peer group A
members' user acount.
I have tried the MS article to select the read/ write lockout time and
delegate again. Still the same.

Any idea ? Thanks !

Jason

 

[Steven L Umbach]

Were they able to manage the user's accounts before and for the same exact
user? If a user is a member of privileged groups such as administrators,
account operators, server operators, etc a regular user who has been
delegated permissions to manage user accounts for a OU/container can not
manage those user accounts. When you examine the security properties of
users in those privileged groups you will see that the "delegated" group
does not have permissions to the user and that user object is configured to
not inherit security settings from parent in advanced page of security
properties. --- Steve

 

[Jason]

Steven,
Memebers of both groups ( A&B ) are not part of any previledged groups or
build-in groups. ( I have verified this by checking these two groups'
"member-of " tab.).They are able to unlock peer user accounts before the
change.

Jason

 

[Steven L Umbach]

Hmm. The privileged group membership was always what caused this to happen
in my experience. I can't think of a reason why that would happen offhand if
they were not. Instead of group nesting I would try to explicitly delegate
Group A permissions to manage user account to see if that works for you.---
Steve

 

[Roger Abell]

Examining the memberships of those groups will not tell you
whether the accounts that are members in those groups are or
are not members of privileged groups. It will only tell you
whether they are or are not so due to membership in the two
groups you examined.

 

[Steven L Umbach]

Roger makes an excellent point. Examine the "member of" tab of the user for
which the account can not be managed and membership of each privileged
group. That would be a start since it could become more complex depending on
group nesting such as if there were groups that are members of privileged
groups. The dsget and dsquery command line tools can also be used to
enumerate a users membership to all groups, even based on nesting. Those
tools are not available by default in Windows 2000 unless you have a Windows
2003 domain controller or have adminpak for Windows 2003 installed on an XP
Pro domain member. I have also seen where if a user "was" a member of a
priviliged group at one time and then removed from it the inhertitance of
permissions for that user account from the parent is still disabled though
if you enable it you should them be able to managed that account via
user/groups delegated that permission to it. --- Steve

 

[Jason]

Roger , Steven, thanks both of you for your valuable input which do help us in further troubleshoot our Unlock User account issue.

After conducting more than 50 tests and validation ,, we finally found out what exactly is the problem , described below :
First , the MS Article Q294952 is a bit tricky, after going through it a third time ,the fact is that , from the original article :

"Any user or group that has been given permission to read and write the LockoutTime attribute for an OU or other container can unlock user accounts that reside in that container. The user or group that has been given this permission does not have to reside in the container over which they have permission."

1) The hidden implemenation is that you cannot expect the delegated permission will be inherite by the sub-level OU or container beneath it - it has to be delegated to the specific OU and each and every OU where you have users who are also peer group members and who want to be able to Unlock each other's account.
In other words, if you have peer group member users but they reside in different OUs, then make sure you delegate to each Ou respectively with the required delegated group memebership.

2) When it come to delegation ( to Unlock each other's account ) and since we are talking about peer group members, we discover the following scnario:
If :
- user John is member of group A,B,C,D,
- user Mary is member of group A,B,C,D,E,J,K
- user George is member of group A,B,X,Y,
and if you delegate group A,B,C,D the read+write permission to the lockout time attribute in OU "test"
then , User Mary will be able to Unlock John's account , but john will not be able to unlock Mary's. In, addition , neither John or Mary will be able to Unlock George's account or vice versa . The reason is, they only have some common membership in some groups, they are not exactly peer to each other as their " total " membership is not the same in nature as explained in the above example.
Worse case is even delegating all groups A.B,C,D,E,J,K,X,Y the right to R+W the lockout time doesn't necessary guarantee that these three people can unlock eah other 's accounts .
Added to the complication will be if these three users reside in different OUs than it will be a total mess in terms of delegation effort required . And in any day if one of them be added to another group than your effort will be in vain again.

So in the end , we decided to give up this delegation and rather have Domain Admin to Unlock users accounts. Howver, I need to take a further note that, the above case only happens to users/ groups who have already been granted some sort of User account management permission within the AD already ( e.g, create acount, manage acount, manage groups etc.).
They will definitely be able to unlock other users account but not peer's which is the topic of this discussion.

Finally, the previleged group membership, based on our own test case , have no impact as long as the R+W to lockout time has been delegated.

Regards,
Jason

 

[Steven L Umbach]

Hi Jason.

Thanks so much for posting back your results. I find it helpful info to know. If don't know how often you have to unlock accounts, but if you want to move some of that burden from domain admins you might want to consider giving some users a second user account that could be delegated the right to unlock accounts without being in all the different groups that are causing the problem you experience. Then you might end up with just a few users that can not unlock each others accounts. --- Steve


Roger , Steven, thanks both of you for your valuable input which do help us in further troubleshoot our Unlock User account issue.

After conducting more than 50 tests and validation ,, we finally found out what exactly is the problem , described below :
First , the MS Article Q294952 is a bit tricky, after going through it a third time ,the fact is that , from the original article :

"Any user or group that has been given permission to read and write the LockoutTime attribute for an OU or other container can unlock user accounts that reside in that container. The user or group that has been given this permission does not have to reside in the container over which they have permission."

1) The hidden implemenation is that you cannot expect the delegated permission will be inherite by the sub-level OU or container beneath it - it has to be delegated to the specific OU and each and every OU where you have users who are also peer group members and who want to be able to Unlock each other's account.
In other words, if you have peer group member users but they reside in different OUs, then make sure you delegate to each Ou respectively with the required delegated group memebership.

2) When it come to delegation ( to Unlock each other's account ) and since we are talking about peer group members, we discover the following scnario:
If :
- user John is member of group A,B,C,D,
- user Mary is member of group A,B,C,D,E,J,K
- user George is member of group A,B,X,Y,
and if you delegate group A,B,C,D the read+write permission to the lockout time attribute in OU "test"
then , User Mary will be able to Unlock John's account , but john will not be able to unlock Mary's. In, addition , neither John or Mary will be able to Unlock George's account or vice versa . The reason is, they only have some common membership in some groups, they are not exactly peer to each other as their " total " membership is not the same in nature as explained in the above example.
Worse case is even delegating all groups A.B,C,D,E,J,K,X,Y the right to R+W the lockout time doesn't necessary guarantee that these three people can unlock eah other 's accounts .
Added to the complication will be if these three users reside in different OUs than it will be a total mess in terms of delegation effort required . And in any day if one of them be added to another group than your effort will be in vain again.

So in the end , we decided to give up this delegation and rather have Domain Admin to Unlock users accounts. Howver, I need to take a further note that, the above case only happens to users/ groups who have already been granted some sort of User account management permission within the AD already ( e.g, create acount, manage acount, manage groups etc.).
They will definitely be able to unlock other users account but not peer's which is the topic of this discussion.

Finally, the previleged group membership, based on our own test case , have no impact as long as the R+W to lockout time has been delegated.

Regards,
Jason