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=/library/en-us/adschema/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=/library/en-us/adschema/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=/library/en-us/secauthz/se
> curity/ace.asp?frame=true
>
> [3] DACL - Discretionary Access Control List -
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthz/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/
