Re: Share Permissions and Security Groups by Roger
Roger
Wed Dec 22 17:04:27 CST 2004
"jmos" <jmos@discussions.microsoft.com> wrote in message
news:7DFD17A8-CE83-431D-8963-037671A03F2D@microsoft.com...
>
>
> "Roger Abell [MVP]" wrote:
>
> > "jmos" <jmos@discussions.microsoft.com> wrote in message
> > news:573D3611-5A7E-44CA-A8C4-4F84721FE00E@microsoft.com...
> > >
> > >
> > > "Roger Abell" wrote:
> > >
> > >> "jmos" <jmos@discussions.microsoft.com> wrote in message
> > >> news:0C79070A-A656-44E4-80DD-E5F31D940978@microsoft.com...
> > >> > I have the follwoing setup and I wanted to know if this is correct.
> > >> >
> > >> > Global Domain Share Share SubFolder
> > >> > Group local Perms NTFS NTFS
> > >> >
> > >> > PrjGrp1 Dept Dept-FC Dept-RX PrjGrp1-Modify
> > >> >
> > >> > The PrjGrp1 group is a global group of user accounts for an OU.
> > >> > The Dept group is Domain local for the OU which has a member of
> > >> > PrjGrp1.
> > >> >
> > >> > A Share call Sales has share permissions for the Domain Local group
> > >> > Dept
> > >> as
> > >> > Full control. I know I can put the group Everyone but this adds an
> > >> > extra
> > >> > layer of security to the whole setup.
> > >> >
> > >> > The Sales Share NTFS permissions has the same domain local group
but
> > >> > here
> > >> it
> > >> > is given only Read, Execute and list folder permissions.
> > >> >
> > >> > A subfolder within the Sales Share - Project1 has NTFS permissions
set
> > >> > to
> > >> > Modify for PrjGrp1 global group.
> > >> >
> > >> > This means that if Fred is in Global groups PrjGrp1 and PrjGrp3
(each
> > >> > referencing a subfolder in the Sales share ie Project 1 and Project
3),
> > >> > he
> > >> > will not gain access to the subfolder Project2 within Sales and the
> > >> > NTFS
> > >> > share permissions will not allow him to fiddle within the Share
folder
> > >> itself.
> > >> >
> > >> > For one domain setup are my group assignments correct? Should I
make
> > >> > the
> > >> > Dept group a Global Group instead of a Domain local or should I be
> > >> > looking
> > >> at
> > >> > a different setup?
> > >> >
> > >> > TIA
> > >>
> > >> What you outline seems reasonable to allow the member of the
> > >> PrjGrp1 global to have access to not alter the root of the shared
> > >> area but to be able to modify the folder within.
> > >> Use of domain locals is handy if you might need to place the
> > >> storage on a member server.
> > >> If the account is in no group that directly or indirectly has been
> > >> granted access to Project2 subfolder, then the account will have
> > >> no access there. However, note that the grant at the root of the
> > >> shared area may be inherited onto Project2, thus allowing the
> > >> account to list the folder, read/execute files of the folder. To
> > >> have not access granted to the account the NTFS permissions
> > >> on the Project2 folder would need to not inherit from its parent.
> > >>
> > >> You showed use of the global to grant modify on the subfolder.
> > >> There is no clear reason here to use the global instead of the
> > >> domain local Dept group for the subfolder grant.
> > >>
> > >> In general, I would suggest that you always collect accounts
> > >> into groups of users, and that you then define groups for the
> > >> resources that are controlled and add the groups of principals
> > >> into the resource access groups. This will allow you to look
> > >> at the memberships (in the one domain scenario) of an account,
> > >> and then to look at the memberships of the principal groups in
> > >> which the account is a member in order to see what resources
> > >> the account can access (the list of resource groups). If you
> > >> directly grant resource accesses with the principal group (as
> > >> you have done on the subfolder) then you will need some other
> > >> method to keep track of the resources to which an account has
> > >> been granted access.
> > >> --
> > >> Roger Abell
> > >> Microsoft MVP (Windows Security)
> > >> MCSE (W2k3,W2k,Nt4) MCDBA
> > >>
> > >
> > > Hi Roger
> > > Thank you for your reply.
> > > From your comments I ensure that each Project Folder NTFS does not
inherit
> > > the permissions from the Parent Share NTFS. This undoubtely enforces a
> > > greater degree of security. Furthermore I have to ensure that all
> > > securities
> > > work to avoid the indirect access which may occur with a complex
security
> > > setup.
> > >
> > > The use of global to grant modify access is necessary to allow only
that
> > > group access to that sub Project Folder and one issue which I have
debated
> > > for a while. The domain local group acts as a container for all the
PrjGrp
> > > principals which gives access to the share allbeit tightly controlled
and
> > > then the NTFS of each Project Folder gives only it associated Global
group
> > > access.
> > >
> > > If my share is the resource and the domain local group is its
equivalent
> > > for
> > > users then I see the setup like a bow tie.
> > >
> > > Global Groups Domain Share
> > > Project Folders
> > > Local +NTFS
> > > NTFS
> > >
> > > PrjGrp1 ----------------------\
> > > /--------(PrjGrp1)-----------Proj 1
> > > PrjGrp2 ------------------------ Dept----------Dept --------
> > > (PrjGrp2)---------- Proj 2
> > > PrjGrp3 ----------------------/
> > > \--------(PrjGrp3)---------- Proj 3
> > >
> > > Seeing as each Project Group pertains to only one Project Folder ie
they
> > > are
> > > pretty much called the same, then I can always tell which resources
each
> > > user
> > > has access to as its noted in their user account information.
> > >
> > > Jmos
> >
> > There is always a cut-off between explosion in the number of groups
> > and forcing the OS groups to self-document for you.
> > I like to not depend on out-of-band documentation methods, and their
> > being kept up-to-date
> > In a case like yours, consider
> > Usrs_PrjGrp1
> > Usrs_PrjGrp2
> > etc. to collect users
> >
> > Project1 <== Usrs_PrjGrp1
> > etc. for use on the NTFS level
> > perhaps Project3 <== Usrs_PrjGrp1 + Usrs_PrjGrp2
> > so the naming might better be other than Usrs_PrjGrp1, etc.
> > for example perhaps these people are a natural group within
> > your organization (other than just having access to these files
> > as what is in common).
> >
> > Then for share level permissions such as
> > Project_Share <== Project1 + Project2 + . . .
> > so that the share permissions are scoped to allow the groups
> > that are granted at the NTFS level.
> >
> > If you do this, or similar, correctly, then the groups document
> > the grants so that you will not need to examine the NTFS structures
> > or shares in the future to see who has what, and also you will end
> > up making user account members of only a few groups and as a
> > consequence they will automatically have the resources appropriate
> > to the principal groups they are in.
> >
>
> Thanks Roger
> I get the feeling we are saying the same sort of thing here.
>
Yes, after reading your reply I do think we are close, but
in different terms. My objectives are
1. be able to have a user account in an absolute minimum
of groups (directly), ideally one that identifies their
primary role (or few for their roles) in the organization
2. use nesting so that all else just happens once the account
is tied to its role(s)
3. define share permissions and the subsections (ntfs) of
what is shared once (for each section at least) and never
have to revisit (except auditing that it remains as intended)
4. be able to state all resource accesses by recursing memberships
> Your Usrs_PrjGrp1 is my PrjGrp1.
> Your Project1 is my Dept.
>
yep - I added Usrs_ just to emphasize it is not used on resources but
only exists to categorize accounts and is only used to populate groups
that are on the resources
> Only difference is that I choose to place all Usrs_PrjGrp's (I'll use your
> notation) into Dept Domain local group rather than list them all under the
> Project_Share permissions. If I may briefly explain, each Share may have
10's
not the only. If multiple of the Usrs_PrjGrps should have access at some
NTFS branch, like where you have used Dept, then yes, those groups are
members in the Dept. But I was saying not to use Dept at the share level
also, rather defining Project_Share for that. So, pattern is
resource group for the NTFS branch
this resource group is member in the share granting group (along with
all other resource groups for NTFS areas in the share)
this resource group has as its own members only principal groups (Usrs_*)
The principal groups are not necessarily defined because of the existance
of the project (i.e. the NTFS branch) but might be, or they may pre-exist
due to other aspects of your organization.
> of projects. To list each over time is not so bad, but when I have to
> recreate the whole share due to lack of storage (long story) etc.. I
become
> lazy and so place all the user groups into one domain local group used at
> share and share ntfs permission level.
The group membership nesting can be read with script, and that script
can output cmd set that will recreate the groups. However, using domain
locals means you do not need to do that when the storage is moved to
a different device or server.
I would suggest that you consider templating the NTFS of the storage
area. It should only change when a new NTFS tree is added. The
template is of use on another server (or disk) with the only change that
might be needed is a global replace of F:\ with X:\ if letters change.
>
> What I had not considered was your Project3 example, where I could
> 'recycle' existing groups to combine the necessary user groups. Yes I do
have
> a problem with group explosion but this unfortunatley is a trait I have to
> deal with as the network has to be audited and securities be 'clear' to
the
> untrained eye.
I think that for monitoring and auditing erring on the side of group
explosion (with comprehensibility controlled by structured nesting)
is the way to go. This allows you to have _a_ paradigm that _is_ how
it is. As soon as one wanders into "it is mostly done this way, but on
that X we granted directly to . . ., and on that Y we . . ." one looses
transparency as to whether things really are as intended.
>
> Enumarating groups for login purposes is a pain so I have considered using
That is where the objective of having accounts only need direct membership
in a minimum number of groups comes in. For example, other than things like
Domain Users, if an account can only be in a group that starts BaseRole_
and you know that these are all fundemental (not composite, formed from
other BaseRole_ groups) then you have limited the set of groups of interest
in the enumeration.
> OU's with specific GPO's and login scripts to deal with the issue but all
the
> staff here float bewteen project to project across multiple departments. I
do
that would make "role" identification a bit more challenging, but you would
need to examine how people function in your organization and attempt some
categorization. For example, if some of the folks that travel into many of
the projects do so because they consult on design, or on operational
methods,
etc. perhaps there should be a group for them, and it is member in the
project's
resource group during the time of their involvement.
> to an extent combine groups, ie. a Directors and Domain Admin Group
generally
> have access to most projects. These get placed into each Usrs_PrjGrp's
along
> with other, separate user accounts.
>
> In your Project_Share example are you not complicating things or am I
> misreading?
I think we were close to saying the same, but I was trying to untie the
multiple uses you have made of Dept, and also I was trying to indicate
that by nesting all NTFS area groups into the Share group, then you only
need to adjust the NTFS group membership and the Share level grant will
happen automatically.
> If Placing the Project1, 2 groups in another Project_Share group is what
you
> are suggesting (all Domain Local) is this not complicating things and my
> example of bypassing the Project1, 2 groups by placing the Usrs_PrjGrp
> directly into a domain local Project_Share better?
>
To change access you need to adjust membership of two groups then.
This 1) gives room for human error; 2) provides a place where you
could exert a second independent check controlling the access
> One main reason for doing it the way I have suggested is that I'm not
always
> the person who sets up the permissions. Telling certain key people that
the
> only thing they have to do is :
> create a global group
if needed (the account may already be grouped together in the base roles)
> add the users and other groups required
> adding this to a preset domain local group named after the Share in
question
for me it is named after the new resource, i.e. NTFS branch
> - not have to create another
did not follow that part
> Then go to the share, create a new project folder
> untick the inherit permissions on the NTFS tab
> remove all groups not required and add the newly created global project
group
I would add the new resource domain local group to the storage branch
and then add it as a member of the group used at the share level
(note: I am assuming we are still speaking of multiple differently
ACL branches all within one share)
> then wait for a while
Yep, or have them log off/in
In my way, when one needs to change who is allowed on
projectX one needs only to add/remove Usr_ principal groups
to/from the ProjectX group (that is used on the NTFS branch
and is in the share group).
>
> seems simpler to me but I could well be wrong.
>
> Let me know your thoughts.
>
> Apologies for the length of the posting but a great many thanks for all
the
> advice. I think this has turned out to be a good debate!
>
Always fun to exchange viewpoints/experiences. It often depends
on what one chooses to emphasize (ex. long term simplicity or the
simplicity of the immediate task to set up initially) and what demands
are considered (movability/storage reorg across servers, etc..)
--
Roger