| Author | Messages | |
matheesha
Posts:34
 | | 07/24/2006 12:11 PM |
| 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 | | | |
| listmail
Posts:824
| | 07/24/2006 2:10 AM |
| 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
Allow TEST\Enterprise Admins FULL CONTROL
Permissions inherited to subobjects are:
Inherited to all subobjects
Allow TEST\Domain Admins FULL CONTROL
Allow TEST\Enterprise Admins FULL CONTROL
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Matheesha
Weerasinghe
Sent: Monday, July 24, 2006 8:12 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
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 | | | |
| matheesha
Posts:34
| | 07/24/2006 3:32 AM |
| 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 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
Allow TEST\Enterprise Admins FULL CONTROL
Permissions inherited to subobjects are:
Inherited to all subobjects
Allow TEST\Domain Admins FULL CONTROL
Allow TEST\Enterprise Admins FULL CONTROL
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Matheesha
Weerasinghe
Sent: Monday, July 24, 2006 8:12 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
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 | | | |
| listmail
Posts:824
| | 07/24/2006 5:00 AM |
| 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Matheesha
Weerasinghe
Sent: Monday, July 24, 2006 11:32 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
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 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 parent>
> Allow TEST\Enterprise Admins FULL CONTROL parent>
>
> Permissions inherited to subobjects are:
> Inherited to all subobjects
> Allow TEST\Domain Admins FULL CONTROL parent>
> Allow TEST\Enterprise Admins FULL CONTROL 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Matheesha
> Weerasinghe
> Sent: Monday, July 24, 2006 8:12 AM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> 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 | | | |
| matheesha
Posts:34
| | 07/24/2006 6:02 AM |
| Joe
joe I see you were configuring Full Control (GA) for nTDSConnection
objects by configuring perms on the parent nTDSDSA object. I was
trying to actually configure full control to the nTDSDSA using perms
on the CN=Sites object but the principal is the same I guess. The only
thing is nTDSConnection objects cant have child objects can they?
Still I am having some issues repro'ing. You said your workaround was
to configure on the object types. Did you mean to configure explicitly
on the object or on the parent with the child's object type specified
in the ACE? I cant repro here and I am not sure whether you used
dsacls or ldp to repro.
And why does it not choose the "Access System Security" option when
you edit a Full Control ACE? Is that expected? I thought full control
meant everything. Not everything but "Access System Security".
Also how come there is no string defined for "Access System Security"?
There is for all other access masks.
I freely admit I know very little in this arena. Any lesson offered is
most appreciated. I am already reading technet and many books by the
fine guys on here. I just havent finished them yet ;-)
Thanks to everyone who's read this so far and for all the help I am
offered. I truly appreciate it.
Sincerely
M@
On 7/24/06, joe 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
Allow TEST\Enterprise Admins FULL CONTROL
Permissions inherited to subobjects are:
Inherited to all subobjects
Allow TEST\Domain Admins FULL CONTROL
Allow TEST\Enterprise Admins FULL CONTROL
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Matheesha
Weerasinghe
Sent: Monday, July 24, 2006 8:12 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
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 | | | |
| listmail
Posts:824
| | 07/24/2006 8:41 AM |
| Yeah what I was doing was setting a FC ACE for connection objects only. If
you want to cover multiple objects for this you would need to specify
multiple objectclasses which would result in multiple ACEs which is not a
good option. Which means, use a different tool as the bugs in the current
version of LDP make that difficult for this specific task. In my tests, I
was specifically using LDP from ADAM SP1. But for what you want to do, use
ADUC or DSACLS.
As an aside, I emailed Matheesha directly a little while ago when my first
email was lost in limbo waiting to be sent out by the list. A version of LDP
that doesn't have this issue should be in Longhorn when it is released. The
developer quickly fixed the first bug I mentioned this morning after I
pinged him and it seems the second bug had already been corrected. This
folks is the power of this list.... Take note.
I am not entirely positive what the "Access system security" is supposed to
be... This is not an issue in later versions of LDP...
I would say read the chapters on security in the AD book, then if you don't
have it, get and read Sakari's book as that has a great chapter on AD
security and then finally if you still want to learn more, wander into the
MSDN library and start reading about Security Descriptors, Access Control
Lists, and Access Control Entries. Once you understand the structures and
how they are represented a lot of the security stuff starts making more and
more sense.
joe
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Matheesha
Weerasinghe
Sent: Monday, July 24, 2006 2:03 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] ldp in ADAM-SP1
Joe
joe I see you were configuring Full Control (GA) for nTDSConnection
objects by configuring perms on the parent nTDSDSA object. I was
trying to actually configure full control to the nTDSDSA using perms
on the CN=Sites object but the principal is the same I guess. The only
thing is nTDSConnection objects cant have child objects can they?
Still I am having some issues repro'ing. You said your workaround was
to configure on the object types. Did you mean to configure explicitly
on the object or on the parent with the child's object type specified
in the ACE? I cant repro here and I am not sure whether you used
dsacls or ldp to repro.
And why does it not choose the "Access System Security" option when
you edit a Full Control ACE? Is that expected? I thought full control
meant everything. Not everything but "Access System Security".
Also how come there is no string defined for "Access System Security"?
There is for all other access masks.
I freely admit I know very little in this arena. Any lesson offered is
most appreciated. I am already reading technet and many books by the
fine guys on here. I just havent finished them yet ;-)
Thanks to everyone who's read this so far and for all the help I am
offered. I truly appreciate it.
Sincerely
M@
On 7/24/06, joe 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 parent>
> Allow TEST\Enterprise Admins FULL CONTROL parent>
>
> Permissions inherited to subobjects are:
> Inherited to all subobjects
> Allow TEST\Domain Admins FULL CONTROL parent>
> Allow TEST\Enterprise Admins FULL CONTROL 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Matheesha
> Weerasinghe
> Sent: Monday, July 24, 2006 8:12 AM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> 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 | | | |
| dmitrig@xxxx.yyy
| | 07/24/2006 9:57 AM |
| Re "Access System Security" checkbox. We removed it from the latest
versions of ldp.exe because it does not do what you want. Even if you
grant this right to some principal, he will still be unable to read or
tweak the SACLs. The only way to be able to do this is to grant
SE_ACCESS_SYSTEM_SECURITY privilege. You do this from gpedit.msc
(security settings/User rights assignments).
On a more general note -- yes, AD security is a mess to manage and to
understand. We are trying to improve it, but it is super super difficult
task. Not only the rules are difficult to understand and are numerous,
but also we need to respect the existing security setups which use weird
ACLs. There were several attempts to improve things, but I don't believe
we are getting closer, mostly due to backward compatibility issues, as
well as due to the need to introduce new rules (such as confidentiality
bit and many new control access rights).
BTW, the Delegation Wizard is considered to be the "entry-level" ACLing
tool. Alas, it does not work for ADAM.
Dmitri
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of joe
Sent: Monday, July 24, 2006 1:42 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] ldp in ADAM-SP1
Yeah what I was doing was setting a FC ACE for connection objects only.
If you want to cover multiple objects for this you would need to specify
multiple objectclasses which would result in multiple ACEs which is not
a good option. Which means, use a different tool as the bugs in the
current version of LDP make that difficult for this specific task. In my
tests, I was specifically using LDP from ADAM SP1. But for what you want
to do, use ADUC or DSACLS.
As an aside, I emailed Matheesha directly a little while ago when my
first email was lost in limbo waiting to be sent out by the list. A
version of LDP that doesn't have this issue should be in Longhorn when
it is released. The developer quickly fixed the first bug I mentioned
this morning after I pinged him and it seems the second bug had already
been corrected. This folks is the power of this list.... Take note.
I am not entirely positive what the "Access system security" is supposed
to be... This is not an issue in later versions of LDP...
I would say read the chapters on security in the AD book, then if you
don't have it, get and read Sakari's book as that has a great chapter on
AD security and then finally if you still want to learn more, wander
into the MSDN library and start reading about Security Descriptors,
Access Control Lists, and Access Control Entries. Once you understand
the structures and how they are represented a lot of the security stuff
starts making more and more sense.
joe
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Matheesha
Weerasinghe
Sent: Monday, July 24, 2006 2:03 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] ldp in ADAM-SP1
Joe
joe I see you were configuring Full Control (GA) for nTDSConnection
objects by configuring perms on the parent nTDSDSA object. I was trying
to actually configure full control to the nTDSDSA using perms on the
CN=Sites object but the principal is the same I guess. The only thing is
nTDSConnection objects cant have child objects can they?
Still I am having some issues repro'ing. You said your workaround was to
configure on the object types. Did you mean to configure explicitly on
the object or on the parent with the child's object type specified in
the ACE? I cant repro here and I am not sure whether you used dsacls or
ldp to repro.
And why does it not choose the "Access System Security" option when you
edit a Full Control ACE? Is that expected? I thought full control meant
everything. Not everything but "Access System Security".
Also how come there is no string defined for "Access System Security"?
There is for all other access masks.
I freely admit I know very little in this arena. Any lesson offered is
most appreciated. I am already reading technet and many books by the
fine guys on here. I just havent finished them yet ;-)
Thanks to everyone who's read this so far and for all the help I am
offered. I truly appreciate it.
Sincerely
M@
On 7/24/06, joe 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=Conf
igur
> 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 parent>
> Allow TEST\Enterprise Admins FULL CONTROL parent>
>
> Permissions inherited to subobjects are:
> Inherited to all subobjects
> Allow TEST\Domain Admins FULL CONTROL parent>
> Allow TEST\Enterprise Admins FULL CONTROL 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Matheesha
> Weerasinghe
> Sent: Monday, July 24, 2006 8:12 AM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> 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
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 | | | |
| amulnick
Posts:163
| | 07/25/2006 1:18 AM |
| "The tricky bit is the matching a trusted andappropriately skilled person to the relevant role." That makes me laugh and cringe at the same time. Yes, it is very difficult to find that "perfect match" but at the same time I think a design should take that into account where possible. That's a design philosophy and I won't debate that for this thread. But I would caution you that any design that has the people intricately relied upon is going to have a failure point at some point when you least can tolerate it.
While you can use the command line tools as much as possible, as joe and Guido both pointed out, consider rolling your own scripts if you absolutely cannot do what you *need* to do at the GUI. But remember you can really really really^^ hurt yourself with security permissions. Believe me, it can be ugly and it can be the undoing.
Two thoughts consider as you walk through the design:
1) You should never try to solve wetware issues with software or hardware.
2) Complexity is the anti-security.
Best of luck.
On 7/25/06, Matheesha Weerasinghe wrote:
Wow,Thanks you so much for the detailed info guys. Basically my goal isquite simple. At least it is in my head. What I want to do, is to go
through the entire case study given in the AD delegation whitepaper,and do all of that permissions configuration entirely at command line(where possible). I am willing to use the delegation wizard to someextent, but as I am configuring quite a lot of permissions for an AD
design I am involved in, I would rather avoid having to use GUI toolsfor this.You see, I am going to end up as been a very privileged serviceadministrator and data administrator once my proposed AD design model
is in place. I expect I will be making some endeavour to trainsufficiently capable people in doing this. But I dont plan to spoonfeed. I want the guys to know to a decent level ACL'ing and if not, dotheir research. At least on an adhoc basis. Then once they understand
whats involved, they can go ahead and add/modify/delete ACE's , revokeperms, define new roles etc...Reading this delegation doc has made me believe I can configure anextremely secure delegation model where each role can be given just
enough to do that role. The tricky bit is the matching a trusted andappropriately skilled person to the relevant role.So you see, as there is a lot involved and this is a biginfrastructure to attempt to administer perms for 20,000 users plus
many OUs used to organise users based on the business unit (at least adozen in each geographical hub) they work in and the site (we havemore than a 40 geographical hubs and 1000 satellite sites) they arelocated at. Different levels of data admin roles. I would like to get
this right to a large extent from the moment go. Admittedly it may notbe big as in Fortune 5 ADs. But its the biggest I've had the privilegeto design and support.I figured if I test this using the case study as a lab, I will get a
good feel of whats involved in my lower level design. I am getting alittle miffed when I have to swap between several tools to do what Ineed to do. There is just so many buts and ifs. "You can do this but
you cant do this. To do this use this. For this use that. And thentry this. If all else fails script ...."I admit I was ranting a bit when asking why is this named and likesuch and the discrepencies in the docs and syntax help of command line
tools. My sincere apologies for been anal.Is it too much to ask, to have at the very least a reliable commandline or GUI tool (ldp) to configure perms just the way I want andneed? Actually I don care even if I have to use a series of command
line apps. I dont care how complex it is/willbe right now. I just wantsomething that works. And I want the tool from MSFT. For free ;0)Please!CheersM@P.S. thanks once again for reading, for escalating, for laughing, for
educating , the kind words, hugsControl-H,Control-H,Control-H,Control-H,Control-H, etc...On 7/25/06, Grillenmeier, Guido wrote:> I guess Matheesha's original question has been answered as good as it> can for now with the information given. I just quickly want to comment> on the 3rd party tool aspect joe is mentioning below - naturally, before
> spending considerable money on the tools, you'd need to test if they do> what you want them to do in the first place.>> What I've found from many years of leveraging and checking different
> ACLing tools is that they also just go so far... I've had various> different customer requests, which could not be achieved with the tools,> but could be achieved with the native ACLs (mostly talking AD here).
> After getting over the hurdles of the basics, scripting quickly becomes> your friend. I am not saying that 3rd party tools aren't quite useful> for general ACLing stuff - it's when your own security model is complex,
> the tools will often not be able to help you reach your goal.>> Often this is a result of the complex ACLing rules build by MSFT> themselves. Very hard for a developer to keep up with all changes (think
> of all the changes in Win2003 compared to 2000 and then with Win2003> SP1) and to understand the plethora of rules, especially when it comes> to combining specific ACLing settings set at totally different places in
> the directory. A great example for this are various options to> controlling delegation of password settings (I've written this up> internally and for my upcoming Windows security book, as joe had been
> pointed at in his other reply). Win2003 provides three new not so well> known extended rights, which allow domain admins to control which> delegated admin can change critical password attributes on user
> accounts:>> * Enable-Per-User-Reversibly-Encrypted-Password> * Unexpire-Password> * Update-Password-Not-Required-Bit>> The challenge: these extended rights are set at the domain level, while
> other permissions to control which delegated admin can do what in an OU> (e.g. create and manage users) are typically set at the OU level. So if> you give a delegated admin full control over users, he would for example
> not be able to set the "Password never expires" and the "Store password> using reversible encryption" options on the user accounts he is allowed> to fully control, UNLESS he is ALSO granted the appropriate extended
> right at the root of your domain ("Unexpire-Password" and> "Enable-Per-User-Reversibly-Encrypted-Password" in this example).>> This is certainly challenging for any domain admininstrator and moreso
> for 3rd party ACLing tools. Realize that by default the three extended> rights I have mentioned above are granted to Authenticated Users, which> means that any delegated admin who is also granted the rights to control
> the account restrictions of a user can set the respective password> options. As these are rather sensible settings though, I'd rather> disable any delegated admin from setting them (which is why the extended
> rights have been added to Win2003 in the first place). If you have> different admins allowed to create users, just check out your domains> and see how many users are configured with the "password never expires"
> flag - you will quickly understand what I mean.>> But again: it is very tough for 3rd party tools to remove default rights> for you => they usually just handle adding permissions and it is up to
> you to fully understand the ACLing concepts of Windows to make> everything work correctly.>> /Guido>>> -----Original Message-----> From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of joe> Sent: Monday, July 24, 2006 7:00 PM> To:
ActiveDir@xxxxxxxxxxxxxxxxxx> Subject: RE: [ActiveDir] ldp in ADAM-SP1>> 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx> [mailto:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Matheesha> Weerasinghe> Sent: Monday, July 24, 2006 11:32 AM> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> 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 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=Conf> igur> > 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 > parent>> > Allow TEST\Enterprise Admins FULL CONTROL > parent>
> >> > Permissions inherited to subobjects are:> > Inherited to all subobjects> > Allow TEST\Domain Admins FULL CONTROL > parent>
> > Allow TEST\Enterprise Admins FULL CONTROL > 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:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx> > [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Matheesha> > Weerasinghe> > Sent: Monday, July 24, 2006 8:12 AM
> > To: ActiveDir@xxxxxxxxxxxxxxxxxx> > 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> 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.aspxList FAQ : http://www.activedir.org/ListFAQ.aspxList archive: http://www.activedir.org/ml/threads.aspx | | | |
| GuidoG
Posts:114
| | 07/25/2006 1:22 AM |
| well, for Win2000 and Win2003 AD that tool is DSACLS for 95% of what you
should need to do. You've already tripped over some of it's limitations
especially around handling the confidential bit - however, I have not
seen many customers that actually leverage the confidential bit yet for
anything else but OS features (for example for PKI credential roaming).
It would be nice to leverage it for many more lockdown scenarios, but
you can't use it for the base schema attributes (category 1), which
includes almost all of the interesting attributes you may want to
restrict access to. Ofcourse you can use it for your own schema
extensions.
For file-system ACLing that tool is CALS or XCACLS - probably for 99% of
what you need to do. Note for the FS you may also want to check out the
betas of either Windows Longhorn or the current Windows 2003 SP2 => they
include a new commandline ACLing tool called Icacls.exe, which can be
used to reset the account control lists (ACL) on files from Recovery
Console, and to back up ACLs. It can also handle replacement of ACLs
(much like subinacl) and works well with either names or SIDs. At last,
unlike Cacls.exe, Icacles.exe preserves canonical ordering of ACEs and
thus correctly propagates changes to and creation of inherited ACLs.
DSACLs has only been updated slightly in LH, but I hope to see some more
changes prior to beta 3.
At last, depending on your requirements, you may also need to look into
changing the default security descriptor of some of the objects (for
example, check out all the default write permissions, which every user
is granted on it's own object via the SELF security principal; many
companies are still unaware of this). You can check these rights most
easily via the schema mgmt mmc (check properties of a class object, such
as user and click on the Default Security tab).
So it's fair to say that although handling ACLs remains to be a complex
topic, you can get most of the things done with existing commandline
tools from MSFT. Sometimes it will simply be more appropriate to use the
UI for a few settings. And there is always the option to script setting
ACLs if you really have special requirements.
As for your delegation model => I would not have the goal to teach your
delegated admins how to do ACLing inside AD. I'm fine with a delegated
admin doing the security on a file-server that he completely manages on
his own. But AD security should be kept in the hand of domain and
enterprise admins (partly because it is rather complex and you only want
few folks to fiddle around with it, partly because it is plain risky to
do it otherwise). The critical piece for most delegation models to
succeed is to build a centrally controlled OU structure (ideally
standardized for your different delegated "admin units" as I like to
call them and not to grant your data admin (= the delegated admins) any
rights to create OUs themselves (otherwise - with the current ACLing
model - you can't prevent them to configure the security of the OU).
Basically the same is true for any objects they create, but it's the OUs
that allow you to manage the security for multiple child objects at once
(and thus these need to be controlled centrally). Many more things to
share in this respect, but no delegation model is the same as any other
so you're best to understand and plan it from the ground up. There may
be similarities between many models, but for the various infrastructures
I've planned, every customer has had their special requirements.
/Guido
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Matheesha
Weerasinghe
Sent: Tuesday, July 25, 2006 9:34 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] ldp in ADAM-SP1
Wow,
Thanks you so much for the detailed info guys. Basically my goal is
quite simple. At least it is in my head. What I want to do, is to go
through the entire case study given in the AD delegation whitepaper,
and do all of that permissions configuration entirely at command line
(where possible). I am willing to use the delegation wizard to some
extent, but as I am configuring quite a lot of permissions for an AD
design I am involved in, I would rather avoid having to use GUI tools
for this.
You see, I am going to end up as been a very privileged service
administrator and data administrator once my proposed AD design model
is in place. I expect I will be making some endeavour to train
sufficiently capable people in doing this. But I dont plan to spoon
feed. I want the guys to know to a decent level ACL'ing and if not, do
their research. At least on an adhoc basis. Then once they understand
whats involved, they can go ahead and add/modify/delete ACE's , revoke
perms, define new roles etc...
Reading this delegation doc has made me believe I can configure an
extremely secure delegation model where each role can be given just
enough to do that role. The tricky bit is the matching a trusted and
appropriately skilled person to the relevant role.
So you see, as there is a lot involved and this is a big
infrastructure to attempt to administer perms for 20,000 users plus
many OUs used to organise users based on the business unit (at least a
dozen in each geographical hub) they work in and the site (we have
more than a 40 geographical hubs and 1000 satellite sites) they are
located at. Different levels of data admin roles. I would like to get
this right to a large extent from the moment go. Admittedly it may not
be big as in Fortune 5 ADs. But its the biggest I've had the privilege
to design and support.
I figured if I test this using the case study as a lab, I will get a
good feel of whats involved in my lower level design. I am getting a
little miffed when I have to swap between several tools to do what I
need to do. There is just so many buts and ifs. "You can do this but
you cant do this. To do this use this. For this use that. And then
try this. If all else fails script ...."
I admit I was ranting a bit when asking why is this named and like
such and the discrepencies in the docs and syntax help of command line
tools. My sincere apologies for been anal.
Is it too much to ask, to have at the very least a reliable command
line or GUI tool (ldp) to configure perms just the way I want and
need? Actually I don care even if I have to use a series of command
line apps. I dont care how complex it is/willbe right now. I just want
something that works. And I want the tool from MSFT. For free ;0)
Please!
Cheers
M@
P.S. thanks once again for reading, for escalating, for laughing, for
educating , the kind words, hugs
Control-H,Control-H,Control-H,Control-H,Control-H, etc...
On 7/25/06, Grillenmeier, Guido wrote:
> I guess Matheesha's original question has been answered as good as it
> can for now with the information given. I just quickly want to comment
> on the 3rd party tool aspect joe is mentioning below - naturally,
before
> spending considerable money on the tools, you'd need to test if they
do
> what you want them to do in the first place.
>
> What I've found from many years of leveraging and checking different
> ACLing tools is that they also just go so far... I've had various
> different customer requests, which could not be achieved with the
tools,
> but could be achieved with the native ACLs (mostly talking AD here).
> After getting over the hurdles of the basics, scripting quickly
becomes
> your friend. I am not saying that 3rd party tools aren't quite useful
> for general ACLing stuff - it's when your own security model is
complex,
> the tools will often not be able to help you reach your goal.
>
> Often this is a result of the complex ACLing rules build by MSFT
> themselves. Very hard for a developer to keep up with all changes
(think
> of all the changes in Win2003 compared to 2000 and then with Win2003
> SP1) and to understand the plethora of rules, especially when it comes
> to combining specific ACLing settings set at totally different places
in
> the directory. A great example for this are various options to
> controlling delegation of password settings (I've written this up
> internally and for my upcoming Windows security book, as joe had been
> pointed at in his other reply). Win2003 provides three new not so well
> known extended rights, which allow domain admins to control which
> delegated admin can change critical password attributes on user
> accounts:
>
> * Enable-Per-User-Reversibly-Encrypted-Password
> * Unexpire-Password
> * Update-Password-Not-Required-Bit
>
> The challenge: these extended rights are set at the domain level,
while
> other permissions to control which delegated admin can do what in an
OU
> (e.g. create and manage users) are typically set at the OU level. So
if
> you give a delegated admin full control over users, he would for
example
> not be able to set the "Password never expires" and the "Store
password
> using reversible encryption" options on the user accounts he is
allowed
> to fully control, UNLESS he is ALSO granted the appropriate extended
> right at the root of your domain ("Unexpire-Password" and
> "Enable-Per-User-Reversibly-Encrypted-Password" in this example).
>
> This is certainly challenging for any domain admininstrator and moreso
> for 3rd party ACLing tools. Realize that by default the three extended
> rights I have mentioned above are granted to Authenticated Users,
which
> means that any delegated admin who is also granted the rights to
control
> the account restrictions of a user can set the respective password
> options. As these are rather sensible settings though, I'd rather
> disable any delegated admin from setting them (which is why the
extended
> rights have been added to Win2003 in the first place). If you have
> different admins allowed to create users, just check out your domains
> and see how many users are configured with the "password never
expires"
> flag - you will quickly understand what I mean.
>
> But again: it is very tough for 3rd party tools to remove default
rights
> for you => they usually just handle adding permissions and it is up to
> you to fully understand the ACLing concepts of Windows to make
> everything work correctly.
>
> /Guido
>
>
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of joe
> Sent: Monday, July 24, 2006 7:00 PM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> Subject: RE: [ActiveDir] ldp in ADAM-SP1
>
> 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Matheesha
> Weerasinghe
> Sent: Monday, July 24, 2006 11:32 AM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> 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 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=Conf
> igur
> > 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 > parent>
> > Allow TEST\Enterprise Admins FULL CONTROL > parent>
> >
> > Permissions inherited to subobjects are:
> > Inherited to all subobjects
> > Allow TEST\Domain Admins FULL CONTROL > parent>
> > Allow TEST\Enterprise Admins FULL CONTROL > 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> > [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Matheesha
> > Weerasinghe
> > Sent: Monday, July 24, 2006 8:12 AM
> > To: ActiveDir@xxxxxxxxxxxxxxxxxx
> > 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
> 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 | | | |
| amulnick
Posts:163
| | 07/25/2006 1:27 AM |
| A QFE for Longhorn? You're making the assumption that the fix is backported. It may not be.
I think that would be the first question to ask before asking to get a copy.
Al
On 7/24/06, Matheesha Weerasinghe wrote:
There is much in ldp I dont know. Everything I do know, I learned fromJohn Craddock's book and the understanding ldap whitepaper from MSFT.
Thanks for all the help so far joe and Dmitri . If I wanted to get myTAM to get the updated version of ldp as it stands, what QFE numbershould I quote?The more I look into this the more insane I get ;-) Why is the
Extended Right is defined with the string "SW" in the sddl format butdsacls uses "WS". Different access masks have different namesdepending on what I read. "Read permissions" in ldp is "Read Control"
in the docs. "Extended write" in ldp is "Write to self" in dsacls. Atleast thats how I understood it.I may have to make my own notes on this. If I ever have to read thisstuff and the delegation docs I am definitely going to go nuts.
Would it be fare to say we can do all we need definitely usingscripts? Or is that also not definite? You see, until recently I wasreading this delegation doc with a grin from ear-to-ear thinking yeah!And now I am not so ....
Before I break down and cry like Homer, I'm gonna go get some Zzzzzzzzzzzzzz!CheersM@On 7/24/06, Dmitri Gavrilov wrote:> Re "Access System Security" checkbox. We removed it from the latest> versions of ldp.exe because it does not do what you want. Even if you> grant this right to some principal, he will still be unable to read or
> tweak the SACLs. The only way to be able to do this is to grant> SE_ACCESS_SYSTEM_SECURITY privilege. You do this from gpedit.msc> (security settings/User rights assignments).>> On a more general note -- yes, AD security is a mess to manage and to
> understand. We are trying to improve it, but it is super super difficult> task. Not only the rules are difficult to understand and are numerous,> but also we need to respect the existing security setups which use weird
> ACLs. There were several attempts to improve things, but I don't believe> we are getting closer, mostly due to backward compatibility issues, as> well as due to the need to introduce new rules (such as confidentiality
> bit and many new control access rights).>> BTW, the Delegation Wizard is considered to be the "entry-level" ACLing> tool. Alas, it does not work for ADAM.>> Dmitri
>> -----Original Message-----> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx
] On Behalf Of joe> Sent: Monday, July 24, 2006 1:42 PM> To: ActiveDir@xxxxxxxxxxxxxxxxxx> Subject: RE: [ActiveDir] ldp in ADAM-SP1>> Yeah what I was doing was setting a FC ACE for connection objects only.
> If you want to cover multiple objects for this you would need to specify> multiple objectclasses which would result in multiple ACEs which is not> a good option. Which means, use a different tool as the bugs in the
> current version of LDP make that difficult for this specific task. In my> tests, I was specifically using LDP from ADAM SP1. But for what you want> to do, use ADUC or DSACLS.>> As an aside, I emailed Matheesha directly a little while ago when my
> first email was lost in limbo waiting to be sent out by the list. A> version of LDP that doesn't have this issue should be in Longhorn when> it is released. The developer quickly fixed the first bug I mentioned
> this morning after I pinged him and it seems the second bug had already> been corrected. This folks is the power of this list.... Take note.>> I am not entirely positive what the "Access system security" is supposed
> to be... This is not an issue in later versions of LDP...>> I would say read the chapters on security in the AD book, then if you> don't have it, get and read Sakari's book as that has a great chapter on
> AD security and then finally if you still want to learn more, wander> into the MSDN library and start reading about Security Descriptors,> Access Control Lists, and Access Control Entries. Once you understand
> the structures and how they are represented a lot of the security stuff> starts making more and more sense.>> joe>>> --> O'Reilly Active Directory Third Edition -
> http://www.joeware.net/win/ad3e.htm>>> -----Original Message-----> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Matheesha> Weerasinghe> Sent: Monday, July 24, 2006 2:03 PM> To:
ActiveDir@xxxxxxxxxxxxxxxxxx> Subject: Re: [ActiveDir] ldp in ADAM-SP1>> Joe>> joe I see you were configuring Full Control (GA) for nTDSConnection> objects by configuring perms on the parent nTDSDSA object. I was trying
> to actually configure full control to the nTDSDSA using perms on the> CN=Sites object but the principal is the same I guess. The only thing is> nTDSConnection objects cant have child objects can they?
> Still I am having some issues repro'ing. You said your workaround was to> configure on the object types. Did you mean to configure explicitly on> the object or on the parent with the child's object type specified in
> the ACE? I cant repro here and I am not sure whether you used dsacls or> ldp to repro.>> And why does it not choose the "Access System Security" option when you> edit a Full Control ACE? Is that expected? I thought full control meant
> everything. Not everything but "Access System Security".>> Also how come there is no string defined for "Access System Security"?> There is for all other access masks.
>> I freely admit I know very little in this arena. Any lesson offered is> most appreciated. I am already reading technet and many books by the> fine guys on here. I just havent finished them yet ;-)
>> Thanks to everyone who's read this so far and for all the help I am> offered. I truly appreciate it.>> Sincerely>> M@>>> On 7/24/06, joe 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=Conf> igur> > 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 > parent>> > Allow TEST\Enterprise Admins FULL CONTROL > parent>
> >> > Permissions inherited to subobjects are:> > Inherited to all subobjects> > Allow TEST\Domain Admins FULL CONTROL > parent>
> > Allow TEST\Enterprise Admins FULL CONTROL > 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:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx> > [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Matheesha> > Weerasinghe> > Sent: Monday, July 24, 2006 8:12 AM
> > To: ActiveDir@xxxxxxxxxxxxxxxxxx> > 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>> 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.aspxList FAQ : http://www.activedir.org/ListFAQ.aspxList archive: http://www.activedir.org/ml/threads.aspx | | | |
| listmail
Posts:824
| | 07/25/2006 2:46 AM |
| Al is correct. There is no QFE number at this
point.
The first step would be to present a solid business case
and then Microsoft would officially review it and determine if a QFE which would
mean an official pback port makes sense. A QFE is an official release and takes
some work to get done so there has to be good justification behind it. The more
I think about this, the tougher I think it would be to get a QFE for
LDP. But again if you have the business case, it might get
through.
So is this a case of simply wanting it or this is the only
way? From what I have heard it doesn't sound like this is the only way to go
forward but I am not sure if I know everything required.
What I see right now is
>
objects by configuring perms on the parent nTDSDSA object. I was trying >
to actually configure full control to the nTDSDSA using perms on the>
CN=Sites object but the principal is the same I guess. The only thing is>
nTDSConnection objects cant have child objects can they?
which doesn't really tell me what you are trying to do. Are
you trying to delegate the ability to manipulate connection objects or
ntdsdsa objects or what? If you are trying to just delegate those two pieces and
trying to do it from the sites level on down, you will have to use at a minimum
two ACEs, one for ntdsdsa objects and one for connection objects. Alternately
you will have to add an ACE at the ntdsdsa object level under every server and
every site.
Again, all of the ACL tools have different shortcomings,
there is no one tool that handles everything perfectly from MSFT at this point
in time and even LDP which is one of the more flexible tools after the mentioned
bug fixes is still going to fall short in people's eyes because the interface is
too low level for some people. This is where the next pieces comes into it on
terms and names comes in.
RE: terms and names and etc, yes, it is all over the map.
Asking questions of WHY is this named that and the same thing named something
else in another tool are going to feel good to ask but aren't likely to be
answered because it isn't constructive to answer those questions. Yes security
is tricky and messy and everyone understands that and attempts are being made to
make it better, but as Dmitri indicated and I indicated, it isn't easy. There
are a lot of special cases to take into account and trying to force one good
easy solution at this point has potential to break a lot of things which will
just instigate more WHY questions. Even from the start the flexibility built
into the ACLing model made it complex, it has only gotten more so as people
demanded more granularity and capability. I can say the same things about my
tools and they are ultra simple next to something like the permissioning model.
But as I or others pushed for more features and capability and I actually added
it complexity increased considerably to the point where I am at some point going
to release a whole new version of the tools based on a whole new code base or
framework. This is "easy" for me to do relative to Microsoft as my support base
is not even a rounding error to the MSFT support base and it still will be quite
hard.
So why is it SW in SDDL and WS in DSACLS? Answer:
because that is the way it is. :)
Read permissions could be stated as Read Permissions or
Read Properties or Read Control or just Read or circumflexuremititis whatever.
Why? See above.
The actual reason behind "because" could be lots of things
- it depends. You would need to talk to the developers of each component. I
expect it wasn't a mass conspiracy to confuse anyone. More likely it is actually
dev people trying to help others with maybe more descriptive terms or possibly
they didn't fully understand the thing themselves in the first place. As Dmitri
mentioned with the "Access system security", they put it in and found out later
things just didn't work the way they expected. Heck if they had asked me I could
have told them it doesn't work that way, it could break the security model
if it did. However I wasn't asked. On the contrary though, there are probably a
ton of other things I would have done wrong that I wasn't aware of because I
didn't have a chance to experience them. I got a chance to read something from
Guido recently on some ACL stuff and it completely stunned me and made me bang
my head on the desk for a little bit. It is a complex complex product and
complex complex security model. Though to be blunt, I don't think I have seen a
simple but flexible and granular security model yet that lends itself both to
easy programming and easy user comprehension.
At this point you have it easy, you are only looking at AD
permissions. Once you step out from that tiny little aspect of where this ACLing
is used you start to see all sorts of fun stuff where different bits mean
different things in ACLs for different objects and in some cases another
completely different mechanism was followed but using the same basic SDDL/SD
stuff. Of course here I am referring to the CUSTOMSD stuff they put in for K3
Event Log permissioning. The first time I saw that I was like, was someone on
crack??? They had a perfectly fine set of constants and flag values and these
gomers invented something completely different???? Why was it done? Probably
because either someone didn't understand how it was already handled or someone
thought it was too complex and was going to make it easier and simply added
complexity once they looked outside their little area.
My overriding recommendation to everyone and anyone who
ever plays with ACLs is to use the NORMAL GUI to assign what you want assigned
and then look at the RAW ACL and look at what really happened and ascertain if
it made sense. There are lots of times where the GUI will not produce the most
efficient ACL but it is a great start. Once you have looked at enough ACLs
you start to get a feel for what is and isn't needed and inefficiencies will
start sticking out to you as you build up the rule set in your own mind and just
start using it subconsciously.
I still dump ACLs and look at the raw values on a
regular basis to figure out how things work and if I need to automate the adding
of an ACE to something. The script I created for AD3E in the security chapter
which dumps a security ACL should give you great info for scripting the
modification/creation of ACLs because it specifically dumps out the values for
each field that end up getting set.
I love using DSACLS for looking at ACLs as well because it
is easier for more people to use than say my script and still produces very
useful output. I pretty much refuse to look at ACLs from the GUI anymore simply
because it is not the best way to look at it because you have to go in and look
at each item individually instead of looking at it all in one fell
swoop. That is the fault of the GUIs but I don't blame them much because
there is a lot of info and I can't visualize myself how to do it better at the
moment.
I guess a lot of this was to say beating on the ACLing
model is too easy of a fight. It is like going up to a horse and beating it and
saying you are brown, I am going to beat you. Everyone can see the horse is
brown and everyone would like to be able to fix that (well maybe, I might like a
brown horse, don't take analogies too far is the lesson here...) but some things
just aren't that easy to change no matter how much you want to or how much of a
pain it all is.
So don't give up,
don't go insane, just keep working through it and do it in baby steps. Get a
goal and work towards it, the goal cannot be, understand all about ACLs because
it is too big. Start smaller.
Also state here your actual goal you have for configuring
your ACLs in your sites area so someone can say.... whoa, that itsn't a
very good idea or tell you how to pull it off.
If you know the perfect way all of this could be handled,
do feel free to write the perfect script or tool to do it. Lots of people would
certainly like to have it but it may not sell well. Everyone wants the perfect
tool but they also want it to be free. :)
joe
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Al
MulnickSent: Monday, July 24, 2006 9:27 PMTo:
ActiveDir@xxxxxxxxxxxxxxxxxxSubject: Re: [ActiveDir] ldp in
ADAM-SP1
I think you can infer from the posts by Dmitri and joe that this is more
complex than you'd like to hear. That said, it might be more productive if
you post what you want to accomplish and see if somebody can help you
determine/navigate the way forward.
A QFE for Longhorn? You're making the assumption that the fix is
backported. It may not be.
I think that would be the first question to ask before asking to get a
copy.
Al
On 7/24/06, Matheesha
Weerasinghe matheesha@xxxxxxxxx> wrote:
There
is much in ldp I dont know. Everything I do know, I learned fromJohn
Craddock's book and the understanding ldap whitepaper from MSFT.
Thanks for all the help so far joe and Dmitri . If I wanted to get
myTAM to get the updated version of ldp as it stands, what QFE
numbershould I quote?The more I look into this the more insane I
get ;-) Why is the Extended Right is defined with the string "SW" in the
sddl format butdsacls uses "WS". Different access masks have different
namesdepending on what I read. "Read permissions" in ldp is
"Read Control" in the docs. "Extended write" in ldp is "Write to self" in
dsacls. Atleast thats how I understood it.I may have to make my
own notes on this. If I ever have to read thisstuff and the delegation
docs I am definitely going to go nuts. Would it be fare to say we can
do all we need definitely usingscripts? Or is that also not definite? You
see, until recently I wasreading this delegation doc with a grin from
ear-to-ear thinking yeah!And now I am not so .... Before I break
down and cry like Homer, I'm gonna go get some
Zzzzzzzzzzzzzz!CheersM@On 7/24/06, Dmitri Gavrilov
dmitrig@xxxxxxxxxxxxxxxxxxxxx
> wrote:> Re "Access System Security" checkbox. We removed it
from the latest> versions of ldp.exe because it does not do what you
want. Even if you> grant this right to some principal, he will still be
unable to read or > tweak the SACLs. The only way to be able to do this
is to grant> SE_ACCESS_SYSTEM_SECURITY privilege. You do this from
gpedit.msc> (security settings/User rights
assignments).>> On a more general note -- yes, AD security is a
mess to manage and to > understand. We are trying to improve it, but it
is super super difficult> task. Not only the rules are difficult to
understand and are numerous,> but also we need to respect the existing
security setups which use weird > ACLs. There were several attempts to
improve things, but I don't believe> we are getting closer, mostly due
to backward compatibility issues, as> well as due to the need to
introduce new rules (such as confidentiality > bit and many new control
access rights).>> BTW, the Delegation Wizard is considered to be
the "entry-level" ACLing> tool. Alas, it does not work for
ADAM.>> Dmitri>> -----Original
Message-----> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx>
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx
] On Behalf Of joe> Sent: Monday, July 24, 2006 1:42 PM> To:
ActiveDir@xxxxxxxxxxxxxxxxxx>
Subject: RE: [ActiveDir] ldp in ADAM-SP1>> Yeah what I was doing
was setting a FC ACE for connection objects only. > If you want to
cover multiple objects for this you would need to specify> multiple
objectclasses which would result in multiple ACEs which is not> a good
option. Which means, use a different tool as the bugs in the > current
version of LDP make that difficult for this specific task. In my>
tests, I was specifically using LDP from ADAM SP1. But for what you
want> to do, use ADUC or DSACLS.>> As an aside, I emailed
Matheesha directly a little while ago when my > first email was lost in
limbo waiting to be sent out by the list. A> version of LDP that
doesn't have this issue should be in Longhorn when> it is released. The
developer quickly fixed the first bug I mentioned > this morning after
I pinged him and it seems the second bug had already> been corrected.
This folks is the power of this list.... Take note.>> I am not
entirely positive what the "Access system security" is supposed > to
be... This is not an issue in later versions of LDP...>> I would
say read the chapters on security in the AD book, then if you> don't
have it, get and read Sakari's book as that has a great chapter on > AD
security and then finally if you still want to learn more, wander> into
the MSDN library and start reading about Security Descriptors,> Access
Control Lists, and Access Control Entries. Once you understand > the
structures and how they are represented a lot of the security stuff>
starts making more and more sense.>>
joe>>> --> O'Reilly Active Directory Third Edition
- > http://www.joeware.net/win/ad3e.htm>>>
-----Original Message-----> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of Matheesha> Weerasinghe> Sent: Monday, July 24, 2006
2:03 PM> To: ActiveDir@xxxxxxxxxxxxxxxxxx>
Subject: Re: [ActiveDir] ldp in ADAM-SP1>> Joe>>
joe I see you were configuring Full Control (GA) for nTDSConnection>
objects by configuring perms on the parent nTDSDSA object. I was trying
> to actually configure full control to the nTDSDSA using perms on
the> CN=Sites object but the principal is the same I guess. The only
thing is> nTDSConnection objects cant have child objects can they?
> Still I am having some issues repro'ing. You said your workaround was
to> configure on the object types. Did you mean to configure explicitly
on> the object or on the parent with the child's object type specified
in > the ACE? I cant repro here and I am not sure whether you used
dsacls or> ldp to repro.>> And why does it not choose the
"Access System Security" option when you> edit a Full Control ACE? Is
that expected? I thought full control meant > everything. Not
everything but "Access System Security".>> Also how come there
is no string defined for "Access System Security"?> There is for all
other access masks.>> I freely admit I know very little in this
arena. Any lesson offered is> most appreciated. I am already reading
technet and many books by the> fine guys on here. I just havent
finished them yet ;-) >> Thanks to everyone who's read this so
far and for all the help I am> offered. I truly appreciate
it.>> Sincerely>> M@>>> On
7/24/06, joe 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=Conf>
igur> > 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 > parent>> >
Allow TEST\Enterprise
Admins FULL
CONTROL > parent> >
>> > Permissions inherited to subobjects are:> >
Inherited to all subobjects> > Allow TEST\Domain
Admins FULL
CONTROL > parent>> >
Allow TEST\Enterprise
Admins FULL
CONTROL > 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:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx>
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of Matheesha> > Weerasinghe> > Sent: Monday,
July 24, 2006 8:12 AM > > To: ActiveDir@xxxxxxxxxxxxxxxxxx>
> 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>>
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.aspxList
FAQ : http://www.activedir.org/ListFAQ.aspxList
archive: http://www.activedir.org/ml/threads.aspx | | | |
| GuidoG
Posts:114
| | 07/25/2006 6:40 AM |
| I guess Matheesha's original question has been answered as good as it
can for now with the information given. I just quickly want to comment
on the 3rd party tool aspect joe is mentioning below - naturally, before
spending considerable money on the tools, you'd need to test if they do
what you want them to do in the first place.
What I've found from many years of leveraging and checking different
ACLing tools is that they also just go so far... I've had various
different customer requests, which could not be achieved with the tools,
but could be achieved with the native ACLs (mostly talking AD here).
After getting over the hurdles of the basics, scripting quickly becomes
your friend. I am not saying that 3rd party tools aren't quite useful
for general ACLing stuff - it's when your own security model is complex,
the tools will often not be able to help you reach your goal.
Often this is a result of the complex ACLing rules build by MSFT
themselves. Very hard for a developer to keep up with all changes (think
of all the changes in Win2003 compared to 2000 and then with Win2003
SP1) and to understand the plethora of rules, especially when it comes
to combining specific ACLing settings set at totally different places in
the directory. A great example for this are various options to
controlling delegation of password settings (I've written this up
internally and for my upcoming Windows security book, as joe had been
pointed at in his other reply). Win2003 provides three new not so well
known extended rights, which allow domain admins to control which
delegated admin can change critical password attributes on user
accounts:
* Enable-Per-User-Reversibly-Encrypted-Password
* Unexpire-Password
* Update-Password-Not-Required-Bit
The challenge: these extended rights are set at the domain level, while
other permissions to control which delegated admin can do what in an OU
(e.g. create and manage users) are typically set at the OU level. So if
you give a delegated admin full control over users, he would for example
not be able to set the "Password never expires" and the "Store password
using reversible encryption" options on the user accounts he is allowed
to fully control, UNLESS he is ALSO granted the appropriate extended
right at the root of your domain ("Unexpire-Password" and
"Enable-Per-User-Reversibly-Encrypted-Password" in this example).
This is certainly challenging for any domain admininstrator and moreso
for 3rd party ACLing tools. Realize that by default the three extended
rights I have mentioned above are granted to Authenticated Users, which
means that any delegated admin who is also granted the rights to control
the account restrictions of a user can set the respective password
options. As these are rather sensible settings though, I'd rather
disable any delegated admin from setting them (which is why the extended
rights have been added to Win2003 in the first place). If you have
different admins allowed to create users, just check out your domains
and see how many users are configured with the "password never expires"
flag - you will quickly understand what I mean.
But again: it is very tough for 3rd party tools to remove default rights
for you => they usually just handle adding permissions and it is up to
you to fully understand the ACLing concepts of Windows to make
everything work correctly.
/Guido
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of joe
Sent: Monday, July 24, 2006 7:00 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] ldp in ADAM-SP1
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Matheesha
Weerasinghe
Sent: Monday, July 24, 2006 11:32 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
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 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=Conf
igur
> 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 parent>
> Allow TEST\Enterprise Admins FULL CONTROL parent>
>
> Permissions inherited to subobjects are:
> Inherited to all subobjects
> Allow TEST\Domain Admins FULL CONTROL parent>
> Allow TEST\Enterprise Admins FULL CONTROL 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Matheesha
> Weerasinghe
> Sent: Monday, July 24, 2006 8:12 AM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> 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
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 | | | |
| matheesha
Posts:34
| | 07/25/2006 7:17 AM |
| Thanks to Al and Guido for your further input. Even though it may seem
pretty obvious, I would like to know of any horror stories due to AD
ACL'ing if possible. The reason is Al's comments have made me take a
much more cautious approach to ACL'ing. I get the feeling that even
though the granular feature is there, if there arent enoug people with
the correct skill level available to maintain it, then it shouldnt be
pursued. I hope I can get that skill and that is one fo the goals
here. But I may not be here all the time.....
So any stories from anyone ?
M@
On 7/25/06, Al Mulnick wrote:
I wholeheartedly applaud the effort being put into this. That said, I urge
you to reconsider your administrative model and favor as much simplicity as
is possible. Why? Because the best laid plans of mice and architects and
all that.
"The tricky bit is the matching a trusted and
appropriately skilled person to the relevant role."
That makes me laugh and cringe at the same time. Yes, it is very difficult
to find that "perfect match" but at the same time I think a design should
take that into account where possible. That's a design philosophy and I
won't debate that for this thread. But I would caution you that any design
that has the people intricately relied upon is going to have a failure point
at some point when you least can tolerate it.
While you can use the command line tools as much as possible, as joe and
Guido both pointed out, consider rolling your own scripts if you absolutely
cannot do what you *need* to do at the GUI. But remember you can really
really really^^ hurt yourself with security permissions. Believe me, it can
be ugly and it can be the undoing.
Two thoughts consider as you walk through the design:
1) You should never try to solve wetware issues with software or hardware.
2) Complexity is the anti-security.
Best of luck.
On 7/25/06, Matheesha Weerasinghe wrote:
> Wow,
>
> Thanks you so much for the detailed info guys. Basically my goal is
> quite simple. At least it is in my head. What I want to do, is to go
> through the entire case study given in the AD delegation whitepaper,
> and do all of that permissions configuration entirely at command line
> (where possible). I am willing to use the delegation wizard to some
> extent, but as I am configuring quite a lot of permissions for an AD
> design I am involved in, I would rather avoid having to use GUI tools
> for this.
>
> You see, I am going to end up as been a very privileged service
> administrator and data administrator once my proposed AD design model
> is in place. I expect I will be making some endeavour to train
> sufficiently capable people in doing this. But I dont plan to spoon
> feed. I want the guys to know to a decent level ACL'ing and if not, do
> their research. At least on an adhoc basis. Then once they understand
> whats involved, they can go ahead and add/modify/delete ACE's , revoke
> perms, define new roles etc...
>
> Reading this delegation doc has made me believe I can configure an
> extremely secure delegation model where each role can be given just
> enough to do that role. The tricky bit is the matching a trusted and
> appropriately skilled person to the relevant role.
>
> So you see, as there is a lot involved and this is a big
> infrastructure to attempt to administer perms for 20,000 users plus
> many OUs used to organise users based on the business unit (at least a
> dozen in each geographical hub) they work in and the site (we have
> more than a 40 geographical hubs and 1000 satellite sites) they are
> located at. Different levels of data admin roles. I would like to get
> this right to a large extent from the moment go. Admittedly it may not
> be big as in Fortune 5 ADs. But its the biggest I've had the privilege
> to design and support.
>
> I figured if I test this using the case study as a lab, I will get a
> good feel of whats involved in my lower level design. I am getting a
> little miffed when I have to swap between several tools to do what I
> need to do. There is just so many buts and ifs. "You can do this but
> you cant do this. To do this use this. For this use that. And then
> try this. If all else fails script ...."
>
> I admit I was ranting a bit when asking why is this named and like
> such and the discrepencies in the docs and syntax help of command line
> tools. My sincere apologies for been anal.
>
> Is it too much to ask, to have at the very least a reliable command
> line or GUI tool (ldp) to configure perms just the way I want and
> need? Actually I don care even if I have to use a series of command
> line apps. I dont care how complex it is/willbe right now. I just want
> something that works. And I want the tool from MSFT. For free ;0)
>
> Please!
>
> Cheers
>
> M@
>
>
> P.S. thanks once again for reading, for escalating, for laughing, for
> educating , the kind words, hugs
> Control-H,Control-H,Control-H,Control-H,Control-H, etc...
>
>
>
> On 7/25/06, Grillenmeier, Guido wrote:
> > I guess Matheesha's original question has been answered as good as it
> > can for now with the information given. I just quickly want to comment
> > on the 3rd party tool aspect joe is mentioning below - naturally, before
> > spending considerable money on the tools, you'd need to test if they do
> > what you want them to do in the first place.
> >
> > What I've found from many years of leveraging and checking different
> > ACLing tools is that they also just go so far... I've had various
> > different customer requests, which could not be achieved with the tools,
> > but could be achieved with the native ACLs (mostly talking AD here).
> > After getting over the hurdles of the basics, scripting quickly becomes
> > your friend. I am not saying that 3rd party tools aren't quite useful
> > for general ACLing stuff - it's when your own security model is complex,
> > the tools will often not be able to help you reach your goal.
> >
> > Often this is a result of the complex ACLing rules build by MSFT
> > themselves. Very hard for a developer to keep up with all changes (think
> > of all the changes in Win2003 compared to 2000 and then with Win2003
> > SP1) and to understand the plethora of rules, especially when it comes
> > to combining specific ACLing settings set at totally different places in
> > the directory. A great example for this are various options to
> > controlling delegation of password settings (I've written this up
> > internally and for my upcoming Windows security book, as joe had been
> > pointed at in his other reply). Win2003 provides three new not so well
> > known extended rights, which allow domain admins to control which
> > delegated admin can change critical password attributes on user
> > accounts:
> >
> > * Enable-Per-User-Reversibly-Encrypted-Password
> > * Unexpire-Password
> > * Update-Password-Not-Required-Bit
> >
> > The challenge: these extended rights are set at the domain level, while
> > other permissions to control which delegated admin can do what in an OU
> > (e.g. create and manage users) are typically set at the OU level. So if
> > you give a delegated admin full control over users, he would for example
> > not be able to set the "Password never expires" and the "Store password
> > using reversible encryption" options on the user accounts he is allowed
> > to fully control, UNLESS he is ALSO granted the appropriate extended
> > right at the root of your domain ("Unexpire-Password" and
> > "Enable-Per-User-Reversibly-Encrypted-Password" in this
example).
> >
> > This is certainly challenging for any domain admininstrator and moreso
> > for 3rd party ACLing tools. Realize that by default the three extended
> > rights I have mentioned above are granted to Authenticated Users, which
> > means that any delegated admin who is also granted the rights to control
> > the account restrictions of a user can set the respective password
> > options. As these are rather sensible settings though, I'd rather
> > disable any delegated admin from setting them (which is why the extended
> > rights have been added to Win2003 in the first place). If you have
> > different admins allowed to create users, just check out your domains
> > and see how many users are configured with the "password never expires"
> > flag - you will quickly understand what I mean.
> >
> > But again: it is very tough for 3rd party tools to remove default rights
> > for you => they usually just handle adding permissions and it is up to
> > you to fully understand the ACLing concepts of Windows to make
> > everything work correctly.
> >
> > /Guido
> >
> >
> > -----Original Message-----
> > From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> > [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf
Of joe
> > Sent: Monday, July 24, 2006 7:00 PM
> > To: ActiveDir@xxxxxxxxxxxxxxxxxx
> > Subject: RE: [ActiveDir] ldp in ADAM-SP1
> >
> > 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> > [mailto: ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf
Of Matheesha
> > Weerasinghe
> > Sent: Monday, July 24, 2006 11:32 AM
> > To: ActiveDir@xxxxxxxxxxxxxxxxxx
> > 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 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=Conf
> > igur
> > > 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 > > parent>
> > > Allow TEST\Enterprise Admins FULL CONTROL > > parent>
> > >
> > > Permissions inherited to subobjects are:
> > > Inherited to all subobjects
> > > Allow TEST\Domain Admins FULL CONTROL > > parent>
> > > Allow TEST\Enterprise Admins FULL CONTROL > > 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> > > [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf
Of Matheesha
> > > Weerasinghe
> > > Sent: Monday, July 24, 2006 8:12 AM
> > > To: ActiveDir@xxxxxxxxxxxxxxxxxx
> > > 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
> > 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 | | | |
| matheesha
Posts:34
| | 07/25/2006 7:34 AM |
| Wow,
Thanks you so much for the detailed info guys. Basically my goal is
quite simple. At least it is in my head. What I want to do, is to go
through the entire case study given in the AD delegation whitepaper,
and do all of that permissions configuration entirely at command line
(where possible). I am willing to use the delegation wizard to some
extent, but as I am configuring quite a lot of permissions for an AD
design I am involved in, I would rather avoid having to use GUI tools
for this.
You see, I am going to end up as been a very privileged service
administrator and data administrator once my proposed AD design model
is in place. I expect I will be making some endeavour to train
sufficiently capable people in doing this. But I dont plan to spoon
feed. I want the guys to know to a decent level ACL'ing and if not, do
their research. At least on an adhoc basis. Then once they understand
whats involved, they can go ahead and add/modify/delete ACE's , revoke
perms, define new roles etc...
Reading this delegation doc has made me believe I can configure an
extremely secure delegation model where each role can be given just
enough to do that role. The tricky bit is the matching a trusted and
appropriately skilled person to the relevant role.
So you see, as there is a lot involved and this is a big
infrastructure to attempt to administer perms for 20,000 users plus
many OUs used to organise users based on the business unit (at least a
dozen in each geographical hub) they work in and the site (we have
more than a 40 geographical hubs and 1000 satellite sites) they are
located at. Different levels of data admin roles. I would like to get
this right to a large extent from the moment go. Admittedly it may not
be big as in Fortune 5 ADs. But its the biggest I've had the privilege
to design and support.
I figured if I test this using the case study as a lab, I will get a
good feel of whats involved in my lower level design. I am getting a
little miffed when I have to swap between several tools to do what I
need to do. There is just so many buts and ifs. "You can do this but
you cant do this. To do this use this. For this use that. And then
try this. If all else fails script ...."
I admit I was ranting a bit when asking why is this named and like
such and the discrepencies in the docs and syntax help of command line
tools. My sincere apologies for been anal.
Is it too much to ask, to have at the very least a reliable command
line or GUI tool (ldp) to configure perms just the way I want and
need? Actually I don care even if I have to use a series of command
line apps. I dont care how complex it is/willbe right now. I just want
something that works. And I want the tool from MSFT. For free ;0)
Please!
Cheers
M@
P.S. thanks once again for reading, for escalating, for laughing, for
educating , the kind words, hugs
Control-H,Control-H,Control-H,Control-H,Control-H, etc...
On 7/25/06, Grillenmeier, Guido wrote:
I guess Matheesha's original question has been answered as good as it
can for now with the information given. I just quickly want to comment
on the 3rd party tool aspect joe is mentioning below - naturally, before
spending considerable money on the tools, you'd need to test if they do
what you want them to do in the first place.
What I've found from many years of leveraging and checking different
ACLing tools is that they also just go so far... I've had various
different customer requests, which could not be achieved with the tools,
but could be achieved with the native ACLs (mostly talking AD here).
After getting over the hurdles of the basics, scripting quickly becomes
your friend. I am not saying that 3rd party tools aren't quite useful
for general ACLing stuff - it's when your own security model is complex,
the tools will often not be able to help you reach your goal.
Often this is a result of the complex ACLing rules build by MSFT
themselves. Very hard for a developer to keep up with all changes (think
of all the changes in Win2003 compared to 2000 and then with Win2003
SP1) and to understand the plethora of rules, especially when it comes
to combining specific ACLing settings set at totally different places in
the directory. A great example for this are various options to
controlling delegation of password settings (I've written this up
internally and for my upcoming Windows security book, as joe had been
pointed at in his other reply). Win2003 provides three new not so well
known extended rights, which allow domain admins to control which
delegated admin can change critical password attributes on user
accounts:
* Enable-Per-User-Reversibly-Encrypted-Password
* Unexpire-Password
* Update-Password-Not-Required-Bit
The challenge: these extended rights are set at the domain level, while
other permissions to control which delegated admin can do what in an OU
(e.g. create and manage users) are typically set at the OU level. So if
you give a delegated admin full control over users, he would for example
not be able to set the "Password never expires" and the "Store password
using reversible encryption" options on the user accounts he is allowed
to fully control, UNLESS he is ALSO granted the appropriate extended
right at the root of your domain ("Unexpire-Password" and
"Enable-Per-User-Reversibly-Encrypted-Password" in this example).
This is certainly challenging for any domain admininstrator and moreso
for 3rd party ACLing tools. Realize that by default the three extended
rights I have mentioned above are granted to Authenticated Users, which
means that any delegated admin who is also granted the rights to control
the account restrictions of a user can set the respective password
options. As these are rather sensible settings though, I'd rather
disable any delegated admin from setting them (which is why the extended
rights have been added to Win2003 in the first place). If you have
different admins allowed to create users, just check out your domains
and see how many users are configured with the "password never expires"
flag - you will quickly understand what I mean.
But again: it is very tough for 3rd party tools to remove default rights
for you => they usually just handle adding permissions and it is up to
you to fully understand the ACLing concepts of Windows to make
everything work correctly.
/Guido
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of joe
Sent: Monday, July 24, 2006 7:00 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] ldp in ADAM-SP1
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Matheesha
Weerasinghe
Sent: Monday, July 24, 2006 11:32 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
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 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=Conf
igur
> 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 parent>
> Allow TEST\Enterprise Admins FULL CONTROL parent>
>
> Permissions inherited to subobjects are:
> Inherited to all subobjects
> Allow TEST\Domain Admins FULL CONTROL parent>
> Allow TEST\Enterprise Admins FULL CONTROL 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Matheesha
> Weerasinghe
> Sent: Monday, July 24, 2006 8:12 AM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> 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
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 | | | |
| matheesha
Posts:34
| | 07/25/2006 12:45 PM |
| There is much in ldp I dont know. Everything I do know, I learned from
John Craddock's book and the understanding ldap whitepaper from MSFT.
Thanks for all the help so far joe and Dmitri . If I wanted to get my
TAM to get the updated version of ldp as it stands, what QFE number
should I quote?
The more I look into this the more insane I get ;-) Why is the
Extended Right is defined with the string "SW" in the sddl format but
dsacls uses "WS". Different access masks have different names
depending on what I read. "Read permissions" in ldp is "Read Control"
in the docs. "Extended write" in ldp is "Write to self" in dsacls. At
least thats how I understood it.
I may have to make my own notes on this. If I ever have to read this
stuff and the delegation docs I am definitely going to go nuts.
Would it be fare to say we can do all we need definitely using
scripts? Or is that also not definite? You see, until recently I was
reading this delegation doc with a grin from ear-to-ear thinking yeah!
And now I am not so ....
Before I break down and cry like Homer, I'm gonna go get some Zzzzzzzzzzzzzz!
Cheers
M@
On 7/24/06, Dmitri Gavrilov wrote:
Re "Access System Security" checkbox. We removed it from the latest
versions of ldp.exe because it does not do what you want. Even if you
grant this right to some principal, he will still be unable to read or
tweak the SACLs. The only way to be able to do this is to grant
SE_ACCESS_SYSTEM_SECURITY privilege. You do this from gpedit.msc
(security settings/User rights assignments).
On a more general note -- yes, AD security is a mess to manage and to
understand. We are trying to improve it, but it is super super difficult
task. Not only the rules are difficult to understand and are numerous,
but also we need to respect the existing security setups which use weird
ACLs. There were several attempts to improve things, but I don't believe
we are getting closer, mostly due to backward compatibility issues, as
well as due to the need to introduce new rules (such as confidentiality
bit and many new control access rights).
BTW, the Delegation Wizard is considered to be the "entry-level" ACLing
tool. Alas, it does not work for ADAM.
Dmitri
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of joe
Sent: Monday, July 24, 2006 1:42 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] ldp in ADAM-SP1
Yeah what I was doing was setting a FC ACE for connection objects only.
If you want to cover multiple objects for this you would need to specify
multiple objectclasses which would result in multiple ACEs which is not
a good option. Which means, use a different tool as the bugs in the
current version of LDP make that difficult for this specific task. In my
tests, I was specifically using LDP from ADAM SP1. But for what you want
to do, use ADUC or DSACLS.
As an aside, I emailed Matheesha directly a little while ago when my
first email was lost in limbo waiting to be sent out by the list. A
version of LDP that doesn't have this issue should be in Longhorn when
it is released. The developer quickly fixed the first bug I mentioned
this morning after I pinged him and it seems the second bug had already
been corrected. This folks is the power of this list.... Take note.
I am not entirely positive what the "Access system security" is supposed
to be... This is not an issue in later versions of LDP...
I would say read the chapters on security in the AD book, then if you
don't have it, get and read Sakari's book as that has a great chapter on
AD security and then finally if you still want to learn more, wander
into the MSDN library and start reading about Security Descriptors,
Access Control Lists, and Access Control Entries. Once you understand
the structures and how they are represented a lot of the security stuff
starts making more and more sense.
joe
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Matheesha
Weerasinghe
Sent: Monday, July 24, 2006 2:03 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] ldp in ADAM-SP1
Joe
joe I see you were configuring Full Control (GA) for nTDSConnection
objects by configuring perms on the parent nTDSDSA object. I was trying
to actually configure full control to the nTDSDSA using perms on the
CN=Sites object but the principal is the same I guess. The only thing is
nTDSConnection objects cant have child objects can they?
Still I am having some issues repro'ing. You said your workaround was to
configure on the object types. Did you mean to configure explicitly on
the object or on the parent with the child's object type specified in
the ACE? I cant repro here and I am not sure whether you used dsacls or
ldp to repro.
And why does it not choose the "Access System Security" option when you
edit a Full Control ACE? Is that expected? I thought full control meant
everything. Not everything but "Access System Security".
Also how come there is no string defined for "Access System Security"?
There is for all other access masks.
I freely admit I know very little in this arena. Any lesson offered is
most appreciated. I am already reading technet and many books by the
fine guys on here. I just havent finished them yet ;-)
Thanks to everyone who's read this so far and for all the help I am
offered. I truly appreciate it.
Sincerely
M@
On 7/24/06, joe 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=Conf
igur
> 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 parent>
> Allow TEST\Enterprise Admins FULL CONTROL parent>
>
> Permissions inherited to subobjects are:
> Inherited to all subobjects
> Allow TEST\Domain Admins FULL CONTROL parent>
> Allow TEST\Enterprise Admins FULL CONTROL 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Matheesha
> Weerasinghe
> Sent: Monday, July 24, 2006 8:12 AM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> 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
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 | | | |
| amulnick
Posts:163
| | 07/26/2006 2:16 AM |
| I've seen a few that absolutely were too complex. They ended up having to scrap the whole thing and start again because after several weeks of troubleshooting issues, some folks were shown the door and a new crowd brought in. First order of business was to simplify. Because the information went out the wind^^door, the historical information wasn't there and they got to start all over.
I've seen others where they thought they had it all nailed up and couldn't understand why applications kept failing. There were many reasons, but one was that there were about 400+ domain admins and many more if they wanted to spend a few minutes trying. Bad process and a lack of understanding coupled with unneeded complexity and whiny managers were the root of that debacle. Recommendation was to reduce, simplify, and remove. Stability and reliability went way up although a few people might have wanted to burn me in effigy if not in person :)
As simple as possible to meet the stated and agreed upon goals is the recommendation.
Al
On 7/26/06, Grillenmeier, Guido wrote:
well, do as you should always do to ensure that your systems aremaintainable: keep it simple!Don't introduce extra complexity if you don't require it. For AD ACLing
this means, don't introduce roles and permissions for users, if you donot need that role - there is certainly no need to implement all theroles that are described in the delegation whitepaper to maintain a
stable AD infrastructure.most ACLing issues that I have come across was in companies that grantedtheir delegated admins the rights to create OUs underneath theirlocation specific OU - soon afterwards they had an AD structure with OUs
and permissions that looked like a badly managed file-server...so the issue is not so much setting ACLs in AD (which as discussed canbe a complex task to do right, depending on your needs), but morecontrolling who is allowed to set ACLs. This should be done centrally by
domain and/or enterprise admins. As a rule of thumb you should not grantany non-domain or enterprise admin the rights to create OUs and alsolimit the rights to create any other objects (especially groups) to very
few delegated admins. Less critical is delegating the ability to manageexisting objects (e.g. to reset PW of user, mail-enable users andgroups, change membership of groups, etc). I also consider the rights to
create computer objects as low risk (which is usually required by localdesktop admins in branch offices)./Guido-----Original Message-----From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of MatheeshaWeerasingheSent: Tuesday, July 25, 2006 9:18 PMTo:
ActiveDir@xxxxxxxxxxxxxxxxxxSubject: Re: [ActiveDir] ldp in ADAM-SP1Thanks to Al and Guido for your further input. Even though it may seempretty obvious, I would like to know of any horror stories due to AD
ACL'ing if possible. The reason is Al's comments have made me take amuch more cautious approach to ACL'ing. I get the feeling that eventhough the granular feature is there, if there arent enoug people with
the correct skill level available to maintain it, then it shouldnt bepursued. I hope I can get that skill and that is one fo the goalshere. But I may not be here all the time.....So any stories from anyone ?
M@On 7/25/06, Al Mulnick wrote:>> I wholeheartedly applaud the effort being put into this. That said, Iurge> you to reconsider your administrative model and favor as much
simplicity as> is possible. Why? Because the best laid plans of mice and architectsand> all that.>> "The tricky bit is the matching a trusted and> appropriately skilled person to the relevant role."
>> That makes me laugh and cringe at the same time. Yes, it is verydifficult> to find that "perfect match" but at the same time I think a designshould> take that into account where possible. That's a design philosophy and
I> won't debate that for this thread. But I would caution you that anydesign> that has the people intricately relied upon is going to have a failurepoint> at some point when you least can tolerate it.
>> While you can use the command line tools as much as possible, as joeand> Guido both pointed out, consider rolling your own scripts if youabsolutely> cannot do what you *need* to do at the GUI. But remember you can
really> really really^^ hurt yourself with security permissions. Believe me,it can> be ugly and it can be the undoing.>> Two thoughts consider as you walk through the design:> 1) You should never try to solve wetware issues with software or
hardware.> 2) Complexity is the anti-security.>> Best of luck.>>>> On 7/25/06, Matheesha Weerasinghe wrote:
> > Wow,> >> > Thanks you so much for the detailed info guys. Basically my goal is> > quite simple. At least it is in my head. What I want to do, is to go> > through the entire case study given in the AD delegation whitepaper,
> > and do all of that permissions configuration entirely at commandline> > (where possible). I am willing to use the delegation wizard to some> > extent, but as I am configuring quite a lot of permissions for an AD
> > design I am involved in, I would rather avoid having to use GUItools> > for this.> >> > You see, I am going to end up as been a very privileged service> > administrator and data administrator once my proposed AD design
model> > is in place. I expect I will be making some endeavour to train> > sufficiently capable people in doing this. But I dont plan to spoon> > feed. I want the guys to know to a decent level ACL'ing and if not,
do> > their research. At least on an adhoc basis. Then once theyunderstand> > whats involved, they can go ahead and add/modify/delete ACE's ,revoke> > perms, define new roles etc...
> >> > Reading this delegation doc has made me believe I can configure an> > extremely secure delegation model where each role can be given just> > enough to do that role. The tricky bit is the matching a trusted and
> > appropriately skilled person to the relevant role.> >> > So you see, as there is a lot involved and this is a big> > infrastructure to attempt to administer perms for 20,000 users plus
> > many OUs used to organise users based on the business unit (at leasta> > dozen in each geographical hub) they work in and the site (we have> > more than a 40 geographical hubs and 1000 satellite sites) they are
> > located at. Different levels of data admin roles. I would like toget> > this right to a large extent from the moment go. Admittedly it maynot> > be big as in Fortune 5 ADs. But its the biggest I've had the
privilege> > to design and support.> >> > I figured if I test this using the case study as a lab, I will get a> > good feel of whats involved in my lower level design. I am getting a
> > little miffed when I have to swap between several tools to do what I> > need to do. There is just so many buts and ifs. "You can do this but> > you cant do this. To do this use this. For this use that. And then
> > try this. If all else fails script ...."> >> > I admit I was ranting a bit when asking why is this named and like> > such and the discrepencies in the docs and syntax help of command
line> > tools. My sincere apologies for been anal.> >> > Is it too much to ask, to have at the very least a reliable command> > line or GUI tool (ldp) to configure perms just the way I want and
> > need? Actually I don care even if I have to use a series of command> > line apps. I dont care how complex it is/willbe right now. I justwant> > something that works. And I want the tool from MSFT. For free ;0)
> >> > Please!> >> > Cheers> >> > M@> >> >> > P.S. thanks once again for reading, for escalating, for laughing,for> > educating , the kind words, hugs
> > Control-H,Control-H,Control-H,Control-H,Control-H, etc...> >> >> >> > On 7/25/06, Grillenmeier, Guido wrote:> > > I guess Matheesha's original question has been answered as good asit> > > can for now with the information given. I just quickly want tocomment> > > on the 3rd party tool aspect joe is mentioning below - naturally,
before> > > spending considerable money on the tools, you'd need to test ifthey do> > > what you want them to do in the first place.> > >> > > What I've found from many years of leveraging and checking
different> > > ACLing tools is that they also just go so far... I've had various> > > different customer requests, which could not be achieved with thetools,> > > but could be achieved with the native ACLs (mostly talking AD
here).> > > After getting over the hurdles of the basics, scripting quicklybecomes> > > your friend. I am not saying that 3rd party tools aren't quiteuseful> > > for general ACLing stuff - it's when your own security model is
complex,> > > the tools will often not be able to help you reach your goal.> > >> > > Often this is a result of the complex ACLing rules build by MSFT> > > themselves. Very hard for a developer to keep up with all changes
(think> > > of all the changes in Win2003 compared to 2000 and then withWin2003> > > SP1) and to understand the plethora of rules, especially when itcomes> > > to combining specific ACLing settings set at totally different
places in> > > the directory. A great example for this are various options to> > > controlling delegation of password settings (I've written this up> > > internally and for my upcoming Windows security book, as joe had
been> > > pointed at in his other reply). Win2003 provides three new not sowell> > > known extended rights, which allow domain admins to control which> > > delegated admin can change critical password attributes on user
> > > accounts:> > >> > > * Enable-Per-User-Reversibly-Encrypted-Password> > > * Unexpire-Password> > > * Update-Password-Not-Required-Bit> > >
> > > The challenge: these extended rights are set at the domain level,while> > > other permissions to control which delegated admin can do what inan OU> > > (e.g. create and manage users) are typically set at the OU level.
So if> > > you give a delegated admin full control over users, he would forexample> > > not be able to set the "Password never expires" and the "Storepassword> > > using reversible encryption" options on the user accounts he is
allowed> > > to fully control, UNLESS he is ALSO granted the appropriateextended> > > right at the root of your domain ("Unexpire-Password" and> > > "Enable-Per-User-Reversibly-Encrypted-Password" in this
> example).> > >> > > This is certainly challenging for any domain admininstrator andmoreso> > > for 3rd party ACLing tools. Realize that by default the threeextended
> > > rights I have mentioned above are granted to Authenticated Users,which> > > means that any delegated admin who is also granted the rights tocontrol> > > the account restrictions of a user can set the respective password
> > > options. As these are rather sensible settings though, I'd rather> > > disable any delegated admin from setting them (which is why theextended> > > rights have been added to Win2003 in the first place). If you
have> > > different admins allowed to create users, just check out yourdomains> > > and see how many users are configured with the "password neverexpires"> > > flag - you will quickly understand what I mean.
> > >> > > But again: it is very tough for 3rd party tools to remove defaultrights> > > for you => they usually just handle adding permissions and it isup to> > > you to fully understand the ACLing concepts of Windows to make
> > > everything work correctly.> > >> > > /Guido> > >> > >> > > -----Original Message-----> > > From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx> > > [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf> Of joe> > > Sent: Monday, July 24, 2006 7:00 PM
> > > To: ActiveDir@xxxxxxxxxxxxxxxxxx> > > Subject: RE: [ActiveDir] ldp in ADAM-SP1> > >> > > 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 isalso> > > quite> > > complex and getting more so. Look at the confidential attribute
hack and> > > the> > > extended rights for protecting userAccountControl (Update PasswordNot> > > 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 aswell 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 totell> > > 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 formany
> > > people> > > that just pisses them off and makes them say... Hey Microsoftshould> > > already> > > be supplying this, I'm not buying something. That combined with
the fact> > > that just maybe MSFT will realize they should correct this willtend 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 withoutmaking> > > 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 arefew> > > people> > > who understand how ACLs really work and are configured to thepoint that
> > > the> > > tool would really be useful to any large number of people.> > >> > > Something we recommended previously to MSFT is that we need toradically> > > 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 becareful> > > 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 clueother> > > 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 asyou 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 andmaybe 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 thatdo> > > things> > > in this area, BindView (BVAdmin/BVControl) and Active Roles.
However> > > again,> > > usually people immediately start talking about costs and the factthat> > > 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. Fromwhat> > > I
> > > understand the NET 2.0 framework is alleged to make this mucheasier.> > > Usually easier means less flexibility and builtin assumptions butI> > > 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 thedeveloper> > > working on LDP and can say that he is digging into this. I can'tsay> > > much
> > > more than that though.> > >> > >> > > joe> > >> > >> > > --> > > O'Reilly Active Directory Third Edition -
> > > http://www.joeware.net/win/ad3e.htm> > >> > >> > > -----Original Message-----> > > From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx> > > [mailto: ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf> Of Matheesha> > > Weerasinghe
> > > Sent: Monday, July 24, 2006 11:32 AM> > > To: ActiveDir@xxxxxxxxxxxxxxxxxx> > > 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 mostperms> > > 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 haveto> > > 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 Icome.> > > 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 beheeded> > > to. But please, guys out there with the influence (MVPs) help!!
> > >> > > M@> > >> > >> > > P.S Please!!!> > >> > >> > > On 7/24/06, joe 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 isthe FC> > > > inherit only to the object class you specify but then there isalso a
> > > FC> > > to> > > > the object itself. In the example below note the TEST\joeACEs... 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=Conf> > > igur> > > > 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
> > > parent>> > > > Allow TEST\Enterprise Admins FULL CONTROL > > > parent>> > > >> > > > Permissions inherited to subobjects are:
> > > > Inherited to all subobjects> > > > Allow TEST\Domain Admins FULL CONTROL > > > parent>> > > > Allow TEST\Enterprise Admins FULL CONTROL
> > > 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 whatyou> > > 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> > > > [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf> Of Matheesha> > > > Weerasinghe> > > > Sent: Monday, July 24, 2006 8:12 AM
> > > > To: ActiveDir@xxxxxxxxxxxxxxxxxx> > > > Subject: [ActiveDir] ldp in ADAM-SP1> > > >> > > > All> > > >
> > > > Could someone with more experience with ldp provided withADAM-SP1> > > > tell me how I would go about configuring inherit-only FullControl> > > > 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 isthe most> > > > comprehensive and capable ACL gui editor available. I must bedoing> > > > 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
> > > 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.aspxList FAQ :
http://www.activedir.org/ListFAQ.aspxList archive: http://www.activedir.org/ml/threads.aspxList info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspxList archive: http://www.activedir.org/ml/threads.aspx | | | |
| GuidoG
Posts:114
| | 07/26/2006 5:34 AM |
| well, do as you should always do to ensure that your systems are
maintainable: keep it simple!
Don't introduce extra complexity if you don't require it. For AD ACLing
this means, don't introduce roles and permissions for users, if you do
not need that role - there is certainly no need to implement all the
roles that are described in the delegation whitepaper to maintain a
stable AD infrastructure.
most ACLing issues that I have come across was in companies that granted
their delegated admins the rights to create OUs underneath their
location specific OU - soon afterwards they had an AD structure with OUs
and permissions that looked like a badly managed file-server...
so the issue is not so much setting ACLs in AD (which as discussed can
be a complex task to do right, depending on your needs), but more
controlling who is allowed to set ACLs. This should be done centrally by
domain and/or enterprise admins. As a rule of thumb you should not grant
any non-domain or enterprise admin the rights to create OUs and also
limit the rights to create any other objects (especially groups) to very
few delegated admins. Less critical is delegating the ability to manage
existing objects (e.g. to reset PW of user, mail-enable users and
groups, change membership of groups, etc). I also consider the rights to
create computer objects as low risk (which is usually required by local
desktop admins in branch offices).
/Guido
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Matheesha
Weerasinghe
Sent: Tuesday, July 25, 2006 9:18 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] ldp in ADAM-SP1
Thanks to Al and Guido for your further input. Even though it may seem
pretty obvious, I would like to know of any horror stories due to AD
ACL'ing if possible. The reason is Al's comments have made me take a
much more cautious approach to ACL'ing. I get the feeling that even
though the granular feature is there, if there arent enoug people with
the correct skill level available to maintain it, then it shouldnt be
pursued. I hope I can get that skill and that is one fo the goals
here. But I may not be here all the time.....
So any stories from anyone ?
M@
On 7/25/06, Al Mulnick wrote:
>
> I wholeheartedly applaud the effort being put into this. That said, I
urge
> you to reconsider your administrative model and favor as much
simplicity as
> is possible. Why? Because the best laid plans of mice and architects
and
> all that.
>
> "The tricky bit is the matching a trusted and
> appropriately skilled person to the relevant role."
>
> That makes me laugh and cringe at the same time. Yes, it is very
difficult
> to find that "perfect match" but at the same time I think a design
should
> take that into account where possible. That's a design philosophy and
I
> won't debate that for this thread. But I would caution you that any
design
> that has the people intricately relied upon is going to have a failure
point
> at some point when you least can tolerate it.
>
> While you can use the command line tools as much as possible, as joe
and
> Guido both pointed out, consider rolling your own scripts if you
absolutely
> cannot do what you *need* to do at the GUI. But remember you can
really
> really really^^ hurt yourself with security permissions. Believe me,
it can
> be ugly and it can be the undoing.
>
> Two thoughts consider as you walk through the design:
> 1) You should never try to solve wetware issues with software or
hardware.
> 2) Complexity is the anti-security.
>
> Best of luck.
>
>
>
> On 7/25/06, Matheesha Weerasinghe wrote:
> > Wow,
> >
> > Thanks you so much for the detailed info guys. Basically my goal is
> > quite simple. At least it is in my head. What I want to do, is to go
> > through the entire case study given in the AD delegation whitepaper,
> > and do all of that permissions configuration entirely at command
line
> > (where possible). I am willing to use the delegation wizard to some
> > extent, but as I am configuring quite a lot of permissions for an AD
> > design I am involved in, I would rather avoid having to use GUI
tools
> > for this.
> >
> > You see, I am going to end up as been a very privileged service
> > administrator and data administrator once my proposed AD design
model
> > is in place. I expect I will be making some endeavour to train
> > sufficiently capable people in doing this. But I dont plan to spoon
> > feed. I want the guys to know to a decent level ACL'ing and if not,
do
> > their research. At least on an adhoc basis. Then once they
understand
> > whats involved, they can go ahead and add/modify/delete ACE's ,
revoke
> > perms, define new roles etc...
> >
> > Reading this delegation doc has made me believe I can configure an
> > extremely secure delegation model where each role can be given just
> > enough to do that role. The tricky bit is the matching a trusted and
> > appropriately skilled person to the relevant role.
> >
> > So you see, as there is a lot involved and this is a big
> > infrastructure to attempt to administer perms for 20,000 users plus
> > many OUs used to organise users based on the business unit (at least
a
> > dozen in each geographical hub) they work in and the site (we have
> > more than a 40 geographical hubs and 1000 satellite sites) they are
> > located at. Different levels of data admin roles. I would like to
get
> > this right to a large extent from the moment go. Admittedly it may
not
> > be big as in Fortune 5 ADs. But its the biggest I've had the
privilege
> > to design and support.
> >
> > I figured if I test this using the case study as a lab, I will get a
> > good feel of whats involved in my lower level design. I am getting a
> > little miffed when I have to swap between several tools to do what I
> > need to do. There is just so many buts and ifs. "You can do this but
> > you cant do this. To do this use this. For this use that. And then
> > try this. If all else fails script ...."
> >
> > I admit I was ranting a bit when asking why is this named and like
> > such and the discrepencies in the docs and syntax help of command
line
> > tools. My sincere apologies for been anal.
> >
> > Is it too much to ask, to have at the very least a reliable command
> > line or GUI tool (ldp) to configure perms just the way I want and
> > need? Actually I don care even if I have to use a series of command
> > line apps. I dont care how complex it is/willbe right now. I just
want
> > something that works. And I want the tool from MSFT. For free ;0)
> >
> > Please!
> >
> > Cheers
> >
> > M@
> >
> >
> > P.S. thanks once again for reading, for escalating, for laughing,
for
> > educating , the kind words, hugs
> > Control-H,Control-H,Control-H,Control-H,Control-H, etc...
> >
> >
> >
> > On 7/25/06, Grillenmeier, Guido wrote:
> > > I guess Matheesha's original question has been answered as good as
it
> > > can for now with the information given. I just quickly want to
comment
> > > on the 3rd party tool aspect joe is mentioning below - naturally,
before
> > > spending considerable money on the tools, you'd need to test if
they do
> > > what you want them to do in the first place.
> > >
> > > What I've found from many years of leveraging and checking
different
> > > ACLing tools is that they also just go so far... I've had various
> > > different customer requests, which could not be achieved with the
tools,
> > > but could be achieved with the native ACLs (mostly talking AD
here).
> > > After getting over the hurdles of the basics, scripting quickly
becomes
> > > your friend. I am not saying that 3rd party tools aren't quite
useful
> > > for general ACLing stuff - it's when your own security model is
complex,
> > > the tools will often not be able to help you reach your goal.
> > >
> > > Often this is a result of the complex ACLing rules build by MSFT
> > > themselves. Very hard for a developer to keep up with all changes
(think
> > > of all the changes in Win2003 compared to 2000 and then with
Win2003
> > > SP1) and to understand the plethora of rules, especially when it
comes
> > > to combining specific ACLing settings set at totally different
places in
> > > the directory. A great example for this are various options to
> > > controlling delegation of password settings (I've written this up
> > > internally and for my upcoming Windows security book, as joe had
been
> > > pointed at in his other reply). Win2003 provides three new not so
well
> > > known extended rights, which allow domain admins to control which
> > > delegated admin can change critical password attributes on user
> > > accounts:
> > >
> > > * Enable-Per-User-Reversibly-Encrypted-Password
> > > * Unexpire-Password
> > > * Update-Password-Not-Required-Bit
> > >
> > > The challenge: these extended rights are set at the domain level,
while
> > > other permissions to control which delegated admin can do what in
an OU
> > > (e.g. create and manage users) are typically set at the OU level.
So if
> > > you give a delegated admin full control over users, he would for
example
> > > not be able to set the "Password never expires" and the "Store
password
> > > using reversible encryption" options on the user accounts he is
allowed
> > > to fully control, UNLESS he is ALSO granted the appropriate
extended
> > > right at the root of your domain ("Unexpire-Password" and
> > > "Enable-Per-User-Reversibly-Encrypted-Password" in this
> example).
> > >
> > > This is certainly challenging for any domain admininstrator and
moreso
> > > for 3rd party ACLing tools. Realize that by default the three
extended
> > > rights I have mentioned above are granted to Authenticated Users,
which
> > > means that any delegated admin who is also granted the rights to
control
> > > the account restrictions of a user can set the respective password
> > > options. As these are rather sensible settings though, I'd rather
> > > disable any delegated admin from setting them (which is why the
extended
> > > rights have been added to Win2003 in the first place). If you
have
> > > different admins allowed to create users, just check out your
domains
> > > and see how many users are configured with the "password never
expires"
> > > flag - you will quickly understand what I mean.
> > >
> > > But again: it is very tough for 3rd party tools to remove default
rights
> > > for you => they usually just handle adding permissions and it is
up to
> > > you to fully understand the ACLing concepts of Windows to make
> > > everything work correctly.
> > >
> > > /Guido
> > >
> > >
> > > -----Original Message-----
> > > From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> > > [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf
> Of joe
> > > Sent: Monday, July 24, 2006 7:00 PM
> > > To: ActiveDir@xxxxxxxxxxxxxxxxxx
> > > Subject: RE: [ActiveDir] ldp in ADAM-SP1
> > >
> > > 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> > > [mailto: ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf
> Of Matheesha
> > > Weerasinghe
> > > Sent: Monday, July 24, 2006 11:32 AM
> > > To: ActiveDir@xxxxxxxxxxxxxxxxxx
> > > 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 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=Conf
> > > igur
> > > > 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
> > > parent>
> > > > Allow TEST\Enterprise Admins FULL CONTROL
> > > parent>
> > > >
> > > > Permissions inherited to subobjects are:
> > > > Inherited to all subobjects
> > > > Allow TEST\Domain Admins FULL CONTROL
> > > parent>
> > > > Allow TEST\Enterprise Admins FULL CONTROL
> > > 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> > > > [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf
> Of Matheesha
> > > > Weerasinghe
> > > > Sent: Monday, July 24, 2006 8:12 AM
> > > > To: ActiveDir@xxxxxxxxxxxxxxxxxx
> > > > 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
> > > 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 | | | |
| matheesha
Posts:34
| | 07/26/2006 7:30 AM |
| Thanks Guido. That helps a lot. I was going to create the role
structure but leave them unpopulated and do most of the work myself.
I.e I am all roles!!
I was then going to populate them as and when I found skilled and
trusted chaps. I'll keep it very simple now.
Cheers
M@
P.S. Thanks again to everyone that read and responded.
On 7/26/06, Grillenmeier, Guido wrote:
well, do as you should always do to ensure that your systems are
maintainable: keep it simple!
Don't introduce extra complexity if you don't require it. For AD ACLing
this means, don't introduce roles and permissions for users, if you do
not need that role - there is certainly no need to implement all the
roles that are described in the delegation whitepaper to maintain a
stable AD infrastructure.
most ACLing issues that I have come across was in companies that granted
their delegated admins the rights to create OUs underneath their
location specific OU - soon afterwards they had an AD structure with OUs
and permissions that looked like a badly managed file-server...
so the issue is not so much setting ACLs in AD (which as discussed can
be a complex task to do right, depending on your needs), but more
controlling who is allowed to set ACLs. This should be done centrally by
domain and/or enterprise admins. As a rule of thumb you should not grant
any non-domain or enterprise admin the rights to create OUs and also
limit the rights to create any other objects (especially groups) to very
few delegated admins. Less critical is delegating the ability to manage
existing objects (e.g. to reset PW of user, mail-enable users and
groups, change membership of groups, etc). I also consider the rights to
create computer objects as low risk (which is usually required by local
desktop admins in branch offices).
/Guido
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Matheesha
Weerasinghe
Sent: Tuesday, July 25, 2006 9:18 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] ldp in ADAM-SP1
Thanks to Al and Guido for your further input. Even though it may seem
pretty obvious, I would like to know of any horror stories due to AD
ACL'ing if possible. The reason is Al's comments have made me take a
much more cautious approach to ACL'ing. I get the feeling that even
though the granular feature is there, if there arent enoug people with
the correct skill level available to maintain it, then it shouldnt be
pursued. I hope I can get that skill and that is one fo the goals
here. But I may not be here all the time.....
So any stories from anyone ?
M@
On 7/25/06, Al Mulnick wrote:
>
> I wholeheartedly applaud the effort being put into this. That said, I
urge
> you to reconsider your administrative model and favor as much
simplicity as
> is possible. Why? Because the best laid plans of mice and architects
and
> all that.
>
> "The tricky bit is the matching a trusted and
> appropriately skilled person to the relevant role."
>
> That makes me laugh and cringe at the same time. Yes, it is very
difficult
> to find that "perfect match" but at the same time I think a design
should
> take that into account where possible. That's a design philosophy and
I
> won't debate that for this thread. But I would caution you that any
design
> that has the people intricately relied upon is going to have a failure
point
> at some point when you least can tolerate it.
>
> While you can use the command line tools as much as possible, as joe
and
> Guido both pointed out, consider rolling your own scripts if you
absolutely
> cannot do what you *need* to do at the GUI. But remember you can
really
> really really^^ hurt yourself with security permissions. Believe me,
it can
> be ugly and it can be the undoing.
>
> Two thoughts consider as you walk through the design:
> 1) You should never try to solve wetware issues with software or
hardware.
> 2) Complexity is the anti-security.
>
> Best of luck.
>
>
>
> On 7/25/06, Matheesha Weerasinghe wrote:
> > Wow,
> >
> > Thanks you so much for the detailed info guys. Basically my goal is
> > quite simple. At least it is in my head. What I want to do, is to go
> > through the entire case study given in the AD delegation whitepaper,
> > and do all of that permissions configuration entirely at command
line
> > (where possible). I am willing to use the delegation wizard to some
> > extent, but as I am configuring quite a lot of permissions for an AD
> > design I am involved in, I would rather avoid having to use GUI
tools
> > for this.
> >
> > You see, I am going to end up as been a very privileged service
> > administrator and data administrator once my proposed AD design
model
> > is in place. I expect I will be making some endeavour to train
> > sufficiently capable people in doing this. But I dont plan to spoon
> > feed. I want the guys to know to a decent level ACL'ing and if not,
do
> > their research. At least on an adhoc basis. Then once they
understand
> > whats involved, they can go ahead and add/modify/delete ACE's ,
revoke
> > perms, define new roles etc...
> >
> > Reading this delegation doc has made me believe I can configure an
> > extremely secure delegation model where each role can be given just
> > enough to do that role. The tricky bit is the matching a trusted and
> > appropriately skilled person to the relevant role.
> >
> > So you see, as there is a lot involved and this is a big
> > infrastructure to attempt to administer perms for 20,000 users plus
> > many OUs used to organise users based on the business unit (at least
a
> > dozen in each geographical hub) they work in and the site (we have
> > more than a 40 geographical hubs and 1000 satellite sites) they are
> > located at. Different levels of data admin roles. I would like to
get
> > this right to a large extent from the moment go. Admittedly it may
not
> > be big as in Fortune 5 ADs. But its the biggest I've had the
privilege
> > to design and support.
> >
> > I figured if I test this using the case study as a lab, I will get a
> > good feel of whats involved in my lower level design. I am getting a
> > little miffed when I have to swap between several tools to do what I
> > need to do. There is just so many buts and ifs. "You can do this but
> > you cant do this. To do this use this. For this use that. And then
> > try this. If all else fails script ...."
> >
> > I admit I was ranting a bit when asking why is this named and like
> > such and the discrepencies in the docs and syntax help of command
line
> > tools. My sincere apologies for been anal.
> >
> > Is it too much to ask, to have at the very least a reliable command
> > line or GUI tool (ldp) to configure perms just the way I want and
> > need? Actually I don care even if I have to use a series of command
> > line apps. I dont care how complex it is/willbe right now. I just
want
> > something that works. And I want the tool from MSFT. For free ;0)
> >
> > Please!
> >
> > Cheers
> >
> > M@
> >
> >
> > P.S. thanks once again for reading, for escalating, for laughing,
for
> > educating , the kind words, hugs
> > Control-H,Control-H,Control-H,Control-H,Control-H, etc...
> >
> >
> >
> > On 7/25/06, Grillenmeier, Guido wrote:
> > > I guess Matheesha's original question has been answered as good as
it
> > > can for now with the information given. I just quickly want to
comment
> > > on the 3rd party tool aspect joe is mentioning below - naturally,
before
> > > spending considerable money on the tools, you'd need to test if
they do
> > > what you want them to do in the first place.
> > >
> > > What I've found from many years of leveraging and checking
different
> > > ACLing tools is that they also just go so far... I've had various
> > > different customer requests, which could not be achieved with the
tools,
> > > but could be achieved with the native ACLs (mostly talking AD
here).
> > > After getting over the hurdles of the basics, scripting quickly
becomes
> > > your friend. I am not saying that 3rd party tools aren't quite
useful
> > > for general ACLing stuff - it's when your own security model is
complex,
> > > the tools will often not be able to help you reach your goal.
> > >
> > > Often this is a result of the complex ACLing rules build by MSFT
> > > themselves. Very hard for a developer to keep up with all changes
(think
> > > of all the changes in Win2003 compared to 2000 and then with
Win2003
> > > SP1) and to understand the plethora of rules, especially when it
comes
> > > to combining specific ACLing settings set at totally different
places in
> > > the directory. A great example for this are various options to
> > > controlling delegation of password settings (I've written this up
> > > internally and for my upcoming Windows security book, as joe had
been
> > > pointed at in his other reply). Win2003 provides three new not so
well
> > > known extended rights, which allow domain admins to control which
> > > delegated admin can change critical password attributes on user
> > > accounts:
> > >
> > > * Enable-Per-User-Reversibly-Encrypted-Password
> > > * Unexpire-Password
> > > * Update-Password-Not-Required-Bit
> > >
> > > The challenge: these extended rights are set at the domain level,
while
> > > other permissions to control which delegated admin can do what in
an OU
> > > (e.g. create and manage users) are typically set at the OU level.
So if
> > > you give a delegated admin full control over users, he would for
example
> > > not be able to set the "Password never expires" and the "Store
password
> > > using reversible encryption" options on the user accounts he is
allowed
> > > to fully control, UNLESS he is ALSO granted the appropriate
extended
> > > right at the root of your domain ("Unexpire-Password" and
> > > "Enable-Per-User-Reversibly-Encrypted-Password" in this
> example).
> > >
> > > This is certainly challenging for any domain admininstrator and
moreso
> > > for 3rd party ACLing tools. Realize that by default the three
extended
> > > rights I have mentioned above are granted to Authenticated Users,
which
> > > means that any delegated admin who is also granted the rights to
control
> > > the account restrictions of a user can set the respective password
> > > options. As these are rather sensible settings though, I'd rather
> > > disable any delegated admin from setting them (which is why the
extended
> > > rights have been added to Win2003 in the first place). If you
have
> > > different admins allowed to create users, just check out your
domains
> > > and see how many users are configured with the "password never
expires"
> > > flag - you will quickly understand what I mean.
> > >
> > > But again: it is very tough for 3rd party tools to remove default
rights
> > > for you => they usually just handle adding permissions and it is
up to
> > > you to fully understand the ACLing concepts of Windows to make
> > > everything work correctly.
> > >
> > > /Guido
> > >
> > >
> > > -----Original Message-----
> > > From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> > > [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf
> Of joe
> > > Sent: Monday, July 24, 2006 7:00 PM
> > > To: ActiveDir@xxxxxxxxxxxxxxxxxx
> > > Subject: RE: [ActiveDir] ldp in ADAM-SP1
> > >
> > > 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> > > [mailto: ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf
> Of Matheesha
> > > Weerasinghe
> > > Sent: Monday, July 24, 2006 11:32 AM
> > > To: ActiveDir@xxxxxxxxxxxxxxxxxx
> > > 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 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=Conf
> > > igur
> > > > 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
> > > parent>
> > > > Allow TEST\Enterprise Admins FULL CONTROL
> > > parent>
> > > >
> > > > Permissions inherited to subobjects are:
> > > > Inherited to all subobjects
> > > > Allow TEST\Domain Admins FULL CONTROL
> > > parent>
> > > > Allow TEST\Enterprise Admins FULL CONTROL
> > > 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> > > > [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf
> Of Matheesha
> > > > Weerasinghe
> > > > Sent: Monday, July 24, 2006 8:12 AM
> > > > To: ActiveDir@xxxxxxxxxxxxxxxxxx
> > > > 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
> > > 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
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 | | | |
| dmitrig@xxxx.yyy
| | 07/27/2006 5:46 AM |
| Guido, which changes to you want to see in dsacls in B3?
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Grillenmeier,
Guido
Sent: Tuesday, July 25, 2006 6:22 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] ldp in ADAM-SP1
well, for Win2000 and Win2003 AD that tool is DSACLS for 95% of what you
should need to do. You've already tripped over some of it's limitations
especially around handling the confidential bit - however, I have not
seen many customers that actually leverage the confidential bit yet for
anything else but OS features (for example for PKI credential roaming).
It would be nice to leverage it for many more lockdown scenarios, but
you can't use it for the base schema attributes (category 1), which
includes almost all of the interesting attributes you may want to
restrict access to. Ofcourse you can use it for your own schema
extensions.
For file-system ACLing that tool is CALS or XCACLS - probably for 99% of
what you need to do. Note for the FS you may also want to check out the
betas of either Windows Longhorn or the current Windows 2003 SP2 => they
include a new commandline ACLing tool called Icacls.exe, which can be
used to reset the account control lists (ACL) on files from Recovery
Console, and to back up ACLs. It can also handle replacement of ACLs
(much like subinacl) and works well with either names or SIDs. At last,
unlike Cacls.exe, Icacles.exe preserves canonical ordering of ACEs and
thus correctly propagates changes to and creation of inherited ACLs.
DSACLs has only been updated slightly in LH, but I hope to see some more
changes prior to beta 3.
At last, depending on your requirements, you may also need to look into
changing the default security descriptor of some of the objects (for
example, check out all the default write permissions, which every user
is granted on it's own object via the SELF security principal; many
companies are still unaware of this). You can check these rights most
easily via the schema mgmt mmc (check properties of a class object, such
as user and click on the Default Security tab).
So it's fair to say that although handling ACLs remains to be a complex
topic, you can get most of the things done with existing commandline
tools from MSFT. Sometimes it will simply be more appropriate to use the
UI for a few settings. And there is always the option to script setting
ACLs if you really have special requirements.
As for your delegation model => I would not have the goal to teach your
delegated admins how to do ACLing inside AD. I'm fine with a delegated
admin doing the security on a file-server that he completely manages on
his own. But AD security should be kept in the hand of domain and
enterprise admins (partly because it is rather complex and you only want
few folks to fiddle around with it, partly because it is plain risky to
do it otherwise). The critical piece for most delegation models to
succeed is to build a centrally controlled OU structure (ideally
standardized for your different delegated "admin units" as I like to
call them and not to grant your data admin (= the delegated admins) any
rights to create OUs themselves (otherwise - with the current ACLing
model - you can't prevent them to configure the security of the OU).
Basically the same is true for any objects they create, but it's the OUs
that allow you to manage the security for multiple child objects at once
(and thus these need to be controlled centrally). Many more things to
share in this respect, but no delegation model is the same as any other
so you're best to understand and plan it from the ground up. There may
be similarities between many models, but for the various infrastructures
I've planned, every customer has had their special requirements.
/Guido
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Matheesha
Weerasinghe
Sent: Tuesday, July 25, 2006 9:34 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] ldp in ADAM-SP1
Wow,
Thanks you so much for the detailed info guys. Basically my goal is
quite simple. At least it is in my head. What I want to do, is to go
through the entire case study given in the AD delegation whitepaper, and
do all of that permissions configuration entirely at command line (where
possible). I am willing to use the delegation wizard to some extent, but
as I am configuring quite a lot of permissions for an AD design I am
involved in, I would rather avoid having to use GUI tools for this.
You see, I am going to end up as been a very privileged service
administrator and data administrator once my proposed AD design model is
in place. I expect I will be making some endeavour to train sufficiently
capable people in doing this. But I dont plan to spoon feed. I want the
guys to know to a decent level ACL'ing and if not, do their research. At
least on an adhoc basis. Then once they understand whats involved, they
can go ahead and add/modify/delete ACE's , revoke perms, define new
roles etc...
Reading this delegation doc has made me believe I can configure an
extremely secure delegation model where each role can be given just
enough to do that role. The tricky bit is the matching a trusted and
appropriately skilled person to the relevant role.
So you see, as there is a lot involved and this is a big infrastructure
to attempt to administer perms for 20,000 users plus many OUs used to
organise users based on the business unit (at least a dozen in each
geographical hub) they work in and the site (we have more than a 40
geographical hubs and 1000 satellite sites) they are located at.
Different levels of data admin roles. I would like to get this right to
a large extent from the moment go. Admittedly it may not be big as in
Fortune 5 ADs. But its the biggest I've had the privilege to design and
support.
I figured if I test this using the case study as a lab, I will get a
good feel of whats involved in my lower level design. I am getting a
little miffed when I have to swap between several tools to do what I
need to do. There is just so many buts and ifs. "You can do this but you
cant do this. To do this use this. For this use that. And then try
this. If all else fails script ...."
I admit I was ranting a bit when asking why is this named and like such
and the discrepencies in the docs and syntax help of command line tools.
My sincere apologies for been anal.
Is it too much to ask, to have at the very least a reliable command line
or GUI tool (ldp) to configure perms just the way I want and need?
Actually I don care even if I have to use a series of command line apps.
I dont care how complex it is/willbe right now. I just want something
that works. And I want the tool from MSFT. For free ;0)
Please!
Cheers
M@
P.S. thanks once again for reading, for escalating, for laughing, for
educating , the kind words, hugs
Control-H,Control-H,Control-H,Control-H,Control-H, etc...
On 7/25/06, Grillenmeier, Guido wrote:
> I guess Matheesha's original question has been answered as good as it
> can for now with the information given. I just quickly want to comment
> on the 3rd party tool aspect joe is mentioning below - naturally,
before
> spending considerable money on the tools, you'd need to test if they
do
> what you want them to do in the first place.
>
> What I've found from many years of leveraging and checking different
> ACLing tools is that they also just go so far... I've had various
> different customer requests, which could not be achieved with the
tools,
> but could be achieved with the native ACLs (mostly talking AD here).
> After getting over the hurdles of the basics, scripting quickly
becomes
> your friend. I am not saying that 3rd party tools aren't quite useful
> for general ACLing stuff - it's when your own security model is
complex,
> the tools will often not be able to help you reach your goal.
>
> Often this is a result of the complex ACLing rules build by MSFT
> themselves. Very hard for a developer to keep up with all changes
(think
> of all the changes in Win2003 compared to 2000 and then with Win2003
> SP1) and to understand the plethora of rules, especially when it comes
> to combining specific ACLing settings set at totally different places
in
> the directory. A great example for this are various options to
> controlling delegation of password settings (I've written this up
> internally and for my upcoming Windows security book, as joe had been
> pointed at in his other reply). Win2003 provides three new not so well
> known extended rights, which allow domain admins to control which
> delegated admin can change critical password attributes on user
> accounts:
>
> * Enable-Per-User-Reversibly-Encrypted-Password
> * Unexpire-Password
> * Update-Password-Not-Required-Bit
>
> The challenge: these extended rights are set at the domain level,
while
> other permissions to control which delegated admin can do what in an
OU
> (e.g. create and manage users) are typically set at the OU level. So
if
> you give a delegated admin full control over users, he would for
example
> not be able to set the "Password never expires" and the "Store
password
> using reversible encryption" options on the user accounts he is
allowed
> to fully control, UNLESS he is ALSO granted the appropriate extended
> right at the root of your domain ("Unexpire-Password" and
> "Enable-Per-User-Reversibly-Encrypted-Password" in this example).
>
> This is certainly challenging for any domain admininstrator and moreso
> for 3rd party ACLing tools. Realize that by default the three extended
> rights I have mentioned above are granted to Authenticated Users,
which
> means that any delegated admin who is also granted the rights to
control
> the account restrictions of a user can set the respective password
> options. As these are rather sensible settings though, I'd rather
> disable any delegated admin from setting them (which is why the
extended
> rights have been added to Win2003 in the first place). If you have
> different admins allowed to create users, just check out your domains
> and see how many users are configured with the "password never
expires"
> flag - you will quickly understand what I mean.
>
> But again: it is very tough for 3rd party tools to remove default
rights
> for you => they usually just handle adding permissions and it is up to
> you to fully understand the ACLing concepts of Windows to make
> everything work correctly.
>
> /Guido
>
>
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of joe
> Sent: Monday, July 24, 2006 7:00 PM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> Subject: RE: [ActiveDir] ldp in ADAM-SP1
>
> 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Matheesha
> Weerasinghe
> Sent: Monday, July 24, 2006 11:32 AM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> 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 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=Conf
> igur
> > 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 > parent>
> > Allow TEST\Enterprise Admins FULL CONTROL > parent>
> >
> > Permissions inherited to subobjects are:
> > Inherited to all subobjects
> > Allow TEST\Domain Admins FULL CONTROL > parent>
> > Allow TEST\Enterprise Admins FULL CONTROL > 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> > [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Matheesha
> > Weerasinghe
> > Sent: Monday, July 24, 2006 8:12 AM
> > To: ActiveDir@xxxxxxxxxxxxxxxxxx
> > 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
> 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 | | | |
| GuidoG
Posts:114
| | 07/28/2006 8:06 AM |
| Dmitri,
first of all, I should have added to this thread that there are actually
already a couple of nice changes in DSACLS in Longhorn, which I am glad
do exist:
- it can now be used to set Control Access rights on attributes (for
example with confidential attributes)
- it allows to use SIDs and FQDNs to set/remove ACLs (SID is a major
benefit)
- it supports setting the new OWNER RIGHTS permissions (which can't be
set via the UI right now)
However, the thing I think is still extremely annoying is that you can't
remove single permissions - you always have to remove ALL permissions
for a specific security principal (on the object that you're
processing). This makes it extremely difficult to automate removal of
permissions, as I first need to check all the permissions that an sec
prin has, then remove the one permission that I'd like to remove and at
least re-apply all the permissions that I didn't want to remove. Quite a
pain - would be great to "fix" this.
At last, it would be nice to combine the feature of DSACLS with that of
DSREVOKE. The latter is useful to report on ACLs for a single sec prins
in a whole tree (and to remove them) - however, it is incapable of doing
so for well-known-security-principals such as Authenticated Users or
built-in ones such as Administrators.
Would be lovely to see these changes in B3 ;-)
/Guido
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Dmitri Gavrilov
Sent: Thursday, July 27, 2006 7:46 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] ldp in ADAM-SP1
Guido, which changes to you want to see in dsacls in B3?
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Grillenmeier,
Guido
Sent: Tuesday, July 25, 2006 6:22 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] ldp in ADAM-SP1
well, for Win2000 and Win2003 AD that tool is DSACLS for 95% of what you
should need to do. You've already tripped over some of it's limitations
especially around handling the confidential bit - however, I have not
seen many customers that actually leverage the confidential bit yet for
anything else but OS features (for example for PKI credential roaming).
It would be nice to leverage it for many more lockdown scenarios, but
you can't use it for the base schema attributes (category 1), which
includes almost all of the interesting attributes you may want to
restrict access to. Ofcourse you can use it for your own schema
extensions.
For file-system ACLing that tool is CALS or XCACLS - probably for 99% of
what you need to do. Note for the FS you may also want to check out the
betas of either Windows Longhorn or the current Windows 2003 SP2 => they
include a new commandline ACLing tool called Icacls.exe, which can be
used to reset the account control lists (ACL) on files from Recovery
Console, and to back up ACLs. It can also handle replacement of ACLs
(much like subinacl) and works well with either names or SIDs. At last,
unlike Cacls.exe, Icacles.exe preserves canonical ordering of ACEs and
thus correctly propagates changes to and creation of inherited ACLs.
DSACLs has only been updated slightly in LH, but I hope to see some more
changes prior to beta 3.
At last, depending on your requirements, you may also need to look into
changing the default security descriptor of some of the objects (for
example, check out all the default write permissions, which every user
is granted on it's own object via the SELF security principal; many
companies are still unaware of this). You can check these rights most
easily via the schema mgmt mmc (check properties of a class object, such
as user and click on the Default Security tab).
So it's fair to say that although handling ACLs remains to be a complex
topic, you can get most of the things done with existing commandline
tools from MSFT. Sometimes it will simply be more appropriate to use the
UI for a few settings. And there is always the option to script setting
ACLs if you really have special requirements.
As for your delegation model => I would not have the goal to teach your
delegated admins how to do ACLing inside AD. I'm fine with a delegated
admin doing the security on a file-server that he completely manages on
his own. But AD security should be kept in the hand of domain and
enterprise admins (partly because it is rather complex and you only want
few folks to fiddle around with it, partly because it is plain risky to
do it otherwise). The critical piece for most delegation models to
succeed is to build a centrally controlled OU structure (ideally
standardized for your different delegated "admin units" as I like to
call them and not to grant your data admin (= the delegated admins) any
rights to create OUs themselves (otherwise - with the current ACLing
model - you can't prevent them to configure the security of the OU).
Basically the same is true for any objects they create, but it's the OUs
that allow you to manage the security for multiple child objects at once
(and thus these need to be controlled centrally). Many more things to
share in this respect, but no delegation model is the same as any other
so you're best to understand and plan it from the ground up. There may
be similarities between many models, but for the various infrastructures
I've planned, every customer has had their special requirements.
/Guido
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Matheesha
Weerasinghe
Sent: Tuesday, July 25, 2006 9:34 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] ldp in ADAM-SP1
Wow,
Thanks you so much for the detailed info guys. Basically my goal is
quite simple. At least it is in my head. What I want to do, is to go
through the entire case study given in the AD delegation whitepaper, and
do all of that permissions configuration entirely at command line (where
possible). I am willing to use the delegation wizard to some extent, but
as I am configuring quite a lot of permissions for an AD design I am
involved in, I would rather avoid having to use GUI tools for this.
You see, I am going to end up as been a very privileged service
administrator and data administrator once my proposed AD design model is
in place. I expect I will be making some endeavour to train sufficiently
capable people in doing this. But I dont plan to spoon feed. I want the
guys to know to a decent level ACL'ing and if not, do their research. At
least on an adhoc basis. Then once they understand whats involved, they
can go ahead and add/modify/delete ACE's , revoke perms, define new
roles etc...
Reading this delegation doc has made me believe I can configure an
extremely secure delegation model where each role can be given just
enough to do that role. The tricky bit is the matching a trusted and
appropriately skilled person to the relevant role.
So you see, as there is a lot involved and this is a big infrastructure
to attempt to administer perms for 20,000 users plus many OUs used to
organise users based on the business unit (at least a dozen in each
geographical hub) they work in and the site (we have more than a 40
geographical hubs and 1000 satellite sites) they are located at.
Different levels of data admin roles. I would like to get this right to
a large extent from the moment go. Admittedly it may not be big as in
Fortune 5 ADs. But its the biggest I've had the privilege to design and
support.
I figured if I test this using the case study as a lab, I will get a
good feel of whats involved in my lower level design. I am getting a
little miffed when I have to swap between several tools to do what I
need to do. There is just so many buts and ifs. "You can do this but you
cant do this. To do this use this. For this use that. And then try
this. If all else fails script ...."
I admit I was ranting a bit when asking why is this named and like such
and the discrepencies in the docs and syntax help of command line tools.
My sincere apologies for been anal.
Is it too much to ask, to have at the very least a reliable command line
or GUI tool (ldp) to configure perms just the way I want and need?
Actually I don care even if I have to use a series of command line apps.
I dont care how complex it is/willbe right now. I just want something
that works. And I want the tool from MSFT. For free ;0)
Please!
Cheers
M@
P.S. thanks once again for reading, for escalating, for laughing, for
educating , the kind words, hugs
Control-H,Control-H,Control-H,Control-H,Control-H, etc...
On 7/25/06, Grillenmeier, Guido wrote:
> I guess Matheesha's original question has been answered as good as it
> can for now with the information given. I just quickly want to comment
> on the 3rd party tool aspect joe is mentioning below - naturally,
before
> spending considerable money on the tools, you'd need to test if they
do
> what you want them to do in the first place.
>
> What I've found from many years of leveraging and checking different
> ACLing tools is that they also just go so far... I've had various
> different customer requests, which could not be achieved with the
tools,
> but could be achieved with the native ACLs (mostly talking AD here).
> After getting over the hurdles of the basics, scripting quickly
becomes
> your friend. I am not saying that 3rd party tools aren't quite useful
> for general ACLing stuff - it's when your own security model is
complex,
> the tools will often not be able to help you reach your goal.
>
> Often this is a result of the complex ACLing rules build by MSFT
> themselves. Very hard for a developer to keep up with all changes
(think
> of all the changes in Win2003 compared to 2000 and then with Win2003
> SP1) and to understand the plethora of rules, especially when it comes
> to combining specific ACLing settings set at totally different places
in
> the directory. A great example for this are various options to
> controlling delegation of password settings (I've written this up
> internally and for my upcoming Windows security book, as joe had been
> pointed at in his other reply). Win2003 provides three new not so well
> known extended rights, which allow domain admins to control which
> delegated admin can change critical password attributes on user
> accounts:
>
> * Enable-Per-User-Reversibly-Encrypted-Password
> * Unexpire-Password
> * Update-Password-Not-Required-Bit
>
> The challenge: these extended rights are set at the domain level,
while
> other permissions to control which delegated admin can do what in an
OU
> (e.g. create and manage users) are typically set at the OU level. So
if
> you give a delegated admin full control over users, he would for
example
> not be able to set the "Password never expires" and the "Store
password
> using reversible encryption" options on the user accounts he is
allowed
> to fully control, UNLESS he is ALSO granted the appropriate extended
> right at the root of your domain ("Unexpire-Password" and
> "Enable-Per-User-Reversibly-Encrypted-Password" in this example).
>
> This is certainly challenging for any domain admininstrator and moreso
> for 3rd party ACLing tools. Realize that by default the three extended
> rights I have mentioned above are granted to Authenticated Users,
which
> means that any delegated admin who is also granted the rights to
control
> the account restrictions of a user can set the respective password
> options. As these are rather sensible settings though, I'd rather
> disable any delegated admin from setting them (which is why the
extended
> rights have been added to Win2003 in the first place). If you have
> different admins allowed to create users, just check out your domains
> and see how many users are configured with the "password never
expires"
> flag - you will quickly understand what I mean.
>
> But again: it is very tough for 3rd party tools to remove default
rights
> for you => they usually just handle adding permissions and it is up to
> you to fully understand the ACLing concepts of Windows to make
> everything work correctly.
>
> /Guido
>
>
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of joe
> Sent: Monday, July 24, 2006 7:00 PM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> Subject: RE: [ActiveDir] ldp in ADAM-SP1
>
> 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Matheesha
> Weerasinghe
> Sent: Monday, July 24, 2006 11:32 AM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> 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 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=Conf
> igur
> > 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 > parent>
> > Allow TEST\Enterprise Admins FULL CONTROL > parent>
> >
> > Permissions inherited to subobjects are:
> > Inherited to all subobjects
> > Allow TEST\Domain Admins FULL CONTROL > parent>
> > Allow TEST\Enterprise Admins FULL CONTROL > 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> > [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Matheesha
> > Weerasinghe
> > Sent: Monday, July 24, 2006 8:12 AM
> > To: ActiveDir@xxxxxxxxxxxxxxxxxx
> > 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
> 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
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 | | | |
|
|