Yes the tools are not quite what they could be. A lot of this is based on the complexity of the subject. The model is quite cool but it is also quite complex and getting more so. Look at the confidential attribute hack and the extended rights for protecting userAccountControl (Update Password Not Required Bit, etc).
When you take into account all of the special rules in the DIT (usually around SAM attributes) which conflict with schema definitions as well as the special cases of ACLing like the confidentiality bit and the userAccountControl "modifiers" etc, the inheritence model it is very difficult to write one tool to handle all of the various cases to tell you what you have and to help you get to what you want. An additional difficulty is that Microsoft isn't quick with updating tools to handle new features. Now third parties get into this realm and start playing but for many people that just pisses them off and makes them say... Hey Microsoft should already be supplying this, I'm not buying something. That combined with the fact that just maybe MSFT will realize they should correct this will tend to kill most third party folks from even going into that realm. Oh another additional complexity and LDP actually exposes this. You could create a tool that could build any kind of ACL you want without making any judgements on what is being done so that at a later time if something changes the tool doesn't have to be corrected. However, there are few people who understand how ACLs really work and are configured to the point that the tool would really be useful to any large number of people. Something we recommended previously to MSFT is that we need to radically update the ACL dialog editors for ADUC, etc so that they have an easy mode and an advanced mode for those who really understand what they are doing. The challenge to MSFT is to work out the easy mode, you don't want it too simply and ineffective and the advanced you still have to be careful with because there are a lot of people out there who think they are advanced security/AD people and they really don't have enough of a clue other than to really hurt themselves. But yes, every MSFT security tool out there has some shortcoming in it. The new LDP is the most flexible and has the most capability but as you have found, there are some bugs in it. We have reported those bugs, hopefully they will be corrected. The issue then becomes one of release. More than likely I expect we wouldn't see something before Longhorn and maybe not even before Longhorn R2. I hope that isn't the case, but expect it will be Longhorn timeframe. So the question comes down to are people willing to spend $1000 or $2000 or $5000 or more on tools to manage the ACLing in their directory? If so, third party tools are the answer. I am aware of a couple of tools that do things in this area, BindView (BVAdmin/BVControl) and Active Roles. However again, usually people immediately start talking about costs and the fact that MSFT should be supplying the tools to do this. I am not arguing the point, but that is where we are at at the moment. I will say this, writing c code around ACLing is not trivial. From what I understand the NET 2.0 framework is alleged to make this much easier. Usually easier means less flexibility and builtin assumptions but I don't know enough about it to speak to it for the NET Framework. As a sidenote... I just this second received an email from the developer working on LDP and can say that he is digging into this. I can't say much more than that though. joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matheesha Weerasinghe Sent: Monday, July 24, 2006 11:32 AM To: [email protected] Subject: Re: [ActiveDir] ldp in ADAM-SP1 I dunno about you guys but I am very disappointed with the tools available to me for configuring perms. dsacls can configure most perms but cant configure control access rights to certain attribs of certain objects. (e.g. when you configure an attribute as confidential and need to allow certain people the control access right to view the attribute). dsacls also cant display perms that great and gives details as "special access". In order to see whats special, I have to use something like acldiag and sdcheck. And then to revoke, yet another tool dsrevoke which only works on domain objects and OUs. After reading joe's book I figured ldp.exe from ADAM-SP1, here I come. Now that also has issues. I know I can write scripts for handling this. But they are cumbersome and slow. I think a nice fast C++ tool that does all this would be much appreciated. I am not sure how hard this is to do. But MSFT certaintly have the expertise. May be longhorn will ship with something like that. But I aint holding my breath. I am no expert and no MVP. I aint convinced my rant is gonna be heeded to. But please, guys out there with the influence (MVPs) help!! M@ P.S Please!!! On 7/24/06, joe <[EMAIL PROTECTED]> wrote: > Beautiful, this is bug week.... > > There are actually two bugs here. > > 1. The inherit only check box is greyed out. This is the checkbox you would > need to check in order to specify an inherit only ACE (i.e. Child Objects > Only). > > 2. When you try to work around it and specify the actual object types to > inherit to it creates two ACEs instead of one. The first ACE is the FC > inherit only to the object class you specify but then there is also a FC to > the object itself. In the example below note the TEST\joe ACEs... I only > added a single FC for nTDSConnection objects for test\joe but got that AND > the non-inheritable Test\joe FC on the object itself. > > > G:\>dsacls "\\r2dc1\CN=NTDS > Settings,CN=R2DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configur > ation,DC=test,DC=loc" > Access list: > Effective Permissions on this object are: > Allow TEST\joe FULL CONTROL > Allow TEST\Domain Admins SPECIAL ACCESS > DELETE > READ PERMISSONS > WRITE PERMISSIONS > CHANGE OWNERSHIP > CREATE CHILD > LIST CONTENTS > WRITE SELF > WRITE PROPERTY > READ PROPERTY > DELETE TREE > LIST OBJECT > CONTROL ACCESS > Allow NT AUTHORITY\Authenticated Users SPECIAL ACCESS > READ PERMISSONS > LIST CONTENTS > READ PROPERTY > LIST OBJECT > Allow NT AUTHORITY\SYSTEM FULL CONTROL > Allow TEST\Domain Admins FULL CONTROL <Inherited from > parent> > Allow TEST\Enterprise Admins FULL CONTROL <Inherited from > parent> > > Permissions inherited to subobjects are: > Inherited to all subobjects > Allow TEST\Domain Admins FULL CONTROL <Inherited from > parent> > Allow TEST\Enterprise Admins FULL CONTROL <Inherited from > parent> > > Inherited to nTDSConnection > Allow TEST\joe FULL CONTROL > The command completed successfully > > > > So in order to generate a generic FC that is only inherited, you can't, > because of bug 1 do it with LDP. If you want to create an ACE for a specific > objectclass (which nTDSConnection should be ok in terms of what you are > trying to delegate) it can do it but you have to go back and clean up the > the additional ACE created by bug 2. > > > I will alert MSFT. > > joe > > > > > -- > O'Reilly Active Directory Third Edition - > http://www.joeware.net/win/ad3e.htm > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Matheesha > Weerasinghe > Sent: Monday, July 24, 2006 8:12 AM > To: [email protected] > Subject: [ActiveDir] ldp in ADAM-SP1 > > All > > Could someone with more experience with ldp provided with ADAM-SP1 > tell me how I would go about configuring inherit-only Full Control > permissions on nTDSDSA objects in the > CN=Sites,CN=Configuration,DC=ForestFQDN ? The inherit-only perms > options is grayed out here and I dont know how to do it. > > Based on joe's comments I assumed the ldp.exe's ACL editor is the most > comprehensive and capable ACL gui editor available. I must be doing > something wrong here so I would appreciate some help. > > Regards > > M@ > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: http://www.activedir.org/ml/threads.aspx > > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: http://www.activedir.org/ml/threads.aspx > List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx
