Re: generate a detailed list of account permissions
From: Roger Abell (mvpNOSpam_at_asu.edu)
Date: 03/31/05
- Next message: Roger Abell: "Re: Chunk errors"
- Previous message: Roger Abell: "Re: how to apply w2k security to w2k member servers under w2k3 domain?"
- In reply to: Tom Celica: "Re: generate a detailed list of account permissions"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Thu, 31 Mar 2005 01:37:41 -0700
The answer is to plan. Windows allows for a rather rich
environment, both in types and number of resources and in
ways to categorize accounts and grant access based on those
categories. How many groups in an account in in Unix ?
With Windows you do have a somewhat indexed view in
one direction, but not in the other direction from the resources
back to the accounts.
This is the classic problem of indexing a many to many
relationship without having an explosion of overhead.
The answer is to plan and so grow the environment for
the sake of its future comprehensibility.
I have seen environments that have been grown in an ad hoc
manner, under the hand of a succession of lead admins, that
are a total mess. They have been stretched this way and that,
and then forced into a needle hole here and pulled through a
rusted pipe there.
The answer is to plan, to have a defined methodology, to
have it mapped, and to not vary from it unless the defined
methodology and map is updated.
Example: (Did I say this is just one example?)
Use resource groups. This might be defined, with a naming
convention, that makes clear where they are applied and for
what. That may be a rather specific thing, like deligation of
AD privileges on user account objects, or that may be a more
role-based bundle of things, like some NTFS areas plus some
login rights to a set of machines plus some application publications,
etc.. But, resource groups identify to what they control access
and the type of access they confer.
Use resource group. Have a plan, for their use, for their naming.
Then, define principal groups to categorize user accounts (or
machines). Organize these by the functions/roles people fill,
as is revealed both in the org structure/job title view but also
and importantly in the job tasking and functions.
Place principal groups in resource groups.
Only grant premissions on resources with resource groups.
Principal groups only are used to populate memberships in
resource groups.
Now. Make something along these lines the way things
have to be.
Then, ask: To what does UserX have access
Answer:
from all direct memberships of UserX in principal groups
form closure of all direct and indirect principal groups
that UserX has membership
form closure of all resource groups in which any of the
direct or indirect principal groups of UserX have membership
look at the names of those resource groups, using the naming
convention to understand to what UserX has access and in
what ways
Note that if what in this example was call a resource group
is not used, then one has failed to harness the constructs of the
deployment to facilitate its being "self-documenting". In other
words, placing grants on resources with principal groups, like
a BizOfficeAdmAssistants group, then by looking at the direct
and indirect group memberships of a member of this groups
conveys no knowledge of what accesses are granted where.
If one does not have a deployment strategy, or fails to hold to
it, or has inherited gooblygook, then one must recurse over all
resources in order to determine to what someone has access.
-- Roger Abell Microsoft MVP (Windows Security) MCSE (W2k3,W2k,Nt4) MCDBA "Tom Celica" <Tom@DontReply.net> wrote in message news:IXA2e.8063$zl.6875@newssvr13.news.prodigy.com... > Microsoft's Approach to granted privilages seems very Re-Active. We don't > have sufficient tools to enumerate broad privilages assigned to accounts. > We can check if an account has permissions on a single specific object but > not a variety of objects at once. > > How do we Pro-Actively determine privilages assigned to accounts. We need > to wait until somthing bad happens then look thru logs to determine what > happened, and who did it, before we can discover that excessive privilages > have been assignet to various accounts. > > -Tom > > "Roger Abell" <mvpNOSpam@asu.edu> wrote in message > news:uaYFIbTNFHA.2748@TK2MSFTNGP09.phx.gbl... > > That is frankly like looking for a needle in a haystack. > > You need to narrow things down. What are you looking > > for? Use of the account to grant permissions on C:\ ? > > in registry ? on Com components ? for user rights ? > > etc.. > > > > -- > > Roger Abell > > Microsoft MVP (Windows Security) > > MCSE (W2k3,W2k,Nt4) MCDBA > > "Tom Celica" <Tom@DontReply.net> wrote in message > > news:Axf2e.4341$FN4.267@newssvr21.news.prodigy.com... > >> How can we generate a detailed list of the permissions directly assigned > > to, > >> and inherited to an individual account? > >> > >> Hello, we have an application we received from one of our parter > > companies. > >> It assigned some selective permissions to a particular account. It was > >> supposed to provide a log of the permissions it assigned but we cannot > >> locate that log file. > >> > >> I have tried lots of methods without success yet. Is there a Microsoft > >> tool? or can someone recommend a third party tool? > >> Thanks > >> -Tom > >> > >> > > > > > >
- Next message: Roger Abell: "Re: Chunk errors"
- Previous message: Roger Abell: "Re: how to apply w2k security to w2k member servers under w2k3 domain?"
- In reply to: Tom Celica: "Re: generate a detailed list of account permissions"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
