joeware - never stop exploring... :)

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/adschema/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/adschema/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

[1] IMO. Copyright 2005 joe

[2] ACE – Access Control Entry – http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthz/security/ace.asp?frame=true

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