I previously put in an MVP Wish or otherwise known as a Design Change Request (DCR) or also known as a LadyBug request in for allowing an attribute to be in multiple property sets. I was completely surprised when that request was closed as won’t fix and a question of give a concrete example of why that would be useful came back…
I was shocked.
I was stunned.
Had this person actually used AD in any real way? Had this person been out in the world where people are trying to set up permissions that make sense? Had this person looked at the newsgroup posts and various listserv (like activedir.org) comments on property sets.
I put in a comment of, is this closed or do you really want feedback. I don’t know. The comments say one thing, the status says another. One part of me would be shocked if it is truly closed because the DC team is normally extremely good at listening to the MVPs. Another part would not be shocked as there are parts of MS that have rubber super balls shoved as far down their ear canals as is possible with a sharp knife and a mallet.
For those who are like, WTF is this guy ranting about let me explain.
A property set is a special object in Active Directory that lets you group a set of Active Directory properties (we usually call them attributes though) into one object so we can assign one Access Control Entry (ACE) to a property set to grant rights to a whole bunch of attributes at once instead of creating a bunch of ACEs for the bunch of attributes. Why would one want to do this? Well if you understand how Windows security works, you know that an Access Control List is basically a list of ACEs. When you need to access an object, you have to tell it what kind of access you need, it then checks that object for that access by looking at the Security Identifiers (SIDs) in your security token and comparing them to each ACE in the ACL chain until it either hits an ACE or set of ACEs that grant you the rights necessary or hits an ACE that denies any part of the rights you need.
So it is optimal to have as few ACEs in the chain as possible. Microsoft saw this and said, hey, wouldn’t it be cool if we set up this thing, we will call it a property set to confuse people, that allows an admin to specify ONE ACE on an object instead of like 40 ACEs to specify permissions for 40 attributes. We would want to do this because it is likely you won’t be giving out permissions to attributes on a one attribute at a time basis, it will probably be in groups of like types of attributes. Sort of like role based auth/authz… So they come up with this great idea and then shoot it in the foot during implementation. An attribute can only be in one property set. So by gosh, only one role better need that attribute or else you will be granting that attribute separately anyway thereby defeating the whole point.
The Exchange Devs further dorked this all up with what they did to the property sets. Instead of using their own property set or the phone and mail options property set they used Personal and Public information prop sets so if you were already delegating those, surprise, someone just got a crap load more rights.
So anyway, stupendous idea, stupid implementation for one main thing. Only one property set for an attribute. Assuming an attribute could be in multiple property sets you could set up many role property sets and assign ACEs via those property sets and reading the ACLs would be easier than it is now in terms of not having to surf through a bazillion ACEs. Most admins can not properly read an ACL and have NO clue what access rights people really have. The effective rights stuff doesn’t really work well, you need to know what it can and can’t do for you but again, most admins have no clue. Plus, as you add more and more ACEs to an ACL you bloat up AD more and more and make it slower and slower. K3 helped this some with single instance store but this sort of falls into a category a good friend of mine says that MS has a habit of doing, provide a workaround for a problem they should fix. I am thankful for the single instance SD store but would much rather see good use of property sets so people can seriously reduce the number of ACEs on the objects.
Now this does bring up a good question but I am just saying that because I think the answer is obvious, not that it really is a good question. What happens if a person is in two different property sets, one that grants access to something and one that takes it away??? Oh my. I don’t know, how about follow the normal grant/deny inherited/deny rules? Seems pretty logical to me. I guess it could confuse someone but no more than they get confused by it now because again, most admins have no clue how this stuff works. They just keep granting more and more access until user A can get to their MP3 files.
So… let’s hear it, do you think we should have the ability to have an attribute in multiple property sets? If not, why not? Comment here or email me, I realize some people like to be anonymous.
So I assume we’d then customize our own property sets right? Or probably there would be a default set similar to what’s there currently – only that we’d be able to make it suit our own needs, or at least make it a bit more logical.
Hopefully this also leads to a clean up of the ACL advanced dialog box? I think Sakari refers to this as ACL dialog box (D). I’m certainly all for that – there isn’t any distinction between the property set names and the individual properties on that dialog, so if you don’t know/are not sure what they are ahead of time, it’s not really very useful anymore.
I guess this comes right back to your point – a good concept wasted.
Yeah that is the idea behind it, have the built in sets and then allow us to create more as we see fit. I also put in a separate idea on working on that ACL dialog to make prop sets clearer like having an expansion checkmark next to the propsets so you can expand them and see what is there.
I think you’re being way too kind. MS needed the same thing I need; a way to reduce the number of ace’s required to grant appropriate access. They built a way, and then thanks to the extent that Exchange uses the feature rendered it 100% unsable by anybody else. Yes, the implementation limit of one set per attribute is shortsighted; but to think that only Exchange would face the need for complicated ACLs is worse. It looks to me like the person who did the permissions work for Exchange was a junior level admin for whom just granting more access until it worked was his mantra. If this weren’t the case, someplace there would be documentation of the actual attributes they need access to, not just the list of property sets containing tons of attributes. Sorry to rant, but I would love to be able to actually use property sets instead of cursing MS for teasing me. How do we get them to fix this?
I can not find any fault in your logic. Exchange permissions are often the bane of my existence and completely agree they are half-assed. The only way to get them corrected is to float the complaints up through the support ranks and through the available feedback channels. If everyone were as vocal about this as I am I expect we might seem some changes.
If you aren’t beating on your Microsoft Technical Account Managers (TAMs) about this, start. That is what they are there for. Some of them like to think they are technical people, they aren’t, they are interfaces for customers to bitch at MS.
One point of note, I have found the Exchange groups to be the most resistent to actually listening to customers. Personally I would love to see an Exchange killer quality app to come out that runs on Windows as well as say BSD, that would get MSes attention and maybe cause someone to go sit on the Exchange group for a while.
I have successfully gotten a few changes into the Exchange product but it has always required my blood to do so as well as emails to folks such as Steve Ballmer and openly flogging the Exchange team and their silly ways in public forums. This has actually resulted in backlash from them aimed at me in the past. That simply strengthens my resolve more.
I see this as a more serious problem now, given the default security changes introduced in ADAM. For least privledge, you don’t have read access by default. With AD, you really only have to worry about Property Sets for write access – you automatically get read access for free. Along comes ADAM where Property Sets would make an ideal mechanism for completely controlling access rights, and you’re forced to make the Property Sets incredibly small because the grouping of attributes for read access likely doesn’t match the grouping of attributes for write access.
I was so thrilled when I first learned about property sets, I had in my mind already created a totally revamped strategy for delegating rights for our enviroment, and when I set out to learn more about property sets, I came across this excellent blog post and all my visions got drowned! I couldn’t believe they could be so stupid…
I haven’t check out if they for some fluke resaon might have changed this in Windows 2008, but I doubt it.
I have been thinking on what would happen if I decided to “hack” the DIT file and change this attribute to be multivalue, or in any other way make this a multivalue attribute. I have yet to figure out how do the hack though.