| Author | Messages | |
matheesha
Posts:34
 | | 07/29/2006 9:49 AM |
| "SDDL import/export is a good idea."
And this has already been done for the file-system ;-) The new icacls
tool basically replaces cacls (which still exists) and besides allowing saving
and restoring ACLs on files / folders it also has much better support for ACL
inheritance. The good news is that icacls has been backported to Win2003 and
will be made available with SP2.
Agree this would be a
/Guido
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On
Behalf Of Dmitri Gavrilov
Sent: Saturday, July 29, 2006 12:49 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] ldp in ADAM-SP1
Removing an ACE by index won't work, because you don't know what
this index will point to when you run dsacls second time (somebody could have
updated the SD meanwhile). But removing the specific ACE given its parameters
should be possible.
SDDL import/export is a good idea.
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On
Behalf Of Matheesha Weerasinghe
Sent: Friday, July 28, 2006 2:38 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] ldp in ADAM-SP1
Erm... would it be too much to
ask for an undo or import SD from backup option? Not for me personally, but I
think plenty of others might find it handy ;-)
Also as its possible to use scripts or ldp to remove individual ACE's , can
this not be included in dsacls? For example I would like to be able to list the
acls in sddl format and get a list of
ace(00)blah blah blah
ace(01)blah blah blah
ace(02)blah blah blah
ace(03)blah blah blah
And then do something like
dsacls fqdn_of_obj /RemoveACE=ACE(01)
I guess it goes a long way towards something Guido wants with removing
individual permissions. It certaintly helps if some of the individual perms are
seperate ACE's
Could someone explain why dsrevoke only targets domain objects and OUs? Is it
technically much harder to write something that did the same for config
partition objects?
Cheers
M@
On 7/28/06, Dmitri Gavrilov
wrote:
Thanks Guido,
Nice requests, but not small. So, no promises for LH, it is getting
late. I'll get these filed.
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of Grillenmeier,
Guido
Sent: Friday, July 28, 2006 1:06 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] ldp in ADAM-SP1
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
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/29/2006 10:08 AM |
| To explain what Guido is saying.....
So buy the book now!!! Don't wait until it is too late to help you out!!!
Thanks Guido, nice angle, I hadn't thought of that one...
For retirement money I would consider specifying some other ways it can be
done that will work on later OSes... :o) It has to be enough retirement
money to buy an island or something though, because if I keep talking, ~Eric
will probably try to come find and kill me. Not because he told me how to do
any of it, but because he is very clear on the fact that setting cat-1
attributes to confidential is a strictly untested condition as I am quite
clear on that point in the book as well. :) Personally, I think everything
around confidential bits is a bad idea.
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 Grillenmeier, Guido
Sent: Saturday, July 29, 2006 4:22 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] ldp in ADAM-SP1
"Or buy the book in the signature and find out how to step around this
limitation... ;)"
well, as I know this workaround I'd comment that it's none of long-term
value. At some point you're going to be faced with upgrading your forest
to a new Windows Server release and then you won't have the luxury of
allowing an older Win2003 DC to exist in your infrastructure (just to
mange confidential bits that the updated and newer DCs won't let you
set...). Unless ofcourse, you don't want to leverage the new features of
the new WinOS...
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of joe
Sent: Saturday, July 29, 2006 9:13 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] ldp in ADAM-SP1
> 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.
Or buy the book in the signature and find out how to step around this
limitation... ;)
> 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).
I agree with this and take it a step further. If you are constantly
adding
new sites or what not that need special ACEs that aren't handled through
inheritence from existing structures I highly, no SUPER HIGHLY recommend
spending a good amount of time and scripting the creation of those
structures and those ACL changes. Yes this means actually have some form
of
fixed structure. This irks a lot of people but ad hoc OU structures do
not
work well in large orgs. It is a mess to figure out what is going on
when
you do that and at someone point, someone always wants to know what is
going
on. Plus if done that way, it certainly is a lot more efficient to do
that
work. In the widget company I immediately put together a script to do
that
stuff and an OU structure that exists for every building in the company
that
has something like 10 or 12 subous and several groups and lots of
special
permissions is created in less than a minute correctly each time. By
hand,
you would be talking 15+ minutes of work and who knows what would be
screwed
up. Plus... If something happened and all of the ACLs somehow got
torched,
you can run the script for each of the building OUs and everything is
re-ACLed again.
I didn't just start doing that on AD, I have done that on NTFS file
systems
for years because I was often asked as far back as the mid-90's who had
access to what and where so I made sure that the permissioning model was
shallow and simple. For instance in a project shared folder everyone had
access to the top level, and then there was usually 2 groups for every
top
level folder under that shared folder, one for READ, one for CHANGE. You
were in one group or the other and there was no other ACLing below that
first folder level. It is much easier to put back together and very
simple
to work out who has access to what.
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 Grillenmeier,
Guido
Sent: Tuesday, July 25, 2006 9: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
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/29/2006 10:40 AM |
| ¦except the joeware tools of course ;-)
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On
Behalf Of joe
Sent: Saturday, July 29, 2006 9:43 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] ldp in ADAM-SP1
Hey now... my freeware tombstone reanimation tool works fine
against the config container except for a little bug that exists in AD around
undeleting certain items in the config. Actually it should work fine against
the schema container as well.
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 Grillenmeier,
Guido
Sent: Saturday, July 29, 2006 11:47 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] ldp in ADAM-SP1
Rgd. your question if building something such as dsrevoke is harder
to build for the config partition than for the domain partitions: don™t think
it™s a matter of being harder to implement or not “ it was merely a design
decision not to make it work for the config partition, as you could f***-up
your complete forest much easier here than you can by removing permissions in
the domain partition¦
There are quite a few other tools (the freeware tombstone
reanimation tools come to my mind) that also only work against the domain
partitions of a DC.
/Guido
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On
Behalf Of Matheesha Weerasinghe
Sent: Saturday, July 29, 2006 11:50 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] ldp in ADAM-SP1
I agree on the deleting an ACE
by index wont work 100% all the time. That is why I suggested the ACE index
view first and then choosing the correct index. And the backup option in case
someone else (not me) f***d up.
Hmm... icacls eh? Must see how that fares against setacl.
I'd appreciate a comment on my dsrevoke query too.
Cheers
M@
On 7/29/06, Grillenmeier, Guido guido.grillenmeier@xxxxxx>
wrote:
"SDDL import/export is a good idea."
And this has already been done for
the file-system ;-) The new icacls tool basically replaces cacls
(which still exists) and besides allowing saving and restoring ACLs on files /
folders it also has much better support for ACL inheritance. The good
news is that icacls has been backported to Win2003 and will be made available
with SP2.
Agree this would be a
/Guido
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Dmitri Gavrilov
Sent: Saturday, July 29, 2006 12:49 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] ldp in ADAM-SP1
Removing an ACE by index won't
work, because you don't know what this index will point to when you run dsacls
second time (somebody could have updated the SD meanwhile). But removing the
specific ACE given its parameters should be possible.
SDDL import/export is a good
idea.
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Matheesha
Weerasinghe
Sent: Friday, July 28, 2006 2:38 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] ldp in ADAM-SP1
Erm... would it be too much to ask for an undo
or import SD from backup option? Not for me personally, but I think plenty of
others might find it handy ;-)
Also as its possible to use scripts or ldp to remove individual ACE's , can
this not be included in dsacls? For example I would like to be able to list the
acls in sddl format and get a list of
ace(00)blah blah blah
ace(01)blah blah blah
ace(02)blah blah blah
ace(03)blah blah blah
And then do something like
dsacls fqdn_of_obj /RemoveACE=ACE(01)
I guess it goes a long way towards something Guido wants with removing
individual permissions. It certaintly helps if some of the individual perms are
seperate ACE's
Could someone explain why dsrevoke only targets domain objects and OUs? Is it
technically much harder to write something that did the same for config
partition objects?
Cheers
M@
On 7/28/06, Dmitri Gavrilov dmitrig@xxxxxxxxxxxxxxxxxxxxx>
wrote:
Thanks Guido,
Nice requests, but not small. So, no promises for LH, it is getting
late. I'll get these filed.
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of Grillenmeier,
Guido
Sent: Friday, July 28, 2006 1:06 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] ldp in ADAM-SP1
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 guido.grillenmeier@xxxxxx> 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
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/30/2006 12:17 PM |
| joeware tools excepted in most cases of course ;)
On 7/29/06, joe wrote:
I am curious about this statement
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.
In general, scripts are more dangerous than the command line tools because there are a lot of screwups you can make in a script that a tool may not make because hopefully a full blown tool writer understand the permissioning model and the dev work behind it than a script writer. It is quite easy to use a script and to add 30 duplicate ACEs to an ACL. I can't count the number of times I have seen things like that. There is no guarantee that a commandline tool won't do the same but there are fewer and hopefully more experienced people writing command line tools than scripts.
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: Tuesday, July 25, 2006 9:19 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxxSubject:
Re: [ActiveDir] ldp in ADAM-SP1
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 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.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspxList archive:
http://www.activedir.org/ml/threads.aspx | | | |
| ken
Posts:173
| | 07/31/2006 2:05 AM |
| Hi Al,
I™m going to have to disagree here. I™d wager that the average
programmer has a better understanding of writing code that has:
a)
proper specifications and design
b)
robust error handling
c)
strong typing
d)
etc
Of course, there are always deadlines that result in shoddy
code, and there are certainly some shoddy programmers. But the average scripter
(in my experience) seems to have far fewer clues on how to write robust,
reusable, defensive code than the average programmer. The average scripter
doesn™t know much about IDEs, debugging, source control, unit tests and all the
other goodies that make maintaining large bodies of code easy.
There™s nothing wrong with writing scripts “ especially for
things that just require a few lines of code. Trying to maintain something that
has 1000+ lines of code is a nightmare when scripted using VBS/JScript
Cheers
Ken
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On
Behalf Of Al Mulnick
Sent: Sunday, 30 July 2006 10:17 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] ldp in ADAM-SP1
I have to say that's weak logic joe. Well, good logic,
but weak assumptions.
Tool writers are no more likely to prevent unforseen
mistakes than a script writer. On the plus side, if you write your own script,
you'll have plenty of time to test it and will have gained a great deal more
knowledge than you previously had. Mostly about how not to do it, but that's
better than figuring that out in production or worse, trusting the tool writer
to have done the work for you and to have guessed what you wanted done.
joeware tools excepted in most cases of course ;)
On 7/29/06, joe listmail@xxxxxxxxxxx> wrote:
I am curious about this statement
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.
In general, scripts are more dangerous than the command line tools
because there are a lot of screwups you can make in a script that a tool may
not make because hopefully a full blown tool writer understand the
permissioning model and the dev work behind it than a script writer. It is
quite easy to use a script and to add 30 duplicate ACEs to an ACL. I can't
count the number of times I have seen things like that. There is no guarantee
that a commandline tool won't do the same but there are fewer and hopefully
more experienced people writing command line tools than scripts.
joe
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm | | | |
| amulnick
Posts:163
| | 07/31/2006 5:54 AM |
| At the end of it all, it really comes down to the right tool for the job. I see no difference between a person writing a script to get something done and somebody writing a tool that the person who otherwise would have written a script would now have to write a batch file to use. Not sure the best written tool would be any better and the person writing the batch "wrapper" would have even less understanding of the underpinnings of the tasks than they would if they wrote the script.
C'est la vie, no?
On 7/30/06, Ken Schaefer wrote:
Hi Al,
I'm going to have to disagree here. I'd wager that the average programmer has a better understanding of writing code that has:
a) proper specifications and design
b) robust error handling
c) strong typing
d) etc
Of course, there are always deadlines that result in shoddy code, and there are certainly some shoddy programmers. But the average scripter (in my experience) seems to have far fewer clues on how to write robust, reusable, defensive code than the average programmer. The average scripter doesn't know much about IDEs, debugging, source control, unit tests and all the other goodies that make maintaining large bodies of code easy.
There's nothing wrong with writing scripts “ especially for things that just require a few lines of code. Trying to maintain something that has 1000+ lines of code is a nightmare when scripted using VBS/JScript
Cheers
Ken
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Al MulnickSent:
Sunday, 30 July 2006 10:17 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: Re: [ActiveDir] ldp in ADAM-SP1
I have to say that's weak logic joe. Well, good logic, but weak assumptions.
Tool writers are no more likely to prevent unforseen mistakes than a script writer. On the plus side, if you write your own script, you'll have plenty of time to test it and will have gained a great deal more knowledge than you previously had. Mostly about how not to do it, but that's better than figuring that out in production or worse, trusting the tool writer to have done the work for you and to have guessed what you wanted done.
joeware tools excepted in most cases of course ;)
On 7/29/06, joe wrote:
I am curious about this statement
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.
In general, scripts are more dangerous than the command line tools because there are a lot of screwups you can make in a script that a tool may not make because hopefully a full blown tool writer understand the permissioning model and the dev work behind it than a script writer. It is quite easy to use a script and to add 30 duplicate ACEs to an ACL. I can't count the number of times I have seen things like that. There is no guarantee that a commandline tool won't do the same but there are fewer and hopefully more experienced people writing command line tools than scripts.
joe
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm | | | |
| listmail
Posts:824
| | 07/31/2006 12:23 PM |
| I don't agree with you Al. Sure not all tool writers will
be better than all script writers but I think it would be weighted towards
most tool writers having a sounder understanding than most script writers.
Consider that script writers can be the person who just found the AD Cookbook
website and started scripting that day.
I agree on the possible benefits of scripting writing
though.
Back to tools, I wouldn't expect that the tool writer
should guess what you want done but should be aware of the proper way to do
something. This can backfire on you though when new functionality gets added,
say that control access on an attribute actually means something now and the
tools that didn't allow that because it was an invalid state are now all wrong
because it is valid. But prior to that for the previous 5 or so users, it could
have prevented people from adding worthless ACEs...
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: Saturday, July 29, 2006 8:17 PMTo:
ActiveDir@xxxxxxxxxxxxxxxxxxSubject: Re: [ActiveDir] ldp in
ADAM-SP1
I have to say that's weak logic joe. Well, good logic, but weak
assumptions.
Tool writers are no more likely to prevent unforseen mistakes than a script
writer. On the plus side, if you write your own script, you'll have plenty of
time to test it and will have gained a great deal more knowledge than you
previously had. Mostly about how not to do it, but that's better than figuring
that out in production or worse, trusting the tool writer to have done the work
for you and to have guessed what you wanted done.
joeware tools excepted in most cases of course ;)
On 7/29/06, joe
wrote:
I am
curious about this statement
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.
In
general, scripts are more dangerous than the command line tools because there
are a lot of screwups you can make in a script that a tool may not make
because hopefully a full blown tool writer understand the permissioning model
and the dev work behind it than a script writer. It is quite easy to use a
script and to add 30 duplicate ACEs to an ACL. I can't count the number of
times I have seen things like that. There is no guarantee that a commandline
tool won't do the same but there are fewer and hopefully more experienced
people writing command line tools than scripts.
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: Tuesday, July 25, 2006 9:19 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: Re:
[ActiveDir] ldp in ADAM-SP1
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 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 matheesha@xxxxxxxxx >
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
guido.grillenmeier@xxxxxx > 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 listmail@xxxxxxxxxxx
> 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.aspxList archive: http://www.activedir.org/ml/threads.aspx | | | |
| lists1
Posts:6
| | 08/04/2006 7:25 AM |
| Hi Dmitri,
And DSAcls still does not display a computer accounts ACL if someone was
being delegated permission to join a computer to this account using ADUC:
http://www.windowsserverfaq.org/faq/CompACLs.asp
Gruesse - Sincerely,
Ulf B. Simon-Weidner
Profile & Publications:
http://mvp.support.microsoft.com/profile=35E388DE-4885-4308-B489-F2F1214C811
D
Weblog: http://msmvps.org/UlfBSimonWeidner
Website: http://www.windowsserverfaq.org
-----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 | | | |
| lists1
Posts:6
| | 09/30/2006 10:41 AM |
| Just stepped across this - thanks for fixing it!
Ulf
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Ulf B.
Simon-Weidner
Sent: Freitag, 4. August 2006 09:26
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] ldp in ADAM-SP1
Hi Dmitri,
And DSAcls still does not display a computer accounts ACL if someone was
being delegated permission to join a computer to this account using ADUC:
http://www.windowsserverfaq.org/faq/CompACLs.asp
Gruesse - Sincerely,
Ulf B. Simon-Weidner
Profile & Publications:
http://mvp.support.microsoft.com/profile=35E388DE-4885-4308-B489-F2F1214C811
D
Weblog: http://msmvps.org/UlfBSimonWeidner
Website: http://www.windowsserverfaq.org
-----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
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 | | | |
|
|