| Author | Messages | |
DavidCliffe
Posts:10
 | | 11/15/2005 9:00 AM |
| Jorge --> "The group membership of a
protected group is the criteria the process looks at, not the attribute value of
1. The admincount attribute is just an administrative measure for the process
that says "been here", nothing else."
This implies that if you later go
back and remove a user from any protected groups, you can then
go set his ACL back to what you want, and not have to worry about the
admincount attribute still having a value of 1, right? Only reason I ask
is because I could have sworn I've seen recommendations on this list to set that
attribute back to 0 after removing all protected group memberships, so just
double checking. Maybe there were other factors involved in those previous
recommendations which I didn't read close enough!
Also, interesting approach to
the original poster's question. Thanks!
-DaveC
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Almeida Pinto,
Jorge deSent: Tuesday, November 15, 2005 3:22 PMTo:
ActiveDir@xxxxxxxxxxxxxxxxxxSubject: RE: [ActiveDir] Protecting
objects not covered by AdminSDHolder
That sounds logical. However the
adminsdholder process only looks at users and groups that are defined in
AD as protected objects. As mentioned in MS-KBQ817433 - "Delegated permissions
are not available and inheritance is automatically disabled" it is possible to
include or exclude some of the default admin groups (account operators, print
operators ,etc.) The process that checks object against the adminSDHolder
object only looks at that definition of protected objects and in case of
groups it will also look at its members. It resets the DACL to match the DACL
of the adminSDHolder object and sets the admincount attribute to 1. The group
membership of a protected group is the criteria the process looks at, not the
attribute value of 1. The admincount attribute is just an administrative
measure for the process that says "been here", nothing else.
So, to add custom groups as
protected groups in AD, MS should see if it is interesting to implement in
Longhorn.
There is a way however to implement your
own protected groups. (I think it will work)
How to do that?
* Take a protected group (weakest one
possible)
* Create a distribution group with a name
like "Custom_Protected_Groups_Definition" and make that a member of the actual
protected group
* Put all custom users and groups
directly into the distribution group that need to be protected by
adminSDHolder
Now what will happen?
The adminSDHolder process sees the
memberships (transitive included) and protects them.
When a user logs on, he will be a member
of the distribution group "Custom_Protected_Groups_Definition" but the SID of
the actual (security) protected group will not be in the access token of the
user.
If a distribution group is a member of a
security group, the members of the distribution group will not be transitive
security members of the security protected group as the distribution group
blocks the security group membership
There is a catch however! -> DO NOT EVER CONVERT THE
DISTRIBUTION GROUP TO A SECURITY GROUP! (doing this will lift the security
group membership block and the users/group will suddendly get the SID of the
protected security group in their access token!)
I agree with Al you should be very careful changing the
configuration of the DACL of the adminSDHolder object! Remember that object
protects the default (very strong) users and groups!
Cheers,
Jorge
(cool: I think I just wrote something nice for my blog)
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx on behalf of Al MulnickSent: Tue
11/15/2005 7:04 PMTo:
ActiveDir@xxxxxxxxxxxxxxxxxxSubject: RE: [ActiveDir] Protecting
objects not covered by AdminSDHolder
That's interesting. As far as I can tell, the
adminsdholder is just aprocess that runs on the PDCe that wakes up and
checks for all objects thathave admincount set to 1. For each it
finds, it ensures that they reflectthe permissions set according to the
adminsdholder reference.My first pass at this would be to do likewise
with a custom app vs. tryingto piggy back on the adminsdholder
routine. The reason I say this is that Iwouldn't want any kind of
confusion in the settings and it's generally not arecommended solution to
modify the adminsdholder. Can be very bad if you doso
incorrectly.Any reason a script or other app wouldn't be a
choice? I realize you'relooking for apps that already exist first,
but just curious what theboundaries are. :)Al>From:
>Reply-To:
ActiveDir@xxxxxxxxxxxxxxxxxx>To:
>Subject: [ActiveDir] Protecting
objects not covered by AdminSDHolder>Date: Tue, 15 Nov 2005 16:16:24
-0000>>[I appreciate and understand the role of adminsdholder
and sdprop and>which objects it protects and how etc
etc.]>>I'm sure the answer to my question will be 'no' but I
have to ask in any>case :)>>Can additional groups and/or
user objects be added to the scope of>sdprop and adminsdholder, so that
they are protected as are other>objects, such as members of the Domain
Admins group?>>I have additional groups which are protected
today by virtue of being in>a segregated OU, where special permissions
are applied. I would rather>protect these objects with adminsdholder,
which I find to be a more>robust (and enforced)
approach.>>Is this possible? Are there plans to add the
functionality in later>editions (Longhorn)
perhaps?>>Thanks,>neil>>>___________________________>Neil
Ruston>Global Technology Infrastructure>Nomura International
plc>>>>PLEASE READ: The information contained in
this email is confidential and>intended for the named recipient(s)
only. If you are not an intended>recipient of this email please notify
the sender immediately and delete>your>copy from your system.
You must not copy, distribute or take any further>action in reliance on
it. Email is not a secure method of communication and>Nomura
International plc ('NIplc') will not, to the extent permitted
by>law,>accept responsibility or liability for (a) the accuracy
or completeness of,>or (b) the presence of any virus, worm or similar
malicious or disabling>code in, this message or any attachment(s) to
it. If verification of this>email is sought then please request a hard
copy. Unless otherwise stated>this email: (1) is not, and should not be
treated or relied upon as,>investment research; (2) contains views or
opinions that are solely those>of>the author and do not
necessarily represent those of NIplc; (3) is intended>for informational
purposes only and is not a recommendation, solicitation>or>offer
to buy or sell securities or related financial instruments.
NIplc>does not provide investment services to private customers.
Authorised and>regulated by the Financial Services Authority.
Registered in England>no. 1550505 VAT No. 447 2492 35. Registered
Office: 1 St>Martin's-le-Grand,>London, EC1A 4NP. A member
of the Nomura group of companies.>List info :
http://www.activedir.org/List.aspxList
FAQ : http://www.activedir.org/ListFAQ.aspxList
archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
To find out more about Reuters visit www.about.reuters.com
Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. | | | |
|
|