RE: [ActiveDir] [OnTopic] Active Directory Property Set Madness
Joe wrote: Cool Sakari, if you don't mind I made some small mods to it. I have it preload the attributes and then the lookups go much faster. No, I don't mind. I made the original to be able to investigate things for our book, and I only needed to run the script a couple of times. Therefore, no point in optimizing it. Joe, ok to put your optimized version next to the original one at www.kouti.com? Yours, Sakari 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/
RE: [ActiveDir] [OnTopic] Active Directory Property Set Madness
Absolutely. Knock yourself out Sakari. :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sakari Kouti Sent: Saturday, May 21, 2005 1:07 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] [OnTopic] Active Directory Property Set Madness Joe wrote: Cool Sakari, if you don't mind I made some small mods to it. I have it preload the attributes and then the lookups go much faster. No, I don't mind. I made the original to be able to investigate things for our book, and I only needed to run the script a couple of times. Therefore, no point in optimizing it. Joe, ok to put your optimized version next to the original one at www.kouti.com? Yours, Sakari 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/
RE: [ActiveDir] [OnTopic] Active Directory Property Set Madness
The interesting thing... For the AD component that is a function of the groupPolicyContainer object. That occurs wherever in AD you create those objects by whichever ID. On the file system, it is just how the ACLs are set on the folders when created, you will note inheritence is turned off all over the place in there. If you manally create a folder in the policies folder it should have inheritence enabled. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guy Teverovsky Sent: Thursday, May 12, 2005 8:52 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] [OnTopic] Active Directory Property Set Madness The interesting thing is that the permissions of the newly created GP Objects are not inherited neither from the System\Policies container in the default NC, nor from the Policies folder in the SYSVOL. The permissions are taken from the defaultSecurityDescriptor of the groupPolicyContainer object class. My biggest issue with this group is that it's a global group which can not contain accounts from other domains or forests (and it's also well-known security principal, so it can't be converted to local or universal). In my case I ended up with adding a DLG to Policies folder and container ACL and had to change the defaultSecurityDescriptor to include another DLG with admin permissions over all the GPOs. The bad part is that some vendors assume that when dealing with GPOs you are either member of GPCO or Domain Admin. Guy -Original Message- From: [EMAIL PROTECTED] [mailto:ActiveDir- [EMAIL PROTECTED] On Behalf Of joe Sent: Thursday, May 12, 2005 3:40 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] [OnTopic] Active Directory Property Set Madness Let's take, for example Group Policy Creator Owner. How is this built, controlled and how does it manifest its control over GPOs? Look at the ACL on your Policy Container and the Policies folder. You should see On the Policy Container... Allow x\Group Policy Creator Owners SPECIAL ACCESS CREATE CHILD On the Policies folder x\Group Policy Creator Owners:(special access:) READ_CONTROL SYNCHRONIZE FILE_GENERIC_READ FILE_GENERIC_WRITE FILE_GENERIC_EXECUTE FILE_READ_DATA FILE_WRITE_DATA FILE_APPEND_DATA FILE_READ_EA FILE_WRITE_EA FILE_EXECUTE FILE_READ_ATTRIBUTES FILE_WRITE_ATTRIBUTES x\Group Policy Creator Owners:(OI)(CI)(IO)(special access:) GENERIC_READ GENERIC_WRITE GENERIC_EXECUTE Once someone creates the relevant AD Objects and file system objects, they are the owner of the items so they have FC of them. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kingslan, Rick T. Sent: Wednesday, May 11, 2005 5:27 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] [OnTopic] Active Directory Property Set Madness 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
RE: [ActiveDir] [OnTopic] Active Directory Property Set Madness
I am not sure there is anything odd with that specific group. Initially the only odd thing may be around the creation of the gpc object but now that I looked at the Default SD in the schema, it is configured there to not inherit so even that isn't odd. It is following all of the normal rules, it is just that you don't often see things configured that way. The group itself can't have the scope changed, that is a function of it being a well known RID object[1]. The SAM is hard coded to disallow modifications to objects with RIDs less than some specific value which if I recall is 1000. So looking at the RID of the group - 520, it is following that rule as well. joe [1] I don't know if they qualify as a well known security principal, that is usually, from what I have seen, a term dedicated to built in types like SELF, SYSTEM, INTERACTIVE, Administrators, etc where the SID is ALWAYS identical on any given machine. A well known RID object is an object that has different SIDs but the RIDs are always the same across domains such as Domain Admins, Enterprise Admins, etc. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Thursday, May 12, 2005 10:01 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] [OnTopic] Active Directory Property Set Madness Right. And joe thinks I asked this question because I didn't know. ;o) There are interesting idiosyncrasies with the built-in and default groups that are not well understood. This was the real reason that I was bringing up the discussion - to hopefully ferret out some of the interesting and peculiar, and mostly unknown, behavior of the groups and principals to the masses. -rtk -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guy Teverovsky Sent: Thursday, May 12, 2005 7:52 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] [OnTopic] Active Directory Property Set Madness The interesting thing is that the permissions of the newly created GP Objects are not inherited neither from the System\Policies container in the default NC, nor from the Policies folder in the SYSVOL. The permissions are taken from the defaultSecurityDescriptor of the groupPolicyContainer object class. My biggest issue with this group is that it's a global group which can not contain accounts from other domains or forests (and it's also well-known security principal, so it can't be converted to local or universal). In my case I ended up with adding a DLG to Policies folder and container ACL and had to change the defaultSecurityDescriptor to include another DLG with admin permissions over all the GPOs. The bad part is that some vendors assume that when dealing with GPOs you are either member of GPCO or Domain Admin. Guy -Original Message- From: [EMAIL PROTECTED] [mailto:ActiveDir- [EMAIL PROTECTED] On Behalf Of joe Sent: Thursday, May 12, 2005 3:40 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] [OnTopic] Active Directory Property Set Madness Let's take, for example Group Policy Creator Owner. How is this built, controlled and how does it manifest its control over GPOs? Look at the ACL on your Policy Container and the Policies folder. You should see On the Policy Container... Allow x\Group Policy Creator Owners SPECIAL ACCESS CREATE CHILD On the Policies folder x\Group Policy Creator Owners:(special access:) READ_CONTROL SYNCHRONIZE FILE_GENERIC_READ FILE_GENERIC_WRITE FILE_GENERIC_EXECUTE FILE_READ_DATA FILE_WRITE_DATA FILE_APPEND_DATA FILE_READ_EA FILE_WRITE_EA FILE_EXECUTE FILE_READ_ATTRIBUTES FILE_WRITE_ATTRIBUTES x\Group Policy Creator Owners:(OI)(CI)(IO)(special access:) GENERIC_READ GENERIC_WRITE GENERIC_EXECUTE Once someone creates the relevant AD Objects and file system objects, they are the owner of the items so they have FC of them. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kingslan, Rick T. Sent: Wednesday, May 11, 2005 5:27 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] [OnTopic] Active Directory Property Set Madness 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
RE: [ActiveDir] [OnTopic] Active Directory Property Set Madness
- For i = 1 To 2 : strDest = strDest arrBytes(8 + i) : Next strDest = strDest - For i = 1 To 6 : strDest = strDest arrBytes(10 + i) : Next strDest = strDest } 'WScript.Echo attrSeGuid: strDest GuidBinFormatToStrFormat = strDest End Function -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sakari Kouti Sent: Thursday, May 12, 2005 10:23 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] [OnTopic] Active Directory Property Set Madness Now that Joe brought this up, I uploaded a script that does this enumeration on http://www.kouti.com/scripts.htm (at the bottom of the page). You need only end-user permissions to run this script. You could first run it in a clean forest and a clean forest with Ex2003 installed, to get a reference. Then run it in the customer network and use windiff or whatever to pinpoint differences from the clean install. Yours, Sakari 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/
RE: [ActiveDir] [OnTopic] Active Directory Property Set Madness
Do you mean the memberof attribute?
I have seen quite a few backlinks included in the property sets. I figured
it was for read access because as you note, you obviously, can't write the
info. Ditto for constructed attributes like tokenGroups, etc. At least in
that case, both linked attributes are in the same property set, there are
incidents of the linked attributes in two different property sets. One I
just ran into is publicDelegate and publicDelegateBL. One is in personal
info and the other is in public info.
F:\tempadfind -schema -f ldapdisplayname=publicdelegate*
attributesecurityguid
AdFind V01.26.00cpp Joe Richards ([EMAIL PROTECTED]) February 2005
Using server: 2k3dc01.joe.com
Directory: Windows Server 2003
Base DN: CN=Schema,CN=Configuration,DC=joe,DC=com
dn:CN=ms-Exch-Public-Delegates,CN=Schema,CN=Configuration,DC=joe,DC=com
attributeSecurityGUID: {77B5B886-944A-11D1-AEBD-F80367C1}
dn:CN=ms-Exch-Public-Delegates-BL,CN=Schema,CN=Configuration,DC=joe,DC=com
attributeSecurityGUID: {E48D0154-BCF8-11D1-8702-00C04FB96050}
2 Objects returned
F:\tempadfind -config -rb cn=extended-rights -f
rightsguid=77B5B886-944A-11D1-AEBD-F80367C1 displayname
AdFind V01.26.00cpp Joe Richards ([EMAIL PROTECTED]) February 2005
Using server: 2k3dc01.joe.com
Directory: Windows Server 2003
Base DN: cn=extended-rights,CN=Configuration,DC=joe,DC=com
dn:CN=Personal-Information,CN=Extended-Rights,CN=Configuration,DC=joe,DC=com
displayName: Personal Information
1 Objects returned
F:\tempadfind -config -rb cn=extended-rights -f
rightsguid=E48D0154-BCF8-11D1-8702-00C04FB96050 displayname
AdFind V01.26.00cpp Joe Richards ([EMAIL PROTECTED]) February 2005
Using server: 2k3dc01.joe.com
Directory: Windows Server 2003
Base DN: cn=extended-rights,CN=Configuration,DC=joe,DC=com
dn:CN=Public-Information,CN=Extended-Rights,CN=Configuration,DC=joe,DC=com
displayName: Public Information
1 Objects returned
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Sakari Kouti
Sent: Thursday, May 12, 2005 10:59 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] [OnTopic] Active Directory Property Set Madness
joe wrote:
Another mistake with the property sets in the base OEM setup is the
property set called Phone and Mail Options
(E45795B2-9455-11d1-AEBD-F80367C1) - no attributes in this
property set at all... Must not have any phone or mail attributes in
AD.
I actually reported this to Microsoft five years ago, along with another
bug, where Group Membership property set contained the membership property.
However, checking this permission didn't affect anything, because membership
is a property of a group object and this property set was attached to user
object.
They fixed Group Membership for WS2003, but for Phone and Mail Options the
reply was that it will be used once the Exchange folks start to use it (so
it was a placeholder). However, even Ex2003 doesn't use it, so it seems that
this placeholder was not needed, after all.
If someone actually wants to read on, here are three samples of the prop set
peculiarities:
- givenName and sn are part of Public Information but initials is part of
Personal Information.
- displayName is part of General Information but cn is part of Public
Information. Quite confusing to an administrator.
- Country/region is stored in three attributes (c, co, and countryCode).
These three all belong to different property sets (Personal Information,
Public Information, and General Information).
So, some wishes about prop sets:
- There were different prop sets for internal attributes and the ones
visible in ADUC.
- Exchange would not mess the builtin prop sets, but would add its own, that
would use a Ex prefix.
- The prop set would at least somewhat correspond to the tabs in ADUC.
Yours, Sakari
PS. I acknowledge that those wishes may also have some drawbacks, such if
Exchange added its own prop sets, the existing accounts would need new ACEs.
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/
RE: [ActiveDir] [OnTopic] Active Directory Property Set Madness
But it isn't just the problem with what you may or may not have documents. As we have both mentioned, vendors are horrible in terms of understanding and documenting what rights/permissions their applications need. Exchange is but one example. It gets even worse when the GUI the vendor supplies also applies its own security which doesn't align with the backend security such that someone who does something one way can do it, but if they do it through the vendor supplied method they can't Exchange is a stellar example of that as well. You need far more rights to do things in the GUI or through CDOEXM than you do from say an LDAP update standpoint. But back to the very beginning of this gripe, I think we would be much better off with the ability to have attributes in multiple property sets. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, Guido Sent: Thursday, May 12, 2005 12:04 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] [OnTopic] Active Directory Property Set Madness I do understand - that's what documentation is for... But I tend to agree that documentation lacks in many places. However, you don't only need it for changs in Property Sets - you basically need it for any security change (or other critical change) you perform in AD which is out of the standard, e.g. changing the Default Security Descriptor or any other exising rights in AD. Especially the removal of rights can hurt, as you don't necessarily see it during an analysis (unless you know what you're looking for). So I'd certainly only go this way if you have a good change mgmt system and document ACL changes (incl. those in Property Sets). And yes, that can still hurt you down the road because people even forget they have this documentation or they don't keep it up-to-date. But that's true for any change, not just ACL related changes. Doesn't mean you should leave everything set to the default if the default is unacceptable to you. /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Donnerstag, 12. Mai 2005 02:32 To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] [OnTopic] Active Directory Property Set Madness 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
RE: [ActiveDir] [OnTopic] Active Directory Property Set Madness
Right. And joe thinks I asked this question because I didn't know. ;o) There are interesting idiosyncrasies with the built-in and default groups that are not well understood. This was the real reason that I was bringing up the discussion - to hopefully ferret out some of the interesting and peculiar, and mostly unknown, behavior of the groups and principals to the masses. -rtk -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guy Teverovsky Sent: Thursday, May 12, 2005 7:52 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] [OnTopic] Active Directory Property Set Madness The interesting thing is that the permissions of the newly created GP Objects are not inherited neither from the System\Policies container in the default NC, nor from the Policies folder in the SYSVOL. The permissions are taken from the defaultSecurityDescriptor of the groupPolicyContainer object class. My biggest issue with this group is that it's a global group which can not contain accounts from other domains or forests (and it's also well-known security principal, so it can't be converted to local or universal). In my case I ended up with adding a DLG to Policies folder and container ACL and had to change the defaultSecurityDescriptor to include another DLG with admin permissions over all the GPOs. The bad part is that some vendors assume that when dealing with GPOs you are either member of GPCO or Domain Admin. Guy -Original Message- From: [EMAIL PROTECTED] [mailto:ActiveDir- [EMAIL PROTECTED] On Behalf Of joe Sent: Thursday, May 12, 2005 3:40 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] [OnTopic] Active Directory Property Set Madness Let's take, for example Group Policy Creator Owner. How is this built, controlled and how does it manifest its control over GPOs? Look at the ACL on your Policy Container and the Policies folder. You should see On the Policy Container... Allow x\Group Policy Creator Owners SPECIAL ACCESS CREATE CHILD On the Policies folder x\Group Policy Creator Owners:(special access:) READ_CONTROL SYNCHRONIZE FILE_GENERIC_READ FILE_GENERIC_WRITE FILE_GENERIC_EXECUTE FILE_READ_DATA FILE_WRITE_DATA FILE_APPEND_DATA FILE_READ_EA FILE_WRITE_EA FILE_EXECUTE FILE_READ_ATTRIBUTES FILE_WRITE_ATTRIBUTES x\Group Policy Creator Owners:(OI)(CI)(IO)(special access:) GENERIC_READ GENERIC_WRITE GENERIC_EXECUTE Once someone creates the relevant AD Objects and file system objects, they are the owner of the items so they have FC of them. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kingslan, Rick T. Sent: Wednesday, May 11, 2005 5:27 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] [OnTopic] Active Directory Property Set Madness 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
RE: [ActiveDir] [OnTopic] Active Directory Property Set Madness
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. Now that Joe brought this up, I uploaded a script that does this enumeration on http://www.kouti.com/scripts.htm (at the bottom of the page). You need only end-user permissions to run this script. You could first run it in a clean forest and a clean forest with Ex2003 installed, to get a reference. Then run it in the customer network and use windiff or whatever to pinpoint differences from the clean install. Yours, Sakari 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/
RE: [ActiveDir] [OnTopic] Active Directory Property Set Madness
joe wrote: Another mistake with the property sets in the base OEM setup is the property set called Phone and Mail Options (E45795B2-9455-11d1-AEBD-F80367C1) - no attributes in this property set at all... Must not have any phone or mail attributes in AD. I actually reported this to Microsoft five years ago, along with another bug, where Group Membership property set contained the membership property. However, checking this permission didn't affect anything, because membership is a property of a group object and this property set was attached to user object. They fixed Group Membership for WS2003, but for Phone and Mail Options the reply was that it will be used once the Exchange folks start to use it (so it was a placeholder). However, even Ex2003 doesn't use it, so it seems that this placeholder was not needed, after all. If someone actually wants to read on, here are three samples of the prop set peculiarities: - givenName and sn are part of Public Information but initials is part of Personal Information. - displayName is part of General Information but cn is part of Public Information. Quite confusing to an administrator. - Country/region is stored in three attributes (c, co, and countryCode). These three all belong to different property sets (Personal Information, Public Information, and General Information). So, some wishes about prop sets: - There were different prop sets for internal attributes and the ones visible in ADUC. - Exchange would not mess the builtin prop sets, but would add its own, that would use a Ex prefix. - The prop set would at least somewhat correspond to the tabs in ADUC. Yours, Sakari PS. I acknowledge that those wishes may also have some drawbacks, such if Exchange added its own prop sets, the existing accounts would need new ACEs. 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/
RE: [ActiveDir] [OnTopic] Active Directory Property Set Madness
I do understand - that's what documentation is for... But I tend to agree that documentation lacks in many places. However, you don't only need it for changs in Property Sets - you basically need it for any security change (or other critical change) you perform in AD which is out of the standard, e.g. changing the Default Security Descriptor or any other exising rights in AD. Especially the removal of rights can hurt, as you don't necessarily see it during an analysis (unless you know what you're looking for). So I'd certainly only go this way if you have a good change mgmt system and document ACL changes (incl. those in Property Sets). And yes, that can still hurt you down the road because people even forget they have this documentation or they don't keep it up-to-date. But that's true for any change, not just ACL related changes. Doesn't mean you should leave everything set to the default if the default is unacceptable to you. /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Donnerstag, 12. Mai 2005 02:32 To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] [OnTopic] Active Directory Property Set Madness 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
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, s 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,
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, s 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
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
RE: [ActiveDir] [OnTopic] Active Directory Property Set Madness
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
RE: [ActiveDir] [OnTopic] Active Directory Property Set Madness
I feel like I was told this once,
but I could be making it up in a sleepy haze ...
Yep, I can confirm, a
property set gets one ACE in the ACL. To show it, I simplified an ACL on an OU
to SYSTEM FC, ADMINS FC, and joe\joe Public Information. Here is the dsacls and
raw SDDL output[Wed
05/11/2005 18:41:28.38]G:\dsacls
OU=propset,OU=TestOU,DC=joe,DC=comAccess list:{This object is protected
from inheriting permissions from the parent}Effective Permissions on
this object are:Allow BUILTIN\Administrators FULL CONTROLAllow NT
AUTHORITY\SYSTEM FULL CONTROLPermissions
inherited to subobjects are:Inherited to all subobjectsAllow
BUILTIN\Administrators FULL CONTROLInherited to userAllow
JOE\joe
SPECIAL ACCESS for Public
Information
WRITE
PROPERTY
READ PROPERTYThe command completed successfully[Wed
05/11/2005 18:41:35.18]G:\adfind -default -f name=propset -sddc
ntsecuritydescriptorAdFind V01.26.00cpp Joe Richards ([EMAIL PROTECTED])
February 2005Using server: 2k3dc01.joe.comDirectory: Windows Server
2003Base DN:
DC=joe,DC=comdn:OU=propset,OU=TestOU,DC=joe,DC=comnTSecurityDescriptor:
[SDDL]
O:DAG:DUD:PAI(OA;CIIO;RPWP;e48d0154-bcf8-11d1-8702-00c04fb96050;bf967aba-0de6-11d0-a285-00aa003049e2;S-1-5-21-1862701446-4008382571-2198042679-1680)(A;CI;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)S:AI(OU;CIIDSA;WP;f30e3bbe-9ff0-11d1-b603-f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)(OU;CIIDSA;WP;f30e3bbf-9ff0-11d1-b603-f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)nTSecurityDescriptor:
[OWNER] O:DAnTSecurityDescriptor: [GROUP]
G:DUnTSecurityDescriptor: [DACL]
D:PAI(OA;CIIO;RPWP;e48d0154-bcf8-11d1-8702-00c04fb96050;bf967aba-0de6-11d0-a285-00aa003049e2;S-1-5-21-1862701446-4008382571-2198042679-1680)(A;CI;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)nTSecurityDescriptor:
[SACL]
S:AI(OU;CIIDSA;WP;f30e3bbe-9ff0-11d1-b603-f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)(OU;CIIDSA;WP;f30e3bbf-9ff0-11d1-b603-f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)1
Objects returned[Wed 05/11/2005
18:41:56.82]G:\You will obviously
note the Admin ACE ((A;CI;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)) and
System ACE ((A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)) leaving
the ACE ((OA;CIIO;RPWP;e48d0154-bcf8-11d1-8702-00c04fb96050;bf967aba-0de6-11d0-a285-00aa003049e2;S-1-5-21-1862701446-4008382571-2198042679-1680))
as the ACE for joe\joe WP RP Public Information. You can see the rightsGuid for
Public Information as well as the schemaIDGuid for user.
Whether or not something
is happening in the actual DIT with that I can't obviously say, but I would
expect that raw binary is as it is in the DIT and adfind is displaying it.
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?
I understand what you are
saying here but this is the world we live in rightnow due to having two
mechanisms to assign permissions to the attributes. What is the state of the
Public Information property set if you apply one or moreACEs
forattributes that are normally inthe Public Information property
set. What if you deny one or more of theattributes. How does that
getdisplayed? Answer? It doesn't, it is assumed by all of the tools that
you know what the property sets include and you work from there.
This
assumptionprobably is not a good thing because then people often don't
know what they are delegating since I would say a good majority of the
ADAdmins don't knowhow to list property set members. This results in
too much delegation or duplicate delegation where duplicate delegation is
someone delegating the property set and then several of the attributes again
separately. I have seen this on multiple occasions in many different sized
directories and as recently as today.
In other words, if you had
p a1
a2a3 a4a5a6 a7a8
==
p1 x
x x x
p2
x
xxx
p3 x
x
x x
and you set WP for p1 I wouldNOT expect anything
to show for p2 and p3 just like nothing would be shown for p1 if you set WP on
a1-a4 individually. If I look at the GUI security dialog for the above ACL and
look at what is listed for joe\joe, I simply see WP RP Public Information, I
don't see all of the properties lit up. As for the effective permissions tab,
that thing is a riot, I have seen more things wrong in that than right. If I
display it for joe\joe on the above object it actually shows full control on
that object and it clearly doesn't as joe\joe isn't a member of anything by
domain users.
All of the GUI security tools and even the command line
ones don't do a great job of relating which people have access to what. The
confidentiality bit adds even more to it such that I ended up sending a note to
Dmitri and ~Eric the other day asking if it was feasible to do something around
it and the responses were of the "Unfortunately" type. I understood the
