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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Matheesha
Weerasinghe
Sent: Tuesday, July 25, 2006 9:18 PM
To: ActiveDir@mail.activedir.org
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[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
> >
>
>
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
