|
Sorry, it's getting late here already and
unintentionally pressed ALT+S too early… I just explored this issue some more and
you certainly need List Object ACE on a certain object (and its parent) for it
to appear in the query results (contrary to what I wondered below). In
addition, you need read permission to at least some attributes. E.g. Read Public
Information property set seems to do the trick. What I don't get is that in the
following scenario (List Object Mode enabled): OULevel1 Auth
Users: Read OULevel2 Auth
Users: Not even single ACE given OULevel3 Auth
Users: List Object only ACE
User object in this OU Auth Users: List
Object & Read Public Info When an ordinary user does search, the
user object is shown in the search results. Why? Wouldn't some kind of
"directory traversal" permission be necessary? Or can search "skip"
some levels? Mika From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guido, Eric & Joe – thanx for
prompt and very alighting comments on this issue. Few more points I'd like to
add: Which tool (in addition to GUI ACL Editor)
or script do you usually use to check the SD & ACLs? I've got to like
sdcheck from Support Tools. I noticed that ADS_RIGHT_DS_LIST_OBJECT is
incorrectly "entitled" as ACTRL_DS_LIST_OBJECT by the tool - or at
least differently from Platform SDK. Wouldn't it be correct to say that:
However, if you also want to restrict what
a SecPrin sees in a query/search (e.g. rundll32 dsquery,OpenQueryWindow), you
would have to modify the permissions on leaf objects (such as users). Since the
Auth Users group has five ACEs for a user object, you would have to remove some
or all of these. In addition, depending on your configuration, Auth Users could
be a member in the "Pre-Windows 2000 Compatible Access" group which
in turn has its own ACEs. I briefly played around with the permissions this
afternoon. And something that I don't fully understand is that if List Object
Mode is enabled and a SecPrin doesn't have List Object permission to some user
account object, why would the account be shown in the query? E.g. in a case
where SecPrin has only Read All Properties ACE. If the List Object mode is being used to
secure different portions of the OU structure to separate/hide e.g. different
departments, wouldn't it be rather common to also restrict what is shown in the
queries? Mika From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman Your assuming in your second paragraph.
For “every day admin” perhaps, but for searching a subtree that you
don’t have list_contents to (which is of course the point J) it could in theory be
large. Recall that admin is usually a small % of your load. Users/apps tend to
be most of it. ~Eric From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, Guido yep, makes sense - with list object mode
turned on and the list content right removed on the parent, you're forced to
check if an object itself is to be displayed or not, which is a permission set
on the object. When the mode is turned off (default), you just
either add all children to the list of objects to be returned (list content applied)
or list none (list content removed). So yes, this could have an impact on
the regular LDAP queries if these are heavily used. However, for normal everyday
administration of AD, I doubt the impact is too large, since for most UIs you
still have to evaluate the permission the SecPrin has on the object in the
resulting list to retrieve other information such as object type and status
etc. Furhtermore, since I find the list
content / list object permission typically being required at the OU level only
(and not at leaf-object level, such as users, groups or computers) simply
to hide specific OUs from being visible to unauthorized accounts, I tend to
believe the extra efforts of enumeration with the extra security checks against
the child OUs will truly be neglegible. But it's certainly benefitial to
understand how it works ;-) /Guido From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman Joe is pretty much there. So list object mode really just makes a
second chance check. So if you don’t have list children on the parent, we
then also check if you have list_object on each child object and return them if
you do. So instead of making one check (for list children on the parent) we now
do 1+N where N is the # of child objects. Is the perf hit huge? Small? I have no
idea. Depends upon a lot of things really (2k vs. 2k03, # of child objects in
your env (IE is your tree “tall or wide”), % of times list children
is not present that we have to do the extra checks, etc.). But in some cases
perhaps measurable. Really, I shouldn’t say
“double acl check” as double implies twice the #. In actuality it
can be far more than twice. But that’s a good way to think about it in
the simple case. ~Eric From: joe
[mailto:[EMAIL PROTECTED] This is a guess but... You have two rights/permissions associated
with listing an object. 1. ADS_RIGHT_ACTRL_DS_LIST -
list child (aka list contents). This is a permission that would be set on
an OU to say that a secprin had the ability to list subobjects of the OU. 2. ADS_RIGHT_DS_LIST_OBJECT - list object.
Thi sis the permission that is set on specific objects to say that a secprin
can list that object. This second right/perm is the one enabled/disabled
with the dsheuristics setting. This would seemingly logically mean you
have at least two objects to check ACLs on to ALLOW the ability to list
the object. I would further surmise that if you have multiple objects
within a subOU or subOU structure you would have to check every subobject's ACL
instead of just the OU's ACL to list the DNs of the objects directly under
an OU (i.e. one level). At best if you had n objects at a single level within
an OU you would have n+1 checks. One check for the OU and one check for every
single object. At worst that would be n*2 with the OU being checked every time
an object is also checked. joe From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, Guido there is always something new to learn
;-) Thanks Eric, I wasn't aware of that one (but I can confirm that I've
never noticed any difference in performance myself). Can you elaborate a little as to why a
double ACL check is required? /Guido From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman The typical negative thing associated with
list_object mode is the double ACL check required which can have a performance
overhead. I couldn’t quantify what “perf overhead” means as
frankly I’ve never seen a number from the test team on what that overhead
is, but it is exists, and perhaps in some cases is measurable. It is probably
quite small in the aggregate though. I would venture to guess that in order to
really feel the overhead one would need a pretty serious load, and single
instance store of SDs makes this even more true (caching benefits felt there),
and you’d need a query load that lends itself to having this overhead
(some probably do not). But that last bit is speculation on my part. ~Eric From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, Guido Hello Mika - I have not found any
negative effects by List object mode on other apps whatsoever. And there
shouldn't be any either, since it doesn't change the underlying security
mechanisms at all. It merely gives you the option to distinguish between
the list content and
list object permission,
which would otherwise always be applied in parallel (i.e. you don't even see
the list object permission, but it's always applied when you grant the list
content right, e.g. when you grant read permissions on an OU). I've used it for quite a few
companies already and it works like a charm. Realize that the theory behind the
list object permission is rather easy (allows you to distinguish which objects
someone can see in an OU - such as only specific sub-OUs). However, correctly
leveraging list object mode does add complexity to the overall security modell
and requires people that really know what they're doing. People need to fully understand the
various permissions granted by default in AD and then need to take some of
these away (mainly the Read-Permission for Auth. Users on OUs) before they can
take advantage of the list object permissions in the first place. They also
need to understand the impact on GPOs, as the required permissions to read
GPOs are usually granted via the Auth. User permission on an OU... - so you
need to mimik these permissions as well (not only for users, but also for
the computer accounts). Usually it's those companies that have a
distinct desire to tighten security in AD - these will also invest in the extra
time needed to plan the security model and to manage it in the longrun. Thus,
the list object permission is nothing that you'd just want to leverage for the
fun of it or because it's cool - if there's a business case (i.e. need to
restrict what people can see in AD), then it makes sense, otherwise it doesn't. /Guido From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of I haven't found too many comments discussing the use of list
object mode in production environments. Anybody care to share their experiences
when enabling the list object mode. Has it affected applications running on top
of AD such as Exchange & SMS? Thanks in advance Mika |
- RE: [ActiveDir] List object mode Mika Seitsonen
- Mika Seitsonen
