OK - now that this conversation is started, and the interest level is sort of there... What about the permissions and rights for the Built-in and Default groups and users?
Let's take, for example Group Policy Creator Owner. How is this built, controlled and how does it manifest its control over GPOs? -rtk > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:ActiveDir- > [EMAIL PROTECTED] On Behalf Of Grillenmeier, Guido > Sent: Wednesday, May 11, 2005 4:03 PM > To: ActiveDir@mail.activedir.org > Subject: RE: [ActiveDir] [OnTopic] Active Directory Property Set Madness > > 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/ 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/
