| Author | Messages | |
rmscheck
Posts:66
 | | 05/02/2008 7:21 AM |
| Hey folks,
I am trying to lock down an AD tree using specific ACLs, however, I have been noticing that each part I lock down ends up with a long string of ACLs. Is this good for AD health?
Primarily specific OUs are tailored for Accounts, and Computers. For instance I am attempting to lock down the Accounts OU such that an IT person can only unlock, disable, reset password, edit description, title, manager, etc. For each access I am using either dsacl or the GUI. But I am beginning to see the OU ACL list turn into a mess. Am I better off just allowing by property set.. Personal Information, Public Information, etc? The only problem with that is that they include attributes I dont particularly wants users to edit, and vice versa, they are missing those I want.
How do you folks lock down AD trees?
---------------------------------
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
| | | |
| danholme
Posts:133
| | 05/03/2008 4:39 PM |
| Agreed 100% with Joe, but to address part of your question, the reality
is you WILL end up with additional ACEs in your ACLs to 'open up'
delegation to support the model you do want, whatever that is. Because
you're dealing with object and attribute permissions, the ACL will end
up being "long." But "long" is relative... you should be less concerned
about "length" and more concerned about "optimization." i.e. you want
to create ACLs that balance out achieving your goals with not
over-inundating AD with ACEs.
Also keep in mind that AD "single instances" permissions, so that if you
have a "long" (whatever that means to you) ACL on a upper-level OU,
objects will not have "duplicate" long ACLs below that-they will refer
to the single instance of that ACL. I'm simplifying, and one of the
other posters can expand on or correct this as needs be.
Bottom line is that if you MANAGE your delegation, and if your OU design
truly reflects security/delegation/ACL propagation (whatever you choose
to call it), you'll have an optimized result. This sounds *exactly*
like what you *are* doing, so it sounds like you're heading in the right
direction. FWIW I haven't had a whole lot of luck with property sets
for the very reasons you mention.
The two things I'd generalize out of my large delegations are:
1) Create a role-based delegation so that, after you have created
your OUs and ACL'ed them, you never have to touch them again and can
instead manage delegation with group memberships. It helps A LOT -
beyond words - and is an amazing help when it comes time for audits,
compliance reports, etc.
2) As joe said, look at provisioning/proxying tools to alleviate
the burden of AD delegation. Basic idea is that you have a service/tool
that runs with (broad) rights to make changes to AD. The tool
abstracts/manages the delegation. Admins can use the tool, but are
*not* delegated rights to perform the tasks in AD directly. This not
only simplifies AD ACLs but also enables the injection of business
logic, richer auditing, and self-service. I have a tool we built for
one client (10k seats) that is a simple, but very effective example.
Feel free to ping me off line if you'd like details.
Dan
Dan Holme
dan.holme@intelliem.com
www.intelliem.com
Phone: 415.670.9360 (finds me)
Land: 808.573.0726
Mobile: 602.295.1692
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of joe
Sent: Friday, May 02, 2008 4:38 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] AD Delegation = ACL Mess
Well by default, unless you are being too free with your builtin groups
AD is pretty locked down by default right? You have to actually open it
up for people to do things.
You should think of this as what exactly are you trying to allow, not
what are you trying to block. If the delegation model is extension,
possibly look into some sort of proxydelegation tool of some sort and
delegate permissions there.
With users, anymore, everyone should be looking at provisioning tools,
metadirectory systems, and self service type configurations. There
shouldn't be a lot of need for manual add/delete/updates.
But yes, you don't want to bloat your directory with ACEs, it can impact
perf at some level depending on how deep and long the ACL chains are.
This is much better in K3 than it was in 2K but it doesn't mean you
should do it. Also think of complexity... the more ACE's in place on the
ACL's, the more complexity in trying to work out who can do what in any
reasonable time frame.
joe
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
________________________________
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Rand Salazar
Sent: Friday, May 02, 2008 7:22 AM
To: Active Dir
Subject: [ActiveDir] AD Delegation = ACL Mess
Hey folks,
I am trying to lock down an AD tree using specific ACLs, however, I have
been noticing that each part I lock down ends up with a long string of
ACLs. Is this good for AD health?
Primarily specific OUs are tailored for Accounts, and Computers. For
instance I am attempting to lock down the Accounts OU such that an IT
person can only unlock, disable, reset password, edit description,
title, manager, etc. For each access I am using either dsacl or the
GUI. But I am beginning to see the OU ACL list turn into a mess. Am I
better off just allowing by property set.. Personal Information, Public
Information, etc? The only problem with that is that they include
attributes I dont particularly wants users to edit, and vice versa, they
are missing those I want.
How do you folks lock down AD trees?
________________________________
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try
it now.
<http://us.rd.yahoo.com/evt=51733/*http:/mobile.yahoo.com/;_ylt=Ahu06i62
sR8HDtDypao8Wcj9tAcJ%20>
| | | |
| bdesmond
Posts:374
| | 05/03/2008 10:57 PM |
| The single instancing will help you with DIT size, but, it won't take care
of the management mess of complicated ACLs. I haven't read this whole thread
so I don't know if that's the issue that's being discussed. The single
instacning saved some folks I believe it was ~40% of their DIT size from a
2k vs 2k3 DIT.
--brian
On Sat, May 3, 2008 at 4:34 PM, Dan Holme <dan.holme@intelliem.com> wrote:
> Agreed 100% with Joe, but to address part of your question, the reality
> is you WILL end up with additional ACEs in your ACLs to 'open up' delegation
> to support the model you do want, whatever that is. Because you're dealing
> with object and attribute permissions, the ACL will end up being "long."
> But "long" is relative… you should be less concerned about "length" and more
> concerned about "optimization." i.e. you want to create ACLs that balance
> out achieving your goals with not over-inundating AD with ACEs.
>
>
>
> Also keep in mind that AD "single instances" permissions, so that if you
> have a "long" (whatever that means to you) ACL on a upper-level OU, objects
> will not have "duplicate" long ACLs below that—they will refer to the single
> instance of that ACL. I'm simplifying, and one of the other posters can
> expand on or correct this as needs be.
>
>
>
> Bottom line is that if you MANAGE your delegation, and if your OU design
> truly reflects security/delegation/ACL propagation (whatever you choose to
> call it), you'll have an optimized result. This sounds **exactly** like
> what you **are** doing, so it sounds like you're heading in the right
> direction. FWIW I haven't had a whole lot of luck with property sets for
> the very reasons you mention.
>
>
>
> The two things I'd generalize out of my large delegations are:
>
>
>
> 1) Create a role-based delegation so that, after you have created
> your OUs and ACL'ed them, you never have to touch them again and can instead
> manage delegation with group memberships. It helps A LOT – beyond words –
> and is an amazing help when it comes time for audits, compliance reports,
> etc.
>
> 2) As joe said, look at provisioning/proxying tools to alleviate the
> burden of AD delegation. Basic idea is that you have a service/tool that
> runs with (broad) rights to make changes to AD. The tool abstracts/manages
> the delegation. Admins can use the tool, but are **not** delegated rights
> to perform the tasks in AD directly. This not only simplifies AD ACLs but
> also enables the injection of business logic, richer auditing, and
> self-service. I have a tool we built for one client (10k seats) that is a
> simple, but very effective example. Feel free to ping me off line if you'd
> like details.
>
>
>
>
>
> Dan
>
> Dan Holme
>
> dan.holme@intelliem.com
>
> www.intelliem.com
>
> Phone: 415.670.9360 (finds me)
>
> Land: 808.573.0726
>
> Mobile: 602.295.1692
>
>
>
>
>
>
>
> *From:* ActiveDir-owner@mail.activedir.org [mailto:
> ActiveDir-owner@mail.activedir.org] *On Behalf Of *joe
> *Sent:* Friday, May 02, 2008 4:38 PM
> *To:* ActiveDir@mail.activedir.org
> *Subject:* RE: [ActiveDir] AD Delegation = ACL Mess
>
>
>
> Well by default, unless you are being too free with your builtin groups AD
> is pretty locked down by default right? You have to actually open it up for
> people to do things.
>
>
>
> You should think of this as what exactly are you trying to allow, not what
> are you trying to block. If the delegation model is extension, possibly look
> into some sort of proxydelegation tool of some sort and delegate permissions
> there.
>
>
>
> With users, anymore, everyone should be looking at provisioning tools,
> metadirectory systems, and self service type configurations. There shouldn't
> be a lot of need for manual add/delete/updates.
>
>
>
> But yes, you don't want to bloat your directory with ACEs, it can impact
> perf at some level depending on how deep and long the ACL chains are. This
> is much better in K3 than it was in 2K but it doesn't mean you should do it.
> Also think of complexity... the more ACE's in place on the ACL's, the more
> complexity in trying to work out who can do what in any reasonable time
> frame.
>
>
>
> joe
>
>
>
>
>
>
>
> --
>
> O'Reilly Active Directory Third Edition -
> http://www.joeware.net/win/ad3e.htm
>
>
>
>
>
>
> ------------------------------
>
> *From:* ActiveDir-owner@mail.activedir.org [mailto:
> ActiveDir-owner@mail.activedir.org] *On Behalf Of *Rand Salazar
> *Sent:* Friday, May 02, 2008 7:22 AM
> *To:* Active Dir
> *Subject:* [ActiveDir] AD Delegation = ACL Mess
>
> Hey folks,
>
> I am trying to lock down an AD tree using specific ACLs, however, I have
> been noticing that each part I lock down ends up with a long string of
> ACLs. Is this good for AD health?
>
> Primarily specific OUs are tailored for Accounts, and Computers. For
> instance I am attempting to lock down the Accounts OU such that an IT
> person can only unlock, disable, reset password, edit description, title,
> manager, etc. For each access I am using either dsacl or the GUI. But I am
> beginning to see the OU ACL list turn into a mess. Am I better off just
> allowing by property set.. Personal Information, Public Information, etc?
> The only problem with that is that they include attributes I dont
> particularly wants users to edit, and vice versa, they are missing those I
> want.
>
> How do you folks lock down AD trees?
> ------------------------------
>
> Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it
> now.<http://us.rd.yahoo.com/evt=51733/*http:/mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ%20>
>
--
Thanks,
Brian Desmond
brian@briandesmond.com
c - 312.731.3132
| | | |
| rmscheck
Posts:66
| | 05/04/2008 5:20 PM |
| Excellent advice. You are right, what we want to 'allow' is the better mindset. I guess the hard part is trying to find the balance between what admins will need to do outside of provisioning systems. In some scenarios help desk personnel will still need to perform the basics (enable, disable, reset, unlock, etc) until other systems take those functions away from the ADUC console.
joe <listmail@joeware.net> wrote:
Well by default, unless you are being too free with your builtin groups AD is pretty locked down by default right? You have to actually open it up for people to do things.
You should think of this as what exactly are you trying to allow, not what are you trying to block. If the delegation model is extension, possibly look into some sort of proxydelegation tool of some sort and delegate permissions there.
With users, anymore, everyone should be looking at provisioning tools, metadirectory systems, and self service type configurations. There shouldn't be a lot of need for manual add/delete/updates.
But yes, you don't want to bloat your directory with ACEs, it can impact perf at some level depending on how deep and long the ACL chains are. This is much better in K3 than it was in 2K but it doesn't mean you should do it. Also think of complexity... the more ACE's in place on the ACL's, the more complexity in trying to work out who can do what in any reasonable time frame.
joe
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
---------------------------------
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Rand Salazar
Sent: Friday, May 02, 2008 7:22 AM
To: Active Dir
Subject: [ActiveDir] AD Delegation = ACL Mess
Hey folks,
I am trying to lock down an AD tree using specific ACLs, however, I have been noticing that each part I lock down ends up with a long string of ACLs. Is this good for AD health?
Primarily specific OUs are tailored for Accounts, and Computers. For instance I am attempting to lock down the Accounts OU such that an IT person can only unlock, disable, reset password, edit description, title, manager, etc. For each access I am using either dsacl or the GUI. But I am beginning to see the OU ACL list turn into a mess. Am I better off just allowing by property set.. Personal Information, Public Information, etc? The only problem with that is that they include attributes I dont particularly wants users to edit, and vice versa, they are missing those I want.
How do you folks lock down AD trees?
---------------------------------
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
---------------------------------
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
| | | |
| habr
Posts:25
| | 05/05/2008 8:57 AM |
| Dan [or joe]
Help me understnd something.
What is the "EXACT" purpose of using a service/proxy tool to allow an Admin
to do something?
What "EXACTLY" do you gain by this?
Security?
Accountability?
Simplicity?
I don't see where anything is made simpler, or more secure, or better
"adhered to a design model" by doing it?
RH
________________________________________
-----Original Message-----
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]On Behalf Of Dan Holme
Sent: 03 May, 2008 4:35 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] AD Delegation = ACL Mess
Agreed 100% with Joe, but to address part of your question, the reality is
you WILL end up with additional ACEs in your ACLs to 'open up' delegation to
support the model you do want, whatever that is. Because you're dealing
with object and attribute permissions, the ACL will end up being "long."
But "long" is relative. you should be less concerned about "length" and more
concerned about "optimization." i.e. you want to create ACLs that balance
out achieving your goals with not over-inundating AD with ACEs.
Also keep in mind that AD "single instances" permissions, so that if you
have a "long" (whatever that means to you) ACL on a upper-level OU, objects
will not have "duplicate" long ACLs below that-they will refer to the single
instance of that ACL. I'm simplifying, and one of the other posters can
expand on or correct this as needs be.
Bottom line is that if you MANAGE your delegation, and if your OU design
truly reflects security/delegation/ACL propagation (whatever you choose to
call it), you'll have an optimized result. This sounds *exactly* like what
you *are* doing, so it sounds like you're heading in the right direction.
FWIW I haven't had a whole lot of luck with property sets for the very
reasons you mention.
The two things I'd generalize out of my large delegations are:
1) Create a role-based delegation so that, after you have created
your OUs and ACL'ed them, you never have to touch them again and can instead
manage delegation with group memberships. It helps A LOT - beyond words -
and is an amazing help when it comes time for audits, compliance reports,
etc.
2) As joe said, look at provisioning/proxying tools to alleviate the
burden of AD delegation. Basic idea is that you have a service/tool that
runs with (broad) rights to make changes to AD. The tool abstracts/manages
the delegation. Admins can use the tool, but are *not* delegated rights to
perform the tasks in AD directly. This not only simplifies AD ACLs but also
enables the injection of business logic, richer auditing, and self-service.
I have a tool we built for one client (10k seats) that is a simple, but very
effective example. Feel free to ping me off line if you'd like details.
Dan
Dan Holme
dan.holme@intelliem.com
www.intelliem.com
Phone: 415.670.9360 (finds me)
Land: 808.573.0726
Mobile: 602.295.1692
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of joe
Sent: Friday, May 02, 2008 4:38 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] AD Delegation = ACL Mess
Well by default, unless you are being too free with your builtin groups AD
is pretty locked down by default right? You have to actually open it up for
people to do things.
You should think of this as what exactly are you trying to allow, not what
are you trying to block. If the delegation model is extension, possibly look
into some sort of proxydelegation tool of some sort and delegate permissions
there.
With users, anymore, everyone should be looking at provisioning tools,
metadirectory systems, and self service type configurations. There shouldn't
be a lot of need for manual add/delete/updates.
But yes, you don't want to bloat your directory with ACEs, it can impact
perf at some level depending on how deep and long the ACL chains are. This
is much better in K3 than it was in 2K but it doesn't mean you should do it.
Also think of complexity... the more ACE's in place on the ACL's, the more
complexity in trying to work out who can do what in any reasonable time
frame.
joe
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
----------------------------------------------------------------------------
--
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Rand Salazar
Sent: Friday, May 02, 2008 7:22 AM
To: Active Dir
Subject: [ActiveDir] AD Delegation = ACL Mess
Hey folks,
I am trying to lock down an AD tree using specific ACLs, however, I have
been noticing that each part I lock down ends up with a long string of ACLs.
Is this good for AD health?
Primarily specific OUs are tailored for Accounts, and Computers. For
instance I am attempting to lock down the Accounts OU such that an IT
person can only unlock, disable, reset password, edit description, title,
manager, etc. For each access I am using either dsacl or the GUI. But I am
beginning to see the OU ACL list turn into a mess. Am I better off just
allowing by property set.. Personal Information, Public Information, etc?
The only problem with that is that they include attributes I dont
particularly wants users to edit, and vice versa, they are missing those I
want.
How do you folks lock down AD trees?
----------------------------------------------------------------------------
--
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it
now.
| | | |
| bdesmond
Posts:374
| | 05/05/2008 10:13 AM |
| I'd say you get simplicity and flexibility. You can now implement business
rulesa re part of your delegation process. Let's say right now you have some
people who manually can create users. You have a checklist that says they
need to populate 13 attributes on these objects. 7 of those attributes need
to be formatted in a certain way (e.g. phone numbers, company name, etc).
You're pretty much on your own if you let admins make them by hand. Take a
proxy based tool and you can implement all these rules in it and have it
walk the admin through the reation and enforce the rules.
The tools also tend to log at an easy to use and granular level every
modification. Alot more manageable than the auditing functionality in place
now in 2003 AD.
--brian
On Mon, May 5, 2008 at 8:53 AM, Rocky Habeeb <habr@jws.com> wrote:
> Dan [or joe]
>
> Help me understnd something.
> What is the "EXACT" purpose of using a service/proxy tool to allow an
> Admin to do something?
> What "EXACTLY" do you gain by this?
> Security?
> Accountability?
> Simplicity?
>
> I don't see where anything is made simpler, or more secure, or better
> "adhered to a design model" by doing it?
>
> RH
> ________________________________________
>
> -----Original Message-----
> *From:* ActiveDir-owner@mail.activedir.org [mailto:
> ActiveDir-owner@mail.activedir.org]*On Behalf Of *Dan Holme
> *Sent:* 03 May, 2008 4:35 PM
> *To:* ActiveDir@mail.activedir.org
> *Subject:* RE: [ActiveDir] AD Delegation = ACL Mess
>
> Agreed 100% with Joe, but to address part of your question, the reality
> is you WILL end up with additional ACEs in your ACLs to 'open up' delegation
> to support the model you do want, whatever that is. Because you're dealing
> with object and attribute permissions, the ACL will end up being "long."
> But "long" is relative… you should be less concerned about "length" and more
> concerned about "optimization." i.e. you want to create ACLs that balance
> out achieving your goals with not over-inundating AD with ACEs.
>
>
>
> Also keep in mind that AD "single instances" permissions, so that if you
> have a "long" (whatever that means to you) ACL on a upper-level OU, objects
> will not have "duplicate" long ACLs below that—they will refer to the single
> instance of that ACL. I'm simplifying, and one of the other posters can
> expand on or correct this as needs be.
>
>
>
> Bottom line is that if you MANAGE your delegation, and if your OU design
> truly reflects security/delegation/ACL propagation (whatever you choose to
> call it), you'll have an optimized result. This sounds **exactly** like
> what you **are** doing, so it sounds like you're heading in the right
> direction. FWIW I haven't had a whole lot of luck with property sets for
> the very reasons you mention.
>
>
>
> The two things I'd generalize out of my large delegations are:
>
>
>
> 1) Create a role-based delegation so that, after you have created
> your OUs and ACL'ed them, you never have to touch them again and can instead
> manage delegation with group memberships. It helps A LOT – beyond words –
> and is an amazing help when it comes time for audits, compliance reports,
> etc.
>
> 2) As joe said, look at provisioning/proxying tools to alleviate the
> burden of AD delegation. Basic idea is that you have a service/tool that
> runs with (broad) rights to make changes to AD. The tool abstracts/manages
> the delegation. Admins can use the tool, but are **not** delegated rights
> to perform the tasks in AD directly. This not only simplifies AD ACLs but
> also enables the injection of business logic, richer auditing, and
> self-service. I have a tool we built for one client (10k seats) that is a
> simple, but very effective example. Feel free to ping me off line if you'd
> like details.
>
>
>
>
>
> Dan
>
> Dan Holme
>
> dan.holme@intelliem.com
>
> www.intelliem.com
>
> Phone: 415.670.9360 (finds me)
>
> Land: 808.573.0726
>
> Mobile: 602.295.1692
>
>
>
>
>
>
>
> *From:* ActiveDir-owner@mail.activedir.org [mailto:
> ActiveDir-owner@mail.activedir.org] *On Behalf Of *joe
> *Sent:* Friday, May 02, 2008 4:38 PM
> *To:* ActiveDir@mail.activedir.org
> *Subject:* RE: [ActiveDir] AD Delegation = ACL Mess
>
>
>
> Well by default, unless you are being too free with your builtin groups AD
> is pretty locked down by default right? You have to actually open it up for
> people to do things.
>
>
>
> You should think of this as what exactly are you trying to allow, not what
> are you trying to block. If the delegation model is extension, possibly look
> into some sort of proxydelegation tool of some sort and delegate permissions
> there.
>
>
>
> With users, anymore, everyone should be looking at provisioning tools,
> metadirectory systems, and self service type configurations. There shouldn't
> be a lot of need for manual add/delete/updates.
>
>
>
> But yes, you don't want to bloat your directory with ACEs, it can impact
> perf at some level depending on how deep and long the ACL chains are. This
> is much better in K3 than it was in 2K but it doesn't mean you should do it.
> Also think of complexity... the more ACE's in place on the ACL's, the more
> complexity in trying to work out who can do what in any reasonable time
> frame.
>
>
>
> joe
>
>
>
>
>
>
>
> --
>
> O'Reilly Active Directory Third Edition -
> http://www.joeware.net/win/ad3e.htm
>
>
>
>
>
>
> ------------------------------
>
> *From:* ActiveDir-owner@mail.activedir.org [mailto:
> ActiveDir-owner@mail.activedir.org] *On Behalf Of *Rand Salazar
> *Sent:* Friday, May 02, 2008 7:22 AM
> *To:* Active Dir
> *Subject:* [ActiveDir] AD Delegation = ACL Mess
>
> Hey folks,
>
> I am trying to lock down an AD tree using specific ACLs, however, I have
> been noticing that each part I lock down ends up with a long string of
> ACLs. Is this good for AD health?
>
> Primarily specific OUs are tailored for Accounts, and Computers. For
> instance I am attempting to lock down the Accounts OU such that an IT
> person can only unlock, disable, reset password, edit description, title,
> manager, etc. For each access I am using either dsacl or the GUI. But I am
> beginning to see the OU ACL list turn into a mess. Am I better off just
> allowing by property set.. Personal Information, Public Information, etc?
> The only problem with that is that they include attributes I dont
> particularly wants users to edit, and vice versa, they are missing those I
> want.
>
> How do you folks lock down AD trees?
> ------------------------------
>
> Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it
> now.<http://us.rd.yahoo.com/evt=51733/*http:/mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ%20>
>
>
--
Thanks,
Brian Desmond
brian@briandesmond.com
c - 312.731.3132
| | | |
| PeterJ
Posts:5
| | 05/05/2008 10:53 AM |
| I've implemented one specific version of this type of tool at several
customers, in a previous life, and have seen the benefits. I've found it
depends on the maturity of the organisation and the issues you are
trying to resolve but it certainly had all of the advantages that Brian
mentions.
AD delegation can be a real PITA.
Regards from SA
Peter Johnson
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Brian Desmond
Sent: 05 May 2008 16:13
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] AD Delegation = ACL Mess
I'd say you get simplicity and flexibility. You can now implement
business rulesa re part of your delegation process. Let's say right now
you have some people who manually can create users. You have a checklist
that says they need to populate 13 attributes on these objects. 7 of
those attributes need to be formatted in a certain way (e.g. phone
numbers, company name, etc). You're pretty much on your own if you let
admins make them by hand. Take a proxy based tool and you can implement
all these rules in it and have it walk the admin through the reation and
enforce the rules.
The tools also tend to log at an easy to use and granular level every
modification. Alot more manageable than the auditing functionality in
place now in 2003 AD.
--brian
On Mon, May 5, 2008 at 8:53 AM, Rocky Habeeb <habr@jws.com> wrote:
Dan [or joe]
Help me understnd something.
What is the "EXACT" purpose of using a service/proxy tool to allow an
Admin to do something?
What "EXACTLY" do you gain by this?
Security?
Accountability?
Simplicity?
I don't see where anything is made simpler, or more secure, or better
"adhered to a design model" by doing it?
RH
________________________________________
-----Original Message-----
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]On Behalf Of Dan Holme
Sent: 03 May, 2008 4:35 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] AD Delegation = ACL Mess
Agreed 100% with Joe, but to address part of your question, the
reality is you WILL end up with additional ACEs in your ACLs to 'open
up' delegation to support the model you do want, whatever that is.
Because you're dealing with object and attribute permissions, the ACL
will end up being "long." But "long" is relative... you should be less
concerned about "length" and more concerned about "optimization." i.e.
you want to create ACLs that balance out achieving your goals with not
over-inundating AD with ACEs.
Also keep in mind that AD "single instances" permissions, so
that if you have a "long" (whatever that means to you) ACL on a
upper-level OU, objects will not have "duplicate" long ACLs below
that-they will refer to the single instance of that ACL. I'm
simplifying, and one of the other posters can expand on or correct this
as needs be.
Bottom line is that if you MANAGE your delegation, and if your
OU design truly reflects security/delegation/ACL propagation (whatever
you choose to call it), you'll have an optimized result. This sounds
*exactly* like what you *are* doing, so it sounds like you're heading in
the right direction. FWIW I haven't had a whole lot of luck with
property sets for the very reasons you mention.
The two things I'd generalize out of my large delegations are:
1) Create a role-based delegation so that, after you have
created your OUs and ACL'ed them, you never have to touch them again and
can instead manage delegation with group memberships. It helps A LOT -
beyond words - and is an amazing help when it comes time for audits,
compliance reports, etc.
2) As joe said, look at provisioning/proxying tools to
alleviate the burden of AD delegation. Basic idea is that you have a
service/tool that runs with (broad) rights to make changes to AD. The
tool abstracts/manages the delegation. Admins can use the tool, but are
*not* delegated rights to perform the tasks in AD directly. This not
only simplifies AD ACLs but also enables the injection of business
logic, richer auditing, and self-service. I have a tool we built for
one client (10k seats) that is a simple, but very effective example.
Feel free to ping me off line if you'd like details.
Dan
Dan Holme
dan.holme@intelliem.com
www.intelliem.com <http://www.intelliem.com/>
Phone: 415.670.9360 (finds me)
Land: 808.573.0726
Mobile: 602.295.1692
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of joe
Sent: Friday, May 02, 2008 4:38 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] AD Delegation = ACL Mess
Well by default, unless you are being too free with your builtin
groups AD is pretty locked down by default right? You have to actually
open it up for people to do things.
You should think of this as what exactly are you trying to
allow, not what are you trying to block. If the delegation model is
extension, possibly look into some sort of proxydelegation tool of some
sort and delegate permissions there.
With users, anymore, everyone should be looking at provisioning
tools, metadirectory systems, and self service type configurations.
There shouldn't be a lot of need for manual add/delete/updates.
But yes, you don't want to bloat your directory with ACEs, it
can impact perf at some level depending on how deep and long the ACL
chains are. This is much better in K3 than it was in 2K but it doesn't
mean you should do it. Also think of complexity... the more ACE's in
place on the ACL's, the more complexity in trying to work out who can do
what in any reasonable time frame.
joe
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
________________________________
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Rand Salazar
Sent: Friday, May 02, 2008 7:22 AM
To: Active Dir
Subject: [ActiveDir] AD Delegation = ACL Mess
Hey folks,
I am trying to lock down an AD tree using specific ACLs,
however, I have been noticing that each part I lock down ends up with a
long string of ACLs. Is this good for AD health?
Primarily specific OUs are tailored for Accounts, and Computers.
For instance I am attempting to lock down the Accounts OU such that an
IT person can only unlock, disable, reset password, edit description,
title, manager, etc. For each access I am using either dsacl or the
GUI. But I am beginning to see the OU ACL list turn into a mess. Am I
better off just allowing by property set.. Personal Information, Public
Information, etc? The only problem with that is that they include
attributes I dont particularly wants users to edit, and vice versa, they
are missing those I want.
How do you folks lock down AD trees?
________________________________
Be a better friend, newshound, and know-it-all with Yahoo!
Mobile. Try it now.
<http://us.rd.yahoo.com/evt=51733/*http:/mobile.yahoo.com/;_ylt=Ahu06i62
sR8HDtDypao8Wcj9tAcJ%20>
--
Thanks,
Brian Desmond
brian@briandesmond.com
c - 312.731.3132
Disclaimer:
The Development Bank of Southern Africa exercises no control over information contained in any e-mail message originating from within the organisation. The Bank makes no representation relating to the completeness or accuracy and accepts no responsibility for any loss, damage or liability that is incurred by reliance on the content hereof by the recipient or any other party. Each page attached hereto must also be read in conjunction with any disclaimer, which forms part of it.
Confidentiality:
The e-mail is privileged and confidential and for use of the addressee only. Should you have received this e-mail in error, please return it to webmaster@dbsa.org. Dissemination, disclosure, copying or any similar actions of the content of this e-mail is strictly prohibited.
| | | |
| listmail
Posts:463
| | 05/05/2008 11:14 AM |
| Yep, you can inflict business rules upon the people making changes, you can
give rights to nearly all attributes or even the ability to create objects
but still retain control over the objects. For example, say you give someone
the native right to create users, how badly can they harm your Exchange
environment? Do you know? It depends on your setup but if you followed the
defaults, anyone who can create users can also create mailboxes, set the
quota sizes that they want, etc. This includes accidently (or not so
accidently) creating 40,000 users and sticking them on one mailbox server in
one DB. You need no Exchange permissions to do that.
Another issues... Pre-K8, you couldn't, for example, give rights to just
create say OU's. If you gave someone the right to create an OU, they could
do that and then create any subobjects they wanted that were valid inferior
objectclasses... So giving someone say create computers and create OU's
effectively gave them the rights to create any kind of object they wanted.
Depending on the tool you can delegate out say the right to set some custom
field or add some group membership to a user but have some sort of key that
some other person needs to be looped in and authorize it (workflow). So say
you want to give someone the ability to manage group XYZ but if the person
they are trying to add is already in group PDQ, someone needs to be looped
in to ok it... Say it is someone who is working on dev stuff on one project
for automotive customer #1 and he/she is being given access to a dev project
for automotive customer #2 that is a competitor... someone who may be on the
line for keeping those accounts separate at some or all levels should likely
be looped into the process. In a default delegation, if I can add members to
a group, I can add any member to a group.
Another example of that which I have seen in real life too many times... You
have a GPO that is applied to the entire domain, it is handled by group
filtering (something that has always been a bit of a scary thing for me).
Someone accidently adds EVERYONE to the group... So now everyone gets that
GPO applied... What if it is a Kiosk GPO? Everyone in the domain locks down
to Kiosk mode including Admins... Uh oh. You could set it up so that anyone
can add accounts to that group membership but the ID has to start with
kiosk_ or something like that.
All sorts of examples like that.
Finally the auditing as Brian mentioned can be much more granular and
controlled and informative.
joe
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
_____
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Brian Desmond
Sent: Monday, May 05, 2008 10:13 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] AD Delegation = ACL Mess
I'd say you get simplicity and flexibility. You can now implement business
rulesa re part of your delegation process. Let's say right now you have some
people who manually can create users. You have a checklist that says they
need to populate 13 attributes on these objects. 7 of those attributes need
to be formatted in a certain way (e.g. phone numbers, company name, etc).
You're pretty much on your own if you let admins make them by hand. Take a
proxy based tool and you can implement all these rules in it and have it
walk the admin through the reation and enforce the rules.
The tools also tend to log at an easy to use and granular level every
modification. Alot more manageable than the auditing functionality in place
now in 2003 AD.
--brian
On Mon, May 5, 2008 at 8:53 AM, Rocky Habeeb <habr@jws.com> wrote:
Dan [or joe]
Help me understnd something.
What is the "EXACT" purpose of using a service/proxy tool to allow an Admin
to do something?
What "EXACTLY" do you gain by this?
Security?
Accountability?
Simplicity?
I don't see where anything is made simpler, or more secure, or better
"adhered to a design model" by doing it?
RH
________________________________________
-----Original Message-----
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]On Behalf Of Dan Holme
Sent: 03 May, 2008 4:35 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] AD Delegation = ACL Mess
Agreed 100% with Joe, but to address part of your question, the reality is
you WILL end up with additional ACEs in your ACLs to 'open up' delegation to
support the model you do want, whatever that is. Because you're dealing
with object and attribute permissions, the ACL will end up being "long."
But "long" is relative. you should be less concerned about "length" and more
concerned about "optimization." i.e. you want to create ACLs that balance
out achieving your goals with not over-inundating AD with ACEs.
Also keep in mind that AD "single instances" permissions, so that if you
have a "long" (whatever that means to you) ACL on a upper-level OU, objects
will not have "duplicate" long ACLs below that-they will refer to the single
instance of that ACL. I'm simplifying, and one of the other posters can
expand on or correct this as needs be.
Bottom line is that if you MANAGE your delegation, and if your OU design
truly reflects security/delegation/ACL propagation (whatever you choose to
call it), you'll have an optimized result. This sounds *exactly* like what
you *are* doing, so it sounds like you're heading in the right direction.
FWIW I haven't had a whole lot of luck with property sets for the very
reasons you mention.
The two things I'd generalize out of my large delegations are:
1) Create a role-based delegation so that, after you have created your
OUs and ACL'ed them, you never have to touch them again and can instead
manage delegation with group memberships. It helps A LOT - beyond words -
and is an amazing help when it comes time for audits, compliance reports,
etc.
2) As joe said, look at provisioning/proxying tools to alleviate the
burden of AD delegation. Basic idea is that you have a service/tool that
runs with (broad) rights to make changes to AD. The tool abstracts/manages
the delegation. Admins can use the tool, but are *not* delegated rights to
perform the tasks in AD directly. This not only simplifies AD ACLs but also
enables the injection of business logic, richer auditing, and self-service.
I have a tool we built for one client (10k seats) that is a simple, but very
effective example. Feel free to ping me off line if you'd like details.
Dan
Dan Holme
dan.holme@intelliem.com
www.intelliem.com <http://www.intelliem.com/>
Phone: 415.670.9360 (finds me)
Land: 808.573.0726
Mobile: 602.295.1692
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of joe
Sent: Friday, May 02, 2008 4:38 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] AD Delegation = ACL Mess
Well by default, unless you are being too free with your builtin groups AD
is pretty locked down by default right? You have to actually open it up for
people to do things.
You should think of this as what exactly are you trying to allow, not what
are you trying to block. If the delegation model is extension, possibly look
into some sort of proxydelegation tool of some sort and delegate permissions
there.
With users, anymore, everyone should be looking at provisioning tools,
metadirectory systems, and self service type configurations. There shouldn't
be a lot of need for manual add/delete/updates.
But yes, you don't want to bloat your directory with ACEs, it can impact
perf at some level depending on how deep and long the ACL chains are. This
is much better in K3 than it was in 2K but it doesn't mean you should do it.
Also think of complexity... the more ACE's in place on the ACL's, the more
complexity in trying to work out who can do what in any reasonable time
frame.
joe
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
_____
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Rand Salazar
Sent: Friday, May 02, 2008 7:22 AM
To: Active Dir
Subject: [ActiveDir] AD Delegation = ACL Mess
Hey folks,
I am trying to lock down an AD tree using specific ACLs, however, I have
been noticing that each part I lock down ends up with a long string of ACLs.
Is this good for AD health?
Primarily specific OUs are tailored for Accounts, and Computers. For
instance I am attempting to lock down the Accounts OU such that an IT
person can only unlock, disable, reset password, edit description, title,
manager, etc. For each access I am using either dsacl or the GUI. But I am
beginning to see the OU ACL list turn into a mess. Am I better off just
allowing by property set.. Personal Information, Public Information, etc?
The only problem with that is that they include attributes I dont
particularly wants users to edit, and vice versa, they are missing those I
want.
How do you folks lock down AD trees?
_____
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it
<http://us.rd.yahoo.com/evt=51733/*http:/mobile.yahoo.com/;_ylt=Ahu06i62sR8H
DtDypao8Wcj9tAcJ%20> now.
--
Thanks,
Brian Desmond
brian@briandesmond.com
c - 312.731.3132
| | | |
| danholme
Posts:133
| | 05/05/2008 2:10 PM |
| Agreed with Brian & Joe with two minor enhancements:
Simplified AD ACLing
Easier delegation (done within the provisioning app)
Inject business rules & requirements
+ WORKFLOW (e.g. get "approval" before an object is actually created by
emailing the "manager" and getting a click-through approval)
Auditing (/compliance /reporting)
+ EASIER TOOLS. You can control the UI of tools, allowing, for example,
business owners of resources (shared folders) to manage membership of
groups that provide access to those resources. These business owners
don't even need to be technically literate if you build the tools &
workflows correctly.
And, yes, "Security, Accountability & Simplicity" is another way to say
it J
For whoever 'cares' ;-) I'll be doing three sessions ("Administrators
Idol", "Role Based Management" and "File Server Security") at Tech Ed
each of which address these issues from different perspectives. The
"Administrators Idol" is most directly related to this thread, as it
shows off Proxying.
HTH
Dan
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of joe
Sent: Monday, May 05, 2008 5:12 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] AD Delegation = ACL Mess
Yep, you can inflict business rules upon the people making changes, you
can give rights to nearly all attributes or even the ability to create
objects but still retain control over the objects. For example, say you
give someone the native right to create users, how badly can they harm
your Exchange environment? Do you know? It depends on your setup but if
you followed the defaults, anyone who can create users can also create
mailboxes, set the quota sizes that they want, etc. This includes
accidently (or not so accidently) creating 40,000 users and sticking
them on one mailbox server in one DB. You need no Exchange permissions
to do that.
Another issues... Pre-K8, you couldn't, for example, give rights to just
create say OU's. If you gave someone the right to create an OU, they
could do that and then create any subobjects they wanted that were valid
inferior objectclasses... So giving someone say create computers and
create OU's effectively gave them the rights to create any kind of
object they wanted.
Depending on the tool you can delegate out say the right to set some
custom field or add some group membership to a user but have some sort
of key that some other person needs to be looped in and authorize it
(workflow). So say you want to give someone the ability to manage group
XYZ but if the person they are trying to add is already in group PDQ,
someone needs to be looped in to ok it... Say it is someone who is
working on dev stuff on one project for automotive customer #1 and
he/she is being given access to a dev project for automotive customer #2
that is a competitor... someone who may be on the line for keeping those
accounts separate at some or all levels should likely be looped into the
process. In a default delegation, if I can add members to a group, I can
add any member to a group.
Another example of that which I have seen in real life too many times...
You have a GPO that is applied to the entire domain, it is handled by
group filtering (something that has always been a bit of a scary thing
for me). Someone accidently adds EVERYONE to the group... So now
everyone gets that GPO applied... What if it is a Kiosk GPO? Everyone in
the domain locks down to Kiosk mode including Admins... Uh oh. You could
set it up so that anyone can add accounts to that group membership but
the ID has to start with kiosk_ or something like that.
All sorts of examples like that.
Finally the auditing as Brian mentioned can be much more granular and
controlled and informative.
joe
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
________________________________
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Brian Desmond
Sent: Monday, May 05, 2008 10:13 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] AD Delegation = ACL Mess
I'd say you get simplicity and flexibility. You can now implement
business rulesa re part of your delegation process. Let's say right now
you have some people who manually can create users. You have a checklist
that says they need to populate 13 attributes on these objects. 7 of
those attributes need to be formatted in a certain way (e.g. phone
numbers, company name, etc). You're pretty much on your own if you let
admins make them by hand. Take a proxy based tool and you can implement
all these rules in it and have it walk the admin through the reation and
enforce the rules.
The tools also tend to log at an easy to use and granular level every
modification. Alot more manageable than the auditing functionality in
place now in 2003 AD.
--brian
On Mon, May 5, 2008 at 8:53 AM, Rocky Habeeb <habr@jws.com> wrote:
Dan [or joe]
Help me understnd something.
What is the "EXACT" purpose of using a service/proxy tool to allow an
Admin to do something?
What "EXACTLY" do you gain by this?
Security?
Accountability?
Simplicity?
I don't see where anything is made simpler, or more secure, or better
"adhered to a design model" by doing it?
RH
________________________________________
-----Original Message-----
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]On Behalf Of Dan Holme
Sent: 03 May, 2008 4:35 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] AD Delegation = ACL Mess
Agreed 100% with Joe, but to address part of your question, the
reality is you WILL end up with additional ACEs in your ACLs to 'open
up' delegation to support the model you do want, whatever that is.
Because you're dealing with object and attribute permissions, the ACL
will end up being "long." But "long" is relative... you should be less
concerned about "length" and more concerned about "optimization." i.e.
you want to create ACLs that balance out achieving your goals with not
over-inundating AD with ACEs.
Also keep in mind that AD "single instances" permissions, so
that if you have a "long" (whatever that means to you) ACL on a
upper-level OU, objects will not have "duplicate" long ACLs below
that-they will refer to the single instance of that ACL. I'm
simplifying, and one of the other posters can expand on or correct this
as needs be.
Bottom line is that if you MANAGE your delegation, and if your
OU design truly reflects security/delegation/ACL propagation (whatever
you choose to call it), you'll have an optimized result. This sounds
*exactly* like what you *are* doing, so it sounds like you're heading in
the right direction. FWIW I haven't had a whole lot of luck with
property sets for the very reasons you mention.
The two things I'd generalize out of my large delegations are:
1) Create a role-based delegation so that, after you have
created your OUs and ACL'ed them, you never have to touch them again and
can instead manage delegation with group memberships. It helps A LOT -
beyond words - and is an amazing help when it comes time for audits,
compliance reports, etc.
2) As joe said, look at provisioning/proxying tools to
alleviate the burden of AD delegation. Basic idea is that you have a
service/tool that runs with (broad) rights to make changes to AD. The
tool abstracts/manages the delegation. Admins can use the tool, but are
*not* delegated rights to perform the tasks in AD directly. This not
only simplifies AD ACLs but also enables the injection of business
logic, richer auditing, and self-service. I have a tool we built for
one client (10k seats) that is a simple, but very effective example.
Feel free to ping me off line if you'd like details.
Dan
Dan Holme
dan.holme@intelliem.com
www.intelliem.com <http://www.intelliem.com/>
Phone: 415.670.9360 (finds me)
Land: 808.573.0726
Mobile: 602.295.1692
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of joe
Sent: Friday, May 02, 2008 4:38 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] AD Delegation = ACL Mess
Well by default, unless you are being too free with your builtin
groups AD is pretty locked down by default right? You have to actually
open it up for people to do things.
You should think of this as what exactly are you trying to
allow, not what are you trying to block. If the delegation model is
extension, possibly look into some sort of proxydelegation tool of some
sort and delegate permissions there.
With users, anymore, everyone should be looking at provisioning
tools, metadirectory systems, and self service type configurations.
There shouldn't be a lot of need for manual add/delete/updates.
But yes, you don't want to bloat your directory with ACEs, it
can impact perf at some level depending on how deep and long the ACL
chains are. This is much better in K3 than it was in 2K but it doesn't
mean you should do it. Also think of complexity... the more ACE's in
place on the ACL's, the more complexity in trying to work out who can do
what in any reasonable time frame.
joe
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
________________________________
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Rand Salazar
Sent: Friday, May 02, 2008 7:22 AM
To: Active Dir
Subject: [ActiveDir] AD Delegation = ACL Mess
Hey folks,
I am trying to lock down an AD tree using specific ACLs,
however, I have been noticing that each part I lock down ends up with a
long string of ACLs. Is this good for AD health?
Primarily specific OUs are tailored for Accounts, and Computers.
For instance I am attempting to lock down the Accounts OU such that an
IT person can only unlock, disable, reset password, edit description,
title, manager, etc. For each access I am using either dsacl or the
GUI. But I am beginning to see the OU ACL list turn into a mess. Am I
better off just allowing by property set.. Personal Information, Public
Information, etc? The only problem with that is that they include
attributes I dont particularly wants users to edit, and vice versa, they
are missing those I want.
How do you folks lock down AD trees?
________________________________
Be a better friend, newshound, and know-it-all with Yahoo!
Mobile. Try it now.
<http://us.rd.yahoo.com/evt=51733/*http:/mobile.yahoo.com/;_ylt=Ahu06i62
sR8HDtDypao8Wcj9tAcJ%20>
--
Thanks,
Brian Desmond
brian@briandesmond.com
c - 312.731.3132
| | | |
| davewade
Posts:45
| | 05/05/2008 3:46 PM |
| Speaking as some one who is currently looking to clean up our provisioning process, in particular to delegate user creation and deletion, can some one point me at some suitable tools?
At the moment I have found :-
ADManager Plus
Quest Active Roles
Script Logic Active Administrator
But are there any more I should look at? Any to avoid?
Dave.
________________________________
From: ActiveDir-owner@mail.activedir.org on behalf of Dan Holme
Sent: Mon 05/05/2008 19:05
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] AD Delegation = ACL Mess
Agreed with Brian & Joe with two minor enhancements:
Simplified AD ACLing
Easier delegation (done within the provisioning app)
Inject business rules & requirements
+ WORKFLOW (e.g. get "approval" before an object is actually created by emailing the "manager" and getting a click-through approval)
Auditing (/compliance /reporting)
+ EASIER TOOLS. You can control the UI of tools, allowing, for example, business owners of resources (shared folders) to manage membership of groups that provide access to those resources. These business owners don't even need to be technically literate if you build the tools & workflows correctly.
And, yes, "Security, Accountability & Simplicity" is another way to say it J
For whoever 'cares' ;-) I'll be doing three sessions ("Administrators Idol", "Role Based Management" and "File Server Security") at Tech Ed each of which address these issues from different perspectives. The "Administrators Idol" is most directly related to this thread, as it shows off Proxying.
HTH
Dan
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of joe
Sent: Monday, May 05, 2008 5:12 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] AD Delegation = ACL Mess
Yep, you can inflict business rules upon the people making changes, you can give rights to nearly all attributes or even the ability to create objects but still retain control over the objects. For example, say you give someone the native right to create users, how badly can they harm your Exchange environment? Do you know? It depends on your setup but if you followed the defaults, anyone who can create users can also create mailboxes, set the quota sizes that they want, etc. This includes accidently (or not so accidently) creating 40,000 users and sticking them on one mailbox server in one DB. You need no Exchange permissions to do that.
Another issues... Pre-K8, you couldn't, for example, give rights to just create say OU's. If you gave someone the right to create an OU, they could do that and then create any subobjects they wanted that were valid inferior objectclasses... So giving someone say create computers and create OU's effectively gave them the rights to create any kind of object they wanted.
Depending on the tool you can delegate out say the right to set some custom field or add some group membership to a user but have some sort of key that some other person needs to be looped in and authorize it (workflow). So say you want to give someone the ability to manage group XYZ but if the person they are trying to add is already in group PDQ, someone needs to be looped in to ok it... Say it is someone who is working on dev stuff on one project for automotive customer #1 and he/she is being given access to a dev project for automotive customer #2 that is a competitor... someone who may be on the line for keeping those accounts separate at some or all levels should likely be looped into the process. In a default delegation, if I can add members to a group, I can add any member to a group.
Another example of that which I have seen in real life too many times... You have a GPO that is applied to the entire domain, it is handled by group filtering (something that has always been a bit of a scary thing for me). Someone accidently adds EVERYONE to the group... So now everyone gets that GPO applied... What if it is a Kiosk GPO? Everyone in the domain locks down to Kiosk mode including Admins... Uh oh. You could set it up so that anyone can add accounts to that group membership but the ID has to start with kiosk_ or something like that.
All sorts of examples like that.
Finally the auditing as Brian mentioned can be much more granular and controlled and informative.
joe
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
________________________________
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Brian Desmond
Sent: Monday, May 05, 2008 10:13 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] AD Delegation = ACL Mess
I'd say you get simplicity and flexibility. You can now implement business rulesa re part of your delegation process. Let's say right now you have some people who manually can create users. You have a checklist that says they need to populate 13 attributes on these objects. 7 of those attributes need to be formatted in a certain way (e.g. phone numbers, company name, etc). You're pretty much on your own if you let admins make them by hand. Take a proxy based tool and you can implement all these rules in it and have it walk the admin through the reation and enforce the rules.
The tools also tend to log at an easy to use and granular level every modification. Alot more manageable than the auditing functionality in place now in 2003 AD.
--brian
On Mon, May 5, 2008 at 8:53 AM, Rocky Habeeb <habr@jws.com> wrote:
Dan [or joe]
Help me understnd something.
What is the "EXACT" purpose of using a service/proxy tool to allow an Admin to do something?
What "EXACTLY" do you gain by this?
Security?
Accountability?
Simplicity?
I don't see where anything is made simpler, or more secure, or better "adhered to a design model" by doing it?
RH
________________________________________
-----Original Message-----
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org]On Behalf Of Dan Holme
Sent: 03 May, 2008 4:35 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] AD Delegation = ACL Mess
Agreed 100% with Joe, but to address part of your question, the reality is you WILL end up with additional ACEs in your ACLs to 'open up' delegation to support the model you do want, whatever that is. Because you're dealing with object and attribute permissions, the ACL will end up being "long." But "long" is relative... you should be less concerned about "length" and more concerned about "optimization." i.e. you want to create ACLs that balance out achieving your goals with not over-inundating AD with ACEs.
Also keep in mind that AD "single instances" permissions, so that if you have a "long" (whatever that means to you) ACL on a upper-level OU, objects will not have "duplicate" long ACLs below that-they will refer to the single instance of that ACL. I'm simplifying, and one of the other posters can expand on or correct this as needs be.
Bottom line is that if you MANAGE your delegation, and if your OU design truly reflects security/delegation/ACL propagation (whatever you choose to call it), you'll have an optimized result. This sounds *exactly* like what you *are* doing, so it sounds like you're heading in the right direction. FWIW I haven't had a whole lot of luck with property sets for the very reasons you mention.
The two things I'd generalize out of my large delegations are:
1) Create a role-based delegation so that, after you have created your OUs and ACL'ed them, you never have to touch them again and can instead manage delegation with group memberships. It helps A LOT - beyond words - and is an amazing help when it comes time for audits, compliance reports, etc.
2) As joe said, look at provisioning/proxying tools to alleviate the burden of AD delegation. Basic idea is that you have a service/tool that runs with (broad) rights to make changes to AD. The tool abstracts/manages the delegation. Admins can use the tool, but are *not* delegated rights to perform the tasks in AD directly. This not only simplifies AD ACLs but also enables the injection of business logic, richer auditing, and self-service. I have a tool we built for one client (10k seats) that is a simple, but very effective example. Feel free to ping me off line if you'd like details.
Dan
Dan Holme
dan.holme@intelliem.com
www.intelliem.com <http://www.intelliem.com/>
Phone: 415.670.9360 (finds me)
Land: 808.573.0726
Mobile: 602.295.1692
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of joe
Sent: Friday, May 02, 2008 4:38 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] AD Delegation = ACL Mess
Well by default, unless you are being too free with your builtin groups AD is pretty locked down by default right? You have to actually open it up for people to do things.
You should think of this as what exactly are you trying to allow, not what are you trying to block. If the delegation model is extension, possibly look into some sort of proxydelegation tool of some sort and delegate permissions there.
With users, anymore, everyone should be looking at provisioning tools, metadirectory systems, and self service type configurations. There shouldn't be a lot of need for manual add/delete/updates.
But yes, you don't want to bloat your directory with ACEs, it can impact perf at some level depending on how deep and long the ACL chains are. This is much better in K3 than it was in 2K but it doesn't mean you should do it. Also think of complexity... the more ACE's in place on the ACL's, the more complexity in trying to work out who can do what in any reasonable time frame.
joe
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
________________________________
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Rand Salazar
Sent: Friday, May 02, 2008 7:22 AM
To: Active Dir
Subject: [ActiveDir] AD Delegation = ACL Mess
Hey folks,
I am trying to lock down an AD tree using specific ACLs, however, I have been noticing that each part I lock down ends up with a long string of ACLs. Is this good for AD health?
Primarily specific OUs are tailored for Accounts, and Computers. For instance I am attempting to lock down the Accounts OU such that an IT person can only unlock, disable, reset password, edit description, title, manager, etc. For each access I am using either dsacl or the GUI. But I am beginning to see the OU ACL list turn into a mess. Am I better off just allowing by property set.. Personal Information, Public Information, etc? The only problem with that is that they include attributes I dont particularly wants users to edit, and vice versa, they are missing those I want.
How do you folks lock down AD trees?
________________________________
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. <http://us.rd.yahoo.com/evt=51733/*http:/mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ%20>
--
Thanks,
Brian Desmond
brian@briandesmond.com
c - 312.731.3132
**********************************************************************
This email, and any files transmitted with it, is confidential and
intended solely for the use of the individual or entity to whom they
are addressed. As a public body, the Council may be required to disclose this email, or any response to it, under the Freedom of Information Act 2000, unless the information in it is covered by one of the exemptions in the Act.
If you receive this email in error please notify Stockport ICT, Business Services via email.query@stockport.gov.uk and then permanently remove it from your system.
Thank you.
http://www.stockport.gov.uk
**********************************************************************
| | | |
| jw1
Posts:0
| | 05/05/2008 3:51 PM |
| NetIQ DRA
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Dave Wade
Sent: Monday, May 05, 2008 2:44 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] AD Delegation = ACL Mess
Speaking as some one who is currently looking to clean up our provisioning process, in particular to delegate user creation and deletion, can some one point me at some suitable tools?
At the moment I have found :-
ADManager Plus
Quest Active Roles
Script Logic Active Administrator
But are there any more I should look at? Any to avoid?
Dave.
________________________________
From: ActiveDir-owner@mail.activedir.org on behalf of Dan Holme
Sent: Mon 05/05/2008 19:05
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] AD Delegation = ACL Mess
Agreed with Brian & Joe with two minor enhancements:
Simplified AD ACLing
Easier delegation (done within the provisioning app)
Inject business rules & requirements
+ WORKFLOW (e.g. get "approval" before an object is actually created by emailing the "manager" and getting a click-through approval)
Auditing (/compliance /reporting)
+ EASIER TOOLS. You can control the UI of tools, allowing, for example, business owners of resources (shared folders) to manage membership of groups that provide access to those resources. These business owners don't even need to be technically literate if you build the tools & workflows
correctly.
And, yes, "Security, Accountability & Simplicity" is another way to say it J
For whoever 'cares' ;-) I'll be doing three sessions ("Administrators Idol", "Role Based Management" and "File Server Security") at Tech Ed each of which address these issues from different perspectives. The "Administrators Idol" is most directly related to this thread, as it shows off Proxying.
HTH
Dan
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of joe
Sent: Monday, May 05, 2008 5:12 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] AD Delegation = ACL Mess
Yep, you can inflict business rules upon the people making changes, you can give rights to nearly all attributes or even the ability to create objects but still retain control over the objects. For example, say you give someone the native right to create users, how badly can they harm your Exchange
environment? Do you know? It depends on your setup but if you followed the defaults, anyone who can create users can also create mailboxes, set the quota sizes that they want, etc. This includes accidently (or not so accidently) creating 40,000 users and sticking them on one mailbox server in one
DB. You need no Exchange permissions to do that.
Another issues... Pre-K8, you couldn't, for example, give rights to just create say OU's. If you gave someone the right to create an OU, they could do that and then create any subobjects they wanted that were valid inferior objectclasses... So giving someone say create computers and create OU's
effectively gave them the rights to create any kind of object they wanted.
Depending on the tool you can delegate out say the right to set some custom field or add some group membership to a user but have some sort of key that some other person needs to be looped in and authorize it (workflow). So say you want to give someone the ability to manage group XYZ but if the
person they are trying to add is already in group PDQ, someone needs to be looped in to ok it... Say it is someone who is working on dev stuff on one project for automotive customer #1 and he/she is being given access to a dev project for automotive customer #2 that is a competitor... someone who
may be on the line for keeping those accounts separate at some or all levels should likely be looped into the process. In a default delegation, if I can add members to a group, I can add any member to a group.
Another example of that which I have seen in real life too many times... You have a GPO that is applied to the entire domain, it is handled by group filtering (something that has always been a bit of a scary thing for me). Someone accidently adds EVERYONE to the group... So now everyone gets that
GPO applied... What if it is a Kiosk GPO? Everyone in the domain locks down to Kiosk mode including Admins... Uh oh. You could set it up so that anyone can add accounts to that group membership but the ID has to start with kiosk_ or something like that.
All sorts of examples like that.
Finally the auditing as Brian mentioned can be much more granular and controlled and informative.
joe
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
________________________________
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Brian Desmond
Sent: Monday, May 05, 2008 10:13 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] AD Delegation = ACL Mess
I'd say you get simplicity and flexibility. You can now implement business rulesa re part of your delegation process. Let's say right now you have some people who manually can create users. You have a checklist that says they need to populate 13 attributes on these objects. 7 of those attributes
need to be formatted in a certain way (e.g. phone numbers, company name, etc). You're pretty much on your own if you let admins make them by hand. Take a proxy based tool and you can implement all these rules in it and have it walk the admin through the reation and enforce the rules.
The tools also tend to log at an easy to use and granular level every modification. Alot more manageable than the auditing functionality in place now in 2003 AD.
--brian
On Mon, May 5, 2008 at 8:53 AM, Rocky Habeeb <habr@jws.com> wrote:
Dan [or joe]
Help me understnd something.
What is the "EXACT" purpose of using a service/proxy tool to allow an Admin to do something?
What "EXACTLY" do you gain by this?
Security?
Accountability?
Simplicity?
I don't see where anything is made simpler, or more secure, or better "adhered to a design model" by doing it?
RH
________________________________________
-----Original Message-----
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org]On Behalf Of Dan Holme
Sent: 03 May, 2008 4:35 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] AD Delegation = ACL Mess
Agreed 100% with Joe, but to address part of your question, the reality is you WILL end up with additional ACEs in your ACLs to 'open up' delegation to support the model you do want, whatever that is. Because you're dealing with object and attribute permissions, the ACL will end up being
"long." But "long" is relative... you should be less concerned about "length" and more concerned about "optimization." i.e. you want to create ACLs that balance out achieving your goals with not over-inundating AD with ACEs.
Also keep in mind that AD "single instances" permissions, so that if you have a "long" (whatever that means to you) ACL on a upper-level OU, objects will not have "duplicate" long ACLs below that-they will refer to the single instance of that ACL. I'm simplifying, and one of the other
posters can expand on or correct this as needs be.
Bottom line is that if you MANAGE your delegation, and if your OU design truly reflects security/delegation/ACL propagation (whatever you choose to call it), you'll have an optimized result. This sounds *exactly* like what you *are* doing, so it sounds like you're heading in the right
direction. FWIW I haven't had a whole lot of luck with property sets for the very reasons you mention.
The two things I'd generalize out of my large delegations are:
1) Create a role-based delegation so that, after you have created your OUs and ACL'ed them, you never have to touch them again and can instead manage delegation with group memberships. It helps A LOT - beyond words - and is an amazing help when it comes time for audits, compliance
reports, etc.
2) As joe said, look at provisioning/proxying tools to alleviate the burden of AD delegation. Basic idea is that you have a service/tool that runs with (broad) rights to make changes to AD. The tool abstracts/manages the delegation. Admins can use the tool, but are *not* delegated
rights to perform the tasks in AD directly. This not only simplifies AD ACLs but also enables the injection of business logic, richer auditing, and self-service. I have a tool we built for one client (10k seats) that is a simple, but very effective example. Feel free to ping me off line if you'd
like details.
Dan
Dan Holme
dan.holme@intelliem.com
www.intelliem.com <http://www.intelliem.com/>
Phone: 415.670.9360 (finds me)
Land: 808.573.0726
Mobile: 602.295.1692
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of joe
Sent: Friday, May 02, 2008 4:38 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] AD Delegation = ACL Mess
Well by default, unless you are being too free with your builtin groups AD is pretty locked down by default right? You have to actually open it up for people to do things.
You should think of this as what exactly are you trying to allow, not what are you trying to block. If the delegation model is extension, possibly look into some sort of proxydelegation tool of some sort and delegate permissions there.
With users, anymore, everyone should be looking at provisioning tools, metadirectory systems, and self service type configurations. There shouldn't be a lot of need for manual add/delete/updates.
But yes, you don't want to bloat your directory with ACEs, it can impact perf at some level depending on how deep and long the ACL chains are. This is much better in K3 than it was in 2K but it doesn't mean you should do it. Also think of complexity... the more ACE's in place on the ACL's,
the more complexity in trying to work out who can do what in any reasonable time frame.
joe
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
________________________________
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Rand Salazar
Sent: Friday, May 02, 2008 7:22 AM
To: Active Dir
Subject: [ActiveDir] AD Delegation = ACL Mess
Hey folks,
I am trying to lock down an AD tree using specific ACLs, however, I have been noticing that each part I lock down ends up with a long string of ACLs. Is this good for AD health?
Primarily specific OUs are tailored for Accounts, and Computers. For instance I am attempting to lock down the Accounts OU such that an IT person can only unlock, disable, reset password, edit description, title, manager, etc. For each access I am using either dsacl or the GUI. But I am
beginning to see the OU ACL list turn into a mess. Am I better off just allowing by property set.. Personal Information, Public Information, etc? The only problem with that is that they include attributes I dont particularly wants users to edit, and vice versa, they are missing those I want.
How do you folks lock down AD trees?
________________________________
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. <http://us.rd.yahoo.com/evt=51733/*http:/mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ%20>
--
Thanks,
Brian Desmond
brian@briandesmond.com
c - 312.731.3132
**********************************************************************
This email, and any files transmitted with it, is confidential and
intended solely for the use of the individual or entity to whom they
are addressed. As a public body, the Council may be required to disclose this email, or any response to it, under the Freedom of Information Act 2000, unless the information in it is covered by one of the exemptions in the Act.
If you receive this email in error please notify Stockport ICT, Business Services via email.query@stockport.gov.uk and then permanently remove it from your system.
Thank you.
http://www.stockport.gov.uk
**********************************************************************
| | | |
| darren
Posts:168
| | 05/05/2008 4:06 PM |
| There are, frankly, a ton of solutions out there in this space. You might
want to also check out:
EmpowerID: http://www.thedotnetfactory.com/
http://www.tools4ever.com/products/user-management-resource-administrator/au
tomation/details/
It all depends upon your requirements.
Darren
****
Darren Mar-Elia
CTO & Founder
SDM Software, Inc.
www.sdmsoftware.com <http://www.sdmsoftware.com/>
Secure and configure your Windows desktops accurately every time without
having to learn or install new technology. Find out more about Desktop
Policy Manager at http://www.sdmsoftware.com/desktop_management
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Wells, James Arthur
Sent: Monday, May 05, 2008 12:47 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] AD Delegation = ACL Mess
NetIQ DRA
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Dave Wade
Sent: Monday, May 05, 2008 2:44 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] AD Delegation = ACL Mess
Speaking as some one who is currently looking to clean up our provisioning
process, in particular to delegate user creation and deletion, can some one
point me at some suitable tools?
At the moment I have found :-
ADManager Plus
Quest Active Roles
Script Logic Active Administrator
But are there any more I should look at? Any to avoid?
Dave.
_____
From: ActiveDir-owner@mail.activedir.org on behalf of Dan Holme
Sent: Mon 05/05/2008 19:05
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] AD Delegation = ACL Mess
Agreed with Brian & Joe with two minor enhancements:
Simplified AD ACLing
Easier delegation (done within the provisioning app)
Inject business rules & requirements
+ WORKFLOW (e.g. get "approval" before an object is actually created by
emailing the "manager" and getting a click-through approval)
Auditing (/compliance /reporting)
+ EASIER TOOLS. You can control the UI of tools, allowing, for example,
business owners of resources (shared folders) to manage membership of groups
that provide access to those resources. These business owners don't even
need to be technically literate if you build the tools & workflows
correctly.
And, yes, "Security, Accountability & Simplicity" is another way to say it J
For whoever 'cares' ;-) I'll be doing three sessions ("Administrators
Idol", "Role Based Management" and "File Server Security") at Tech Ed each
of which address these issues from different perspectives. The
"Administrators Idol" is most directly related to this thread, as it shows
off Proxying.
HTH
Dan
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of joe
Sent: Monday, May 05, 2008 5:12 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] AD Delegation = ACL Mess
Yep, you can inflict business rules upon the people making changes, you can
give rights to nearly all attributes or even the ability to create objects
but still retain control over the objects. For example, say you give someone
the native right to create users, how badly can they harm your Exchange
environment? Do you know? It depends on your setup but if you followed the
defaults, anyone who can create users can also create mailboxes, set the
quota sizes that they want, etc. This includes accidently (or not so
accidently) creating 40,000 users and sticking them on one mailbox server in
one DB. You need no Exchange permissions to do that.
Another issues... Pre-K8, you couldn't, for example, give rights to just
create say OU's. If you gave someone the right to create an OU, they could
do that and then create any subobjects they wanted that were valid inferior
objectclasses... So giving someone say create computers and create OU's
effectively gave them the rights to create any kind of object they wanted.
Depending on the tool you can delegate out say the right to set some custom
field or add some group membership to a user but have some sort of key that
some other person needs to be looped in and authorize it (workflow). So say
you want to give someone the ability to manage group XYZ but if the person
they are trying to add is already in group PDQ, someone needs to be looped
in to ok it... Say it is someone who is working on dev stuff on one project
for automotive customer #1 and he/she is being given access to a dev project
for automotive customer #2 that is a competitor... someone who may be on the
line for keeping those accounts separate at some or all levels should likely
be looped into the process. In a default delegation, if I can add members to
a group, I can add any member to a group.
Another example of that which I have seen in real life too many times... You
have a GPO that is applied to the entire domain, it is handled by group
filtering (something that has always been a bit of a scary thing for me).
Someone accidently adds EVERYONE to the group... So now everyone gets that
GPO applied... What if it is a Kiosk GPO? Everyone in the domain locks down
to Kiosk mode including Admins... Uh oh. You could set it up so that anyone
can add accounts to that group membership but the ID has to start with
kiosk_ or something like that.
All sorts of examples like that.
Finally the auditing as Brian mentioned can be much more granular and
controlled and informative.
joe
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
_____
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Brian Desmond
Sent: Monday, May 05, 2008 10:13 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] AD Delegation = ACL Mess
I'd say you get simplicity and flexibility. You can now implement business
rulesa re part of your delegation process. Let's say right now you have some
people who manually can create users. You have a checklist that says they
need to populate 13 attributes on these objects. 7 of those attributes need
to be formatted in a certain way (e.g. phone numbers, company name, etc).
You're pretty much on your own if you let admins make them by hand. Take a
proxy based tool and you can implement all these rules in it and have it
walk the admin through the reation and enforce the rules.
The tools also tend to log at an easy to use and granular level every
modification. Alot more manageable than the auditing functionality in place
now in 2003 AD.
--brian
On Mon, May 5, 2008 at 8:53 AM, Rocky Habeeb <habr@jws.com> wrote:
Dan [or joe]
Help me understnd something.
What is the "EXACT" purpose of using a service/proxy tool to allow an Admin
to do something?
What "EXACTLY" do you gain by this?
Security?
Accountability?
Simplicity?
I don't see where anything is made simpler, or more secure, or better
"adhered to a design model" by doing it?
RH
________________________________________
-----Original Message-----
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org]On Behalf Of Dan Holme
Sent: 03 May, 2008 4:35 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] AD Delegation = ACL Mess
Agreed 100% with Joe, but to address part of your question, the reality is
you WILL end up with additional ACEs in your ACLs to 'open up' delegation to
support the model you do want, whatever that is. Because you're dealing
with object and attribute permissions, the ACL will end up being "long."
But "long" is relative. you should be less concerned about "length" and more
concerned about "optimization." i.e. you want to create ACLs that balance
out achieving your goals with not over-inundating AD with ACEs.
Also keep in mind that AD "single instances" permissions, so that if you
have a "long" (whatever that means to you) ACL on a upper-level OU, objects
will not have "duplicate" long ACLs below that-they will refer to the single
instance of that ACL. I'm simplifying, and one of the other posters can
expand on or correct this as needs be.
Bottom line is that if you MANAGE your delegation, and if your OU design
truly reflects security/delegation/ACL propagation (whatever you choose to
call it), you'll have an optimized result. This sounds *exactly* like what
you *are* doing, so it sounds like you're heading in the right direction.
FWIW I haven't had a whole lot of luck with property sets for the very
reasons you mention.
The two things I'd generalize out of my large delegations are:
1) Create a role-based delegation so that, after you have created your
OUs and ACL'ed them, you never have to touch them again and can instead
manage delegation with group memberships. It helps A LOT - beyond words -
and is an amazing help when it comes time for audits, compliance reports,
etc.
2) As joe said, look at provisioning/proxying tools to alleviate the
burden of AD delegation. Basic idea is that you have a service/tool that
runs with (broad) rights to make changes to AD. The tool abstracts/manages
the delegation. Admins can use the tool, but are *not* delegated rights to
perform the tasks in AD directly. This not only simplifies AD ACLs but also
enables the injection of business logic, richer auditing, and self-service.
I have a tool we built for one client (10k seats) that is a simple, but very
effective example. Feel free to ping me off line if you'd like details.
Dan
Dan Holme
dan.holme@intelliem.com
www.intelliem.com <http://www.intelliem.com/>
Phone: 415.670.9360 (finds me)
Land: 808.573.0726
Mobile: 602.295.1692
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of joe
Sent: Friday, May 02, 2008 4:38 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] AD Delegation = ACL Mess
Well by default, unless you are being too free with your builtin groups AD
is pretty locked down by default right? You have to actually open it up for
people to do things.
You should think of this as what exactly are you trying to allow, not what
are you trying to block. If the delegation model is extension, possibly look
into some sort of proxydelegation tool of some sort and delegate permissions
there.
With users, anymore, everyone should be looking at provisioning tools,
metadirectory systems, and self service type configurations. There shouldn't
be a lot of need for manual add/delete/updates.
But yes, you don't want to bloat your directory with ACEs, it can impact
perf at some level depending on how deep and long the ACL chains are. This
is much better in K3 than it was in 2K but it doesn't mean you should do it.
Also think of complexity... the more ACE's in place on the ACL's, the more
complexity in trying to work out who can do what in any reasonable time
frame.
joe
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
_____
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Rand Salazar
Sent: Friday, May 02, 2008 7:22 AM
To: Active Dir
Subject: [ActiveDir] AD Delegation = ACL Mess
Hey folks,
I am trying to lock down an AD tree using specific ACLs, however, I have
been noticing that each part I lock down ends up with a long string of ACLs.
Is this good for AD health?
Primarily specific OUs are tailored for Accounts, and Computers. For
instance I am attempting to lock down the Accounts OU such that an IT
person can only unlock, disable, reset password, edit description, title,
manager, etc. For each access I am using either dsacl or the GUI. But I am
beginning to see the OU ACL list turn into a mess. Am I better off just
allowing by property set.. Personal Information, Public Information, etc?
The only problem with that is that they include attributes I dont
particularly wants users to edit, and vice versa, they are missing those I
want.
How do you folks lock down AD |
|
|