Re: Share Permissions and Security Groups
From: Roger Abell [MVP] (mvpNoSpam_at_asu.edu)
Date: 12/22/04
- Next message: Jose Jarabo: "Program deleting itself after Execution"
- Previous message: Bob McCoy [MSFT]: "Re: Something is changing my firewall settings!"
- In reply to: jmos: "Re: Share Permissions and Security Groups"
- Next in thread: jmos: "Re: Share Permissions and Security Groups"
- Reply: jmos: "Re: Share Permissions and Security Groups"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Wed, 22 Dec 2004 08:52:26 -0700
"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.
- Next message: Jose Jarabo: "Program deleting itself after Execution"
- Previous message: Bob McCoy [MSFT]: "Re: Something is changing my firewall settings!"
- In reply to: jmos: "Re: Share Permissions and Security Groups"
- Next in thread: jmos: "Re: Share Permissions and Security Groups"
- Reply: jmos: "Re: Share Permissions and Security Groups"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
