> I feel like I was told this once, but I could be making it up in a sleepy haze ...
Yep, I can confirm, a
property set gets one ACE in the ACL. To show it, I simplified an ACL on an OU
to SYSTEM FC, ADMINS FC, and joe\joe Public Information. Here is the dsacls and
raw SDDL output
[Wed
05/11/2005 18:41:28.38]
G:\>dsacls
OU=propset,OU=TestOU,DC=joe,DC=com
Access list:
{This object is protected
from inheriting permissions from the parent}
Effective Permissions on
this object are:
Allow BUILTIN\Administrators FULL CONTROL
Allow NT
AUTHORITY\SYSTEM FULL CONTROL
Permissions
inherited to subobjects are:
Inherited to all subobjects
Allow
BUILTIN\Administrators FULL CONTROL
Inherited to user
Allow
JOE\joe
SPECIAL ACCESS for Public
Information
WRITE
PROPERTY
READ PROPERTY
The command completed successfully
[Wed
05/11/2005 18:41:35.18]
G:\>adfind -default -f name=propset -sddc
ntsecuritydescriptor
AdFind V01.26.00cpp Joe Richards ([EMAIL PROTECTED])
February 2005
Using server: 2k3dc01.joe.com
Directory: Windows Server
2003
Base DN:
DC=joe,DC=com
dn:OU=propset,OU=TestOU,DC=joe,DC=com
>nTSecurityDescriptor:
[SDDL]
O:DAG:DUD:PAI(OA;CIIO;RPWP;e48d0154-bcf8-11d1-8702-00c04fb96050;bf967aba-0de6-11d0-a285-00aa003049e2;S-1-5-21-1862701446-4008382571-2198042679-1680)(A;CI;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)S:AI(OU;CIIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)(OU;CIIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)
>nTSecurityDescriptor:
[OWNER] O:DA
>nTSecurityDescriptor: [GROUP]
G:DU
>nTSecurityDescriptor: [DACL]
D:PAI(OA;CIIO;RPWP;e48d0154-bcf8-11d1-8702-00c04fb96050;bf967aba-0de6-11d0-a285-00aa003049e2;S-1-5-21-1862701446-4008382571-2198042679-1680)(A;CI;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)
>nTSecurityDescriptor:
[SACL]
S:AI(OU;CIIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)(OU;CIIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)
1
Objects returned
[Wed 05/11/2005
18:41:56.82]
G:\>
You will obviously
note the Admin ACE ((A;CI;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)) and
System ACE ((A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)) leaving
the ACE ((OA;CIIO;RPWP;e48d0154-bcf8-11d1-8702-00c04fb96050;bf967aba-0de6-11d0-a285-00aa003049e2;S-1-5-21-1862701446-4008382571-2198042679-1680))
as the ACE for joe\joe WP RP Public Information. You can see the rightsGuid for
Public Information as well as the schemaIDGuid for user.
Whether or not something
is happening in the actual DIT with that I can't obviously say, but I would
expect that raw binary is as it is in the DIT and adfind is displaying it.
> There is an important part to
resolve ... with an attr in two prop sets, imagine you check access to one, what
should be the state of the other prop set?
I understand what you are
saying here but this is the world we live in right now due to having two
mechanisms to assign permissions to the attributes. What is the state of the
Public Information property set if you apply one or more ACEs
for attributes that are normally in the Public Information property
set. What if you deny one or more of the attributes. How does that
get displayed? Answer? It doesn't, it is assumed by all of the tools that
you know what the property sets include and you work from there.
This
assumption probably is not a good thing because then people often don't
know what they are delegating since I would say a good majority of the
AD Admins don't know how to list property set members. This results in
too much delegation or duplicate delegation where duplicate delegation is
someone delegating the property set and then several of the attributes again
separately. I have seen this on multiple occasions in many different sized
directories and as recently as today.
In other words, if you had
p a1
a2 a3 a4 a5 a6 a7 a8
==============================
p1 x
x x x
p2
x
x x x
p3 x
x
x x
and you set WP for p1 I would NOT expect anything
to show for p2 and p3 just like nothing would be shown for p1 if you set WP on
a1-a4 individually. If I look at the GUI security dialog for the above ACL and
look at what is listed for joe\joe, I simply see WP RP Public Information, I
don't see all of the properties lit up. As for the effective permissions tab,
that thing is a riot, I have seen more things wrong in that than right. If I
display it for joe\joe on the above object it actually shows full control on
that object and it clearly doesn't as joe\joe isn't a member of anything by
domain users.
All of the GUI security tools and even the command line
ones don't do a great job of relating which people have access to what. The
confidentiality bit adds even more to it such that I ended up sending a note to
Dmitri and ~Eric the other day asking if it was feasible to do something around
it and the responses were of the "Unfortunately...." type. I understood the
responses, I was asking for something that could disclose information (it was an
idea around the functionality with allowedAttributesEffective but for reading)
and I am thinking of a better way to ask for what I am thinking.
So basically, to sum this up. Your thoughts are that it
would further complicate the reading of the ACLs but my response is that it
wouldn't add any confusion that isn't already there.
joe
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Brett Shirley
Sent: Wednesday, May 11, 2005 5:06 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] [OnTopic] Active Directory Property Set Madness
IIRC and ... I should say, I'm only like 37% sure of this, as AD schema stuff is one of my poor suits, it is NOT one ACE when you "grant" access to a property set, it is access to each individual attribute. Property sets are a lie told to you by the UI. I feel like I was told this once, but I could be making it up in a sleepy haze ...
So I _think_ we are storing 37 ACEs on the object ... use ldp.exe and check for yourself ... and let us know if my anti-sleepy drink (nearly pure aspertaine (sp?)) has any adverse memory affects.
The truth is ... frequently the ACEs provided is inhrerited
and generic, such that we can single instance the whole ACL/SD
across multiple objects (at least in Win2k3), so we're storing 37
ACEs but just once. But that only works sometimes, and is a
digression ... back to the regularly scheduled programming ...
Sooo I've always liked the idea of having an attribute in multiple property sets, it seems like the right thing to do, but ...
There is an important part to resolve ... with an attr in two prop sets, imagine you check access to one, what should be the state of the other prop set? To imply you have access to the other prop set, would be misleading and annoying ("It's checked, but I have no access?"). To imply there is no access would be mis-leading, and well quite frankly dangerous and unsecure ("How did he change that? What the ACL viewer lies!?").
This is _very_ important it is an annoying bug to overrepresent what people have access to, but it is a critical bug to say one doesn't have access to something they do ... and thus the rub ...
Sooo obviously, you goto some representation in the UI for partial permission to the other prop set, but if I remember the ACL editor box (that's like where the prop sets appear right? Been a while, I use ldp.exe, because an SD's like books by Goethe you can't truly appreciate if you don't read them in the original SDDL*) it is long, soooo what if this is off the scroll bar? You might not notice? __I think the current UI motif just wouldn't be good, you've got to get more inventive__, something very clever ... Maybe an exceptions list of other prop sets that you've given partial incindental access to? Even that feels kludgy ... Dude, see this is hard, ah screw it ... I'm going back to something easy, like making sure Exchange can continously log 5 TBs without dismounting an entire SG ...
Cheers,
Brett [msft]
Building 7 Garage Door Operator
Posting "AS IS" ...
* I'm kind of teasing, as I personally think SDDL is a HORRIBLE syntax, although I can read most of it. And I don't read German, so I wouldn't know if Goethe is better in the original language.
On Tue, 10 May 2005, joe wrote:
> Let's talk property sets... I have ranted about them before but got
> reminded again today about how much I like them and hate them and
> figured, I will blow off steam and rant and see if anyone feels the
> same and is willing to respond.
>
>
> Property sets are an amazingly great idea. I mean really, kudos to
> whomever at MS came up with this brilliant idea. Unfortunately they
> suffer from a very poor implementation[1].
>
> It seems like MS came up with this great idea and then stopped dead in
> the middle of the implementation and let it drop on the floor. And
> then it has been kicked a couple of times along the way to pay some
> measure of tribute to it or to make it even less useful.
>
> Why do I say that.... Well first why this is great.
>
> This is great in case you need to apply permissions to your Active
> Directory. This is something that occasionally you will want to do.
> Now you want it to be very locked down but you don't want too many
> ACEs[2] in a DACL[3] because when the security subsystem has to
> process a DACL it reads each entry until it hits an entry that says
> "NO!". So for reading many things in an AD for instance, it will have
> to enumerate all ACEs on every object you return. If you have 10 ACEs
> on an object, you will necessarily go faster than if you have 500 ACEs
> on an object unless you are simply denied access right off in both.
>
> So, MS came up with this cool mechanism that allows you to couple
> multiple properties together in a single grouping called a property
> set and if you specify that property set in the ACE you can grant all
> sorts of permissions in one fell swoop. Look at, for instance, the
> Public Information property set in any raw out of box Windows AD. You
> will see it speaks for many attributes - for a list see
> http://msdn.microsoft.com/library/default.asp?url="">
> ema/ad
> schema/r_public_information.asp.
>
> In K3SP0 that is something like 37 attributes. Those being (by their
> name not lDAPDisplayName) Additional-Information, Allowed-Attributes,
> Allowed-Attributes-Effective, Allowed-Child-Classes,
> Allowed-Child-Classes-Effective, Alt-Security-Identities, Common-Name,
> Company, Department, Description, Display-Name-Printable, Division,
> E-mail-Addresses, Given-Name, Initials, Legacy-Exchange-DN, Manager,
> ms-DS-Allowed-To-Delegate-To, ms-DS-Auxiliary-Classes,
> ms-DS-Approx-Immed-Subordinates, Obj-Dist-Name, Object-Category,
> Object-Class, Object-Guid, Organization-Name,
> Organizational-Unit-Name, Other-Mailbox, Proxy-Addresses, RDN,
> Reports, Service-Principal-Name, Show-In-Address-Book, Surname,
> System-Flags, Text-Country, Title, User-Principal-Name.
>
> I order to GRANT someone WRITE to those attributes without a property
> set, it would require 37 separate ACEs for a single object type or for
> all object types. With a property set you only need one (1) ACE. Not
> only that but the Public Information property set applies only to
> user, computer, and inetOrgPerson. In order to duplicate that in
> normal ACEs it means 37*3 or
> 111 ACEs. To recap, 1 (one) property set ACE is equal to 111 attribute ACEs.
> How can that NOT be a cool idea?
>
> So where did MS miss the boat you ask? Again, IMO, the implementation.
>
> Attributes can only be in 1 (one!!w!!t!!f!!!) property set. This means
> you better choose quite well which property set you put an attribute
> in because one wrong slip and you would be giving more permissions
> than needed to someone which in this world of principal of least
> privilege, you get slapped for[4].
>
> But wait... There are property sets that already exist... Oh n/m, you
> can change them... Oh wait... MS Apps[5] that apply special
> permissioning when installing into AD make assumptions on what is in
> property sets and changing the property sets may put you into a
> position where PSS will (and don't they won't because I have heard it
> personally from Alliance)... will tell you, that is unsupported, you need to fix that right away - what were you
> thinking[6][7]!!!
>
> So that means any attributes already in property sets are
> theoretically off limits for making your own "logical" property sets.
> Anyway, some SAM attributes absolutely are offlimits and just won't
> let you change the property set they are in, for an example of one... member.
>
> Why is this again? Because attributes can only be a member of one
> property set. If we could fix this one small little thing, property
> sets would be amazingly useful and go from the relative lack of use
> they enjoy now to being the primary way of assigning permissions in
> the directory. I mean there are some other things that are confusing
> to most everyone such as trying to figure out what attributes a
> property set apply to or determining what property set an attribute is
> a member of but the real killer is the fact that an attribute can only
> be in one property set. If that weren't the case, people would get
> past those confusion points quite fast. I know I would probably put
> together some tools to make it easier, now I don't see the use. How
> many people are using them enough to actually need a special tool to use them?
>
> Visualize a system where setting up property sets was not only easy
> and fairly intuitive[8], but you could add the same attribute to
> multiple property sets. That way you could set up a form of roles for
> various AD ops and assign those ad hoc. This role needs to modify
> attr1, attr2, attr3, attr4, attr5. This role needs to modify attr1, attr3, attr5, attr6, attr7.
> This role needs attr2, attr5, and attr7. Etc etc etc. Now you would
> have to try and figure out which attrs would always be used together
> and assuming they aren't already in a set, put them in a set. Worse
> case, you are back to setting up ACEs for every attribute.
>
> If you want to use a property set now to assign WRITE PROPERTY and
> don't want to grant all of the permissions granted by the property set
> it is either A) Don't use the property set or B) Use enough DENIES
> to protect the attributes you want protected.
>
> Another mistake with the property sets in the base OEM setup is the
> property set called Phone and Mail Options
> (E45795B2-9455-11d1-AEBD-0000F80367C1) - no attributes in this
> property set at all... Must not have any phone or mail attributes in AD.
>
>
> So anyway, here we are with a really cool idea but implemented in a
> non-cool way and then along comes Exchange which has to mark its
> territory by throwing its stuff all over the directory....
>
> Instead of putting the Exchange attributes into some well named
> property sets, say like Phone and Mail Options or Heaven Forbid
> Exchange Attributes or maybe even multiple property sets broken out
> logically into subgroups that may be good admin lines to follow (like
> say IM attribs in one, attribs for mailbox/mail-enabled in another,
> etc) they seem to randomly pick Public Information and slam an additional 120 attributes into that property set.
> Then ACEs are slammed into AD for the Exchange Servers that give them
> WP to this property set and if you are trying to break up admin of
> Exchange and AD the word is to give the Exchange Admins WP to this
> property set as well instead of giving the Exchange folks domain admin[9] rights.
>
> Whoops, oh yeah, there are attributes in that property set that an
> Exchange Admin probably shouldn't have write access to... Say like
> userPrincipalName or servicePrincipalName or systemFlags or Manager... Etc. So what do you do?
> Why you apply a bunch of DENY ACEs. Everyone loves DENY ACEs. You get
> to apply it for any Groups you have Exchange Admins in that you gave
> Public Information WP to plus don't forget the Exchange Servers Groups....
>
> There are some other fun things Exchange did there as well, one fun
> one I ran into today is that publicDelegates is in one property set
> and publicDelegatesBL is in another one. That just doesn't make a
> whole lot of sense to me you know?
>
>
>
> So anyway, if property sets were implemented properly and you could
> put attributes in multiple property sets, how many people would use
> them? How many people actually use them in any great way now despite
> the issues? How many people don't even have a clue on how to determine
> what attributes are in what property sets and what object types the
> property sets apply to WITHOUT going to
> http://msdn.microsoft.com/library/default.asp?url="">
> ema/ad
> schema/property_sets.asp?frame=true
>
> The question is can MS correct this issue? Barring that, can they
> implement something next to it that can be used instead? It isn't like
> we need more stuff dorking with how ACLs are read and interpreted
> making it very difficult to work out who can read or write what[10]. I
> mean I am glad they did the confidentiality bit versus nothing at all.
> But as one of my good buddies with an English accent and a Florida tan
> tends to say, MS keeps coming up with workaround solutions for issues
> in the basic implementation versus fixing the implementation.
>
> I would absolutely love someone to come along and say, you fool, here
> is how you put attributes into multiple property sets, it is so easy
> you overlooked it... Please... Anyone...
>
>
> joe
>
>
> PS. This is on my blog (blog.joeware.net) if you would rather respond
> there than to the listserv or if you even want to respond directly to
> me. I know some of you are a little shy. :o)
>
>
>
>
> [1] IMO. Copyright 2005 joe
>
> [2] ACE - Access Control Entry -
> http://msdn.microsoft.com/library/default.asp?url="">
> thz/se
> curity/ace.asp?frame=true
>
> [3] DACL - Discretionary Access Control List -
> http://msdn.microsoft.com/library/default.asp?url="">
> thz/se
> curity/acl.asp?frame=true
>
> [4] And rightly so. Some of us have been pushing that line for a
> loooooooong time.
>
> [5] Guess which ones.
>
> [6] A la Dr. Phil.
>
> [7] Ok so no, I didn't actually change it and ask them, I asked them
> up front. Once I finished explaining to them what property sets are
> and why I wanted to change one, then they told me that wouldn't be
> supported. Honest to Betsy truth.
>
> [8] Honestly, I don't care if it is easy or intuitive, that is my love
> for my fellow admins. Me, I just want to be able to use attributes in
> multiple property sets.
>
> [9] But they really want you to give Domain Admin or at least Account
> Operator.
>
> [10] Shot at confidentiality bit and effective permissions GUI all in
> one line.
>
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive:
> http://www.mail-archive.com/activedir%40mail.activedir.org/
>
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
