Yep, I asked first. I knew that I wouldn't always be with the company I was working for or at least wouldn't always be doing what I was doing. This means providing an environment understandable to and supportable by others. The logical choice since there is an existing support contract is to have that understood and supported by MS. Not dumping on you, just explaining why I asked. The very fact that they didn't really understand what I was talking about is enough to put one on edge about it.
Consider further... You deploy raw K3. You see the property sets, you learn about them, you realize, hey MS really kind of missed the boat here. So you correct the ones you can correct (i.e. you don't fix anything SAM related because SAM says so). Everything is beautiful. A few years down the road you decide that your mail hoster sucks and you want to bring it in house, so you load up Exchange 2003. Nothing works right... You go to troubleshoot it, it is a nightmare because there is no simple way to see what queries/updates are being submitted and failed and what the failure reasons are. With luck you run into an error that you are able to track down to something and realize, hey, you don't have permission to do this or that. You contact MS and say, hey Exchange didn't install correctly. They tell you to get them an ACL dump, you do so, they say it looks fine, must be something else. If you are lucky, you will hit an analyst or MS or other consultant who has talked to people about or previously looked at property sets. If not, good luck in finding the resolution of that problem in any real time frame, expect PSS to tell you to rerun forest prep and domain prep several times[1]. Another scenario. You previously modified the property sets and tweaked them so that Exchange worked fine. A couple of years down the road, some other XYZ app from MS which also incorrectly just assumes what attributes are in what property sets is installed and doesn't work... Same exact scenario as above but I can hear some people thinking, that wouldn't happen with Exchange, you always install that right away.... So anyway, the app never looked to see what attributes were in the property set and probably doesn't have enough documentation to tell you what accesses it needs let alone why. You contact the vendor, even MS, and I will bet money you can expect vacant stares. Anyway, when was the last time any consultant on this list actually walked into a company when trying to help them and when they were doing their cursory peek at the directory to see how it was layed out and actually looked at what was in the property sets in the forest to see if they had been modified? How many consultants make it a point to ever look? How many consultants on this list actually could enumerate the property set attributes in a given forest in any reasonable time? I can do it pretty quickly with adfind and little perl script. Not sure of any other easy ways of doing it due to the funky GUID handling. If you took over a forest you didn't build, did you ever go verify that the property sets were all configured as per defaults or were changed? If you manage a domain in a forest you don't manage, have you ever looked at the property sets to see what they were defined like? This is a very severely overlooked area. The difficulty of use and lack of functionality make it so it is just a little bastard red headed step child by the side of the road covered with muck. Really bright people figure them out and maybe dork with them, everyone else ignores them. Going into someone's forest and removing attributes from the default property sets is probably at some point in the future going to burn them. Adding attributes to a default property set could possibly do it as well if some app assigns that permission with an assumption of what rights it grants and it actually grants more. As for the default ACL model... Completely different rant. Of course it is entirely too open. Unfortunately MS management learned about the word security too late for Active Directory. Personally I wouldn't mind seeing all Default SDs chopped down to nothing but localsystem and domain administrator, everything else is inherited. Nothing visible by default, you have to enable everything. The next rant after the default ACL Model is the whole thing with Creator/Owner. I could go on about that one for some time too. It just blows apart what you can do with security. There is one workaround hack I would like to see MS implement if they don't remove that completely. The ability to say that all objects created in this OU or this domain or this forest will all be stamped with this specific owner regardless of who actually created the object. Instead you have everyone that cares about security chasing through their forest changing the owner fields on all object SDs like a little boy following a puppy piddling in different spots throughout the house. joe [1] I have a great story where some MCS guys were having trouble doing something with the Exchange support guys and the response from PSS was rerun forest prep. I was like WHAT!! Piss off. PSS says, you don't have to worry, it won't change anything... What was my response? Well if it won't change anything, how do you expect it will fix anything and why would we run it? We didn't end up running it. The problem was really one with WINS name resolution. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, Guido Sent: Wednesday, May 11, 2005 5: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/
