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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of joe
Sent: Monday, July 24, 2006 7:00 PM
To: ActiveDir@mail.activedir.org
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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Matheesha
Weerasinghe
Sent: Monday, July 24, 2006 11:32 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] ldp in ADAM-SP1
I dunno about you guys but I am very disappointed with the tools
available to me for configuring perms. dsacls can configure most perms
but cant configure control access rights to certain attribs of certain
objects. (e.g. when you configure an attribute as confidential and
need to allow certain people the control access right to view the
attribute). dsacls also cant display perms that great and gives
details as "special access". In order to see whats special, I have to
use something like acldiag and sdcheck. And then to revoke, yet
another tool dsrevoke which only works on domain objects and OUs.
After reading joe's book I figured ldp.exe from ADAM-SP1, here I come.
Now that also has issues.
I know I can write scripts for handling this. But they are cumbersome
and slow. I think a nice fast C++ tool that does all this would be
much appreciated. I am not sure how hard this is to do. But MSFT
certaintly have the expertise. May be longhorn will ship with
something like that. But I aint holding my breath.
I am no expert and no MVP. I aint convinced my rant is gonna be heeded
to. But please, guys out there with the influence (MVPs) help!!
M@
P.S Please!!!
On 7/24/06, joe <[EMAIL PROTECTED]> wrote:
> Beautiful, this is bug week....
>
> There are actually two bugs here.
>
> 1. The inherit only check box is greyed out. This is the checkbox you
would
> need to check in order to specify an inherit only ACE (i.e. Child
Objects
> Only).
>
> 2. When you try to work around it and specify the actual object types
to
> inherit to it creates two ACEs instead of one. The first ACE is the FC
> inherit only to the object class you specify but then there is also a
FC
to
> the object itself. In the example below note the TEST\joe ACEs... I
only
> added a single FC for nTDSConnection objects for test\joe but got that
AND
> the non-inheritable Test\joe FC on the object itself.
>
>
> G:\>dsacls "\\r2dc1\CN=NTDS
>
Settings,CN=R2DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=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 <Inherited from
> parent>
> Allow TEST\Enterprise Admins FULL CONTROL <Inherited from
> parent>
>
> Permissions inherited to subobjects are:
> Inherited to all subobjects
> Allow TEST\Domain Admins FULL CONTROL <Inherited from
> parent>
> Allow TEST\Enterprise Admins FULL CONTROL <Inherited from
> parent>
>
> Inherited to nTDSConnection
> Allow TEST\joe FULL CONTROL
> The command completed successfully
>
>
>
> So in order to generate a generic FC that is only inherited, you
can't,
> because of bug 1 do it with LDP. If you want to create an ACE for a
specific
> objectclass (which nTDSConnection should be ok in terms of what you
are
> trying to delegate) it can do it but you have to go back and clean up
the
> the additional ACE created by bug 2.
>
>
> I will alert MSFT.
>
> joe
>
>
>
>
> --
> O'Reilly Active Directory Third Edition -
> http://www.joeware.net/win/ad3e.htm
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Matheesha
> Weerasinghe
> Sent: Monday, July 24, 2006 8:12 AM
> To: ActiveDir@mail.activedir.org
> 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
