Hey joe - what a post - took forever to read but it was quite entertaining as I've been through similar thoughts myself.
However, I didn't specifically ask for support from PSS. When you asked for the support for removing attributes from property sets, I doubt that the PSS folks really understood you in the first place (specifically since you had to explain what this means... ;-) I've found removal of attributes from permission property sets work quite well - and the nice thing is it works instantaniously. Obviously you can't take it too far and you might need to re-add some attributes to another property set and then grant specific rights for Exchange or other apps etc. - but at least now you have a chance to remove those overly extensive rights more easily from authenticated users and the SELF sec prin. I fully agree that the defaults are less than ideal - but I'm sure glad you can change them in Win2K3... And they wouldn't be editable if they weren't made to be edited... Sure, allowing an attribute in multiple pr.sets would be nice - but I also agree with Brett that this would cause plenty of other issues. Instead I'm fine with breaking up the defaults and adjusting them as I require them. The apps don't typically don't care HOW they get certain permissions - they just care THAT they get them. What I think is even worse in the default AD secrity model (and is somewhat related to prop.sets), is simply the vast rights that Authenticated users have in the directory and how many apps rely on leveraging these rights. One sample is ISA (and many other apps work similar) which assumes its computer account - as an authenticated user - will have sufficient access to read stuff from it's rule set in the System container within a specific domain NC... Not so if you've removed the Read permissions here for Auth. Users - it's an easy fix to add the ISA servers to their own group and grant the necessary rights, but this could have been performed ahead of time via the ISA setup. So regardless of the scope of prop.sets, it's quite a chore to remove the default Auth.User rights and still have a working environment. And ofcourse it's difficult to know what are the minimum rights required to do this and that as a normal user just the same (e.g. to successfully apply GPOs etc.). Sanja's AD Delegation WP contains some very useful infos here, but I'd love to see even more on this. Moreover, I'd love to see the dev-folks of any app accessing AD (not only, but including the MS dev folks) to think more clearly about what permissions they need to access their data in AD without assuming the rights are granted for Auth. Users... => and that's why I'd say PSS is afraid to support this since they have no means to know what's required by all or their own apps either. So it's back to testing this yourself in great detail before you make any efforts to lockdown AD like you'd like to. /Guido -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sakari Kouti Sent: Mittwoch, 11. Mai 2005 13:12 To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] [OnTopic] Active Directory Property Set Madness Hi Brett (and joe), Actually, granting (or denying) permission to one property set takes only one ACE. Each property set corresponds to one controlAccessRight object in the Configuration partition, and that object has a rightsGuid attribute. The ACE that uses this property set contains that rightsGuid in its Object Type field. In turn, each attribute that belongs to that property set has the same rightsGuid in the attributeSecurityGUID of its attributeSchema object. AttributeSecurityGUID is single valued, which means that an attribute can reside in only one property set. To be exact, rightsGuid and attributeSecurityGUID are not quite the same, because the former uses the string syntax, while the latter uses the binary syntax. But with the appropriate conversion, they are the same. I'm not sure if replacing 37 ACEs with one gives you any performance gain (as Joe wrote), because Windows still has to evaluate, which 37 attributes belong to that one set. I think the biggest madness is that the built-in sets are quite funny. For example, "General Information" has nothing to do with the General tab of ADUC. "General Information" contains 12 attributes, one of which is in the General tab. Other three are visible in ADUC, while the remaining eight are not shown in ADUC. The excel file available at http://www.kouti.com/tables.htm documents these for the user class (for which they are mainly used for). Also, the property sets should have been made separately for "internal use" and normal admin use. Now the admin must think does it hurt if he grants or denies sDRightsEffective, showInAdvancedViewOnly, and sIDHistory to or from someone, along with the property set. And because the builtin sets are used in the default ACEs, all users of the forest can see the logonCount of all other users, for example. I wonder if this is really necessary. Yours, Sakari > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Brett Shirley > Sent: Wednesday, May 11, 2005 12:06 PM > 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=/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/ > 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/
