Re: Unable to unlock peer group members ' accounts
From: Jason (jasons_at_hotmail.com)
Date: 02/09/05
- Next message: Shannon Jacobs: "Re: How to fix broken security in Windows 2000?"
- Previous message: Ryan Hanisco: "Re: SID Filtering and trust"
- In reply to: Steven L Umbach: "Re: Unable to unlock peer group members ' accounts"
- Next in thread: Steven L Umbach: "Re: Unable to unlock peer group members ' accounts"
- Reply: Steven L Umbach: "Re: Unable to unlock peer group members ' accounts"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Tue, 8 Feb 2005 22:22:03 -0500
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" <n9rou@nospam-comcast.net> wrote in message news:Omu6ALVDFHA.2876@TK2MSFTNGP12.phx.gbl...
> 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
>
>
> "Roger Abell" <mvpNOSpam@asu.edu> wrote in message
> news:uRKBwBODFHA.520@TK2MSFTNGP09.phx.gbl...
>> 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.
>>
>> --
>> Roger Abell
>> Microsoft MVP (Windows Security)
>> MCSE (W2k3,W2k,Nt4) MCDBA
>> "Jason" <jasons@hotmail.com> wrote in message
>> news:eZsVuxrCFHA.3376@TK2MSFTNGP12.phx.gbl...
>>> 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" <n9rou@nospam-comcast.net> wrote in message
>>> news:%23xe0SGoCFHA.3936@TK2MSFTNGP09.phx.gbl...
>>> > 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" <jasons@hotmail.com> wrote in message
>>> > news:O6wVz2mCFHA.3732@TK2MSFTNGP14.phx.gbl...
>>> >>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
>>> >>
>>> >>
>>> >
>>> >
>>>
>>>
>>
>>
>
>
- Next message: Shannon Jacobs: "Re: How to fix broken security in Windows 2000?"
- Previous message: Ryan Hanisco: "Re: SID Filtering and trust"
- In reply to: Steven L Umbach: "Re: Unable to unlock peer group members ' accounts"
- Next in thread: Steven L Umbach: "Re: Unable to unlock peer group members ' accounts"
- Reply: Steven L Umbach: "Re: Unable to unlock peer group members ' accounts"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|