File/directory permissions

Archived from groups: microsoft.public.win2000.file_system,microsoft.public.win2000.general,microsoft.public.win2000.security,microsoft.public.windows.file_system (More info?)

Scenario - Windows 2000 Server SP4, name server1:

Created a share on the server called shared$

On users' PCs g: is mapped to \\server1\shared$

directories on g:

projects

client1
- 94m43
admin
estimate
calculations
- 94m44
admin
estimate
calculations

client2
- 99r33
admin
junk
letters

I know that I cannot limit what users will see at the root of g:, like in
Netware environment

I need the following file permissions:

users need to have g: mapped to the "shared$"

Then for example, a global group "Proj94m43" needs to be able to do anything
in admin, estimate, calculation directories but it cannot create directories
or files directly under 94m43. Also, I don't want this group to be able to
open files in other projects, for example 94m44 or client2\99r33, even for
read only. Admins should have access everywhere, of course.

Another group, "Proj99r33" will need to work client2\99r33 subdirectories,
same way as above. There will be new groups, new project subdirectories
established when we get more work.

I thought about leaving the share permissions alone (at default) and control
everything thru NTFS but how exactly do I need to set it?

I understand how they work together (share, ntfs), how they add up under
ntfs, but I need real world examples for complicated setups like mine. I am
moving from Netware and permissions are turning into a nightmare.

I appreciate help with the above and pointers to sites
w/explanations/examples more involved than basic.
8 answers Last reply
More about file directory permissions
  1. Archived from groups: microsoft.public.win2000.file_system,microsoft.public.win2000.general,microsoft.public.win2000.security,microsoft.public.windows.file_system (More info?)

    "Grace" <yyy@yyy.com> wrote in message
    news:ekglsXEcFHA.3932@TK2MSFTNGP12.phx.gbl...
    > I know that I cannot limit what users will see at the root of g:, like in
    > Netware environment

    Don't be so fast. If you happen to be using Windows Server 2003, check out
    ABE, or Access-based Enumeration.

    Windows Server 2003 Access-based Enumeration
    http://www.microsoft.com/windowsserver2003/techinfo/overview/abe.mspx

    This is a feature of Windows Server 2003 Service Pack 1.

    Regards

    Oli
  2. Archived from groups: microsoft.public.win2000.file_system,microsoft.public.win2000.general,microsoft.public.win2000.security,microsoft.public.windows.file_system (More info?)

    Unless I'm missing something, I don't see that this scenario as being
    complex at all.

    When you create the root directory, I'd set the ACL to
    builtin\administrators:F. Don't give any users access (you'll be used to
    this, coming from a Netware background). That way, any newly-created
    projects will have the right permissions by default.

    Then, create a group corresponding to each project, and set the ACL to allow
    members of the group change permissions (C).

    If you prefer to do this from the command prompt, the following command
    would do the trick.

    cacls g:\projects\client1\94m43 /t /e /g proj94m43:C

    From what you've said, the ACL I'd use on the share would be
    builtin\administrators:F, builtin\users:C

    Where this scenario would get complex is if you wanted certain groups of
    users to be able to access only, for example, the calculations folders for
    each project they're working on. I haven't yet seen a convincing solution
    to that problem.

    Regards

    Oli


    "Grace" <yyy@yyy.com> wrote in message
    news:ekglsXEcFHA.3932@TK2MSFTNGP12.phx.gbl...
    > Scenario - Windows 2000 Server SP4, name server1:
    >
    > Created a share on the server called shared$
    >
    > On users' PCs g: is mapped to \\server1\shared$
    >
    > directories on g:
    >
    > projects
    >
    > client1
    > - 94m43
    > admin
    > estimate
    > calculations
    > - 94m44
    > admin
    > estimate
    > calculations
    >
    > client2
    > - 99r33
    > admin
    > junk
    > letters
    >
    > I know that I cannot limit what users will see at the root of g:, like in
    > Netware environment
    >
    > I need the following file permissions:
    >
    > users need to have g: mapped to the "shared$"
    >
    > Then for example, a global group "Proj94m43" needs to be able to do
    > anything
    > in admin, estimate, calculation directories but it cannot create
    > directories
    > or files directly under 94m43. Also, I don't want this group to be able
    > to
    > open files in other projects, for example 94m44 or client2\99r33, even for
    > read only. Admins should have access everywhere, of course.
    >
    > Another group, "Proj99r33" will need to work client2\99r33 subdirectories,
    > same way as above. There will be new groups, new project subdirectories
    > established when we get more work.
    >
    > I thought about leaving the share permissions alone (at default) and
    > control
    > everything thru NTFS but how exactly do I need to set it?
    >
    > I understand how they work together (share, ntfs), how they add up under
    > ntfs, but I need real world examples for complicated setups like mine. I
    > am
    > moving from Netware and permissions are turning into a nightmare.
    >
    > I appreciate help with the above and pointers to sites
    > w/explanations/examples more involved than basic.
    >
    >
    >
  3. Archived from groups: microsoft.public.win2000.file_system,microsoft.public.win2000.general,microsoft.public.win2000.security,microsoft.public.windows.file_system (More info?)

    "Oli Restorick [MVP]" <oli@mvps.org> wrote in message
    news:u%23yhrZFcFHA.1568@TK2MSFTNGP10.phx.gbl...
    > Unless I'm missing something, I don't see that this scenario as being
    > complex at all.
    >
    > When you create the root directory, I'd set the ACL to
    > builtin\administrators:F. Don't give any users access (you'll be used to
    > this, coming from a Netware background). That way, any newly-created
    > projects will have the right permissions by default.
    >
    > Then, create a group corresponding to each project, and set the ACL to
    allow
    > members of the group change permissions (C).
    >
    > If you prefer to do this from the command prompt, the following command
    > would do the trick.
    >
    > cacls g:\projects\client1\94m43 /t /e /g proj94m43:C
    >
    > From what you've said, the ACL I'd use on the share would be
    > builtin\administrators:F, builtin\users:C
    >
    > Where this scenario would get complex is if you wanted certain groups of
    > users to be able to access only, for example, the calculations folders for
    > each project they're working on. I haven't yet seen a convincing solution
    > to that problem.
    >
    > Regards
    >
    > Oli
    >
    >
    >
    > "Grace" <yyy@yyy.com> wrote in message
    > news:ekglsXEcFHA.3932@TK2MSFTNGP12.phx.gbl...
    > > Scenario - Windows 2000 Server SP4, name server1:
    > >
    > > Created a share on the server called shared$
    > >
    > > On users' PCs g: is mapped to \\server1\shared$
    > >
    > > directories on g:
    > >
    > > projects
    > >
    > > client1
    > > - 94m43
    > > admin
    > > estimate
    > > calculations
    > > - 94m44
    > > admin
    > > estimate
    > > calculations
    > >
    > > client2
    > > - 99r33
    > > admin
    > > junk
    > > letters
    > >
    > > I know that I cannot limit what users will see at the root of g:, like
    in
    > > Netware environment
    > >
    > > I need the following file permissions:
    > >
    > > users need to have g: mapped to the "shared$"
    > >
    > > Then for example, a global group "Proj94m43" needs to be able to do
    > > anything
    > > in admin, estimate, calculation directories but it cannot create
    > > directories
    > > or files directly under 94m43. Also, I don't want this group to be able
    > > to
    > > open files in other projects, for example 94m44 or client2\99r33, even
    for
    > > read only. Admins should have access everywhere, of course.
    > >
    > > Another group, "Proj99r33" will need to work client2\99r33
    subdirectories,
    > > same way as above. There will be new groups, new project subdirectories
    > > established when we get more work.
    > >
    > > I thought about leaving the share permissions alone (at default) and
    > > control
    > > everything thru NTFS but how exactly do I need to set it?
    > >
    > > I understand how they work together (share, ntfs), how they add up under
    > > ntfs, but I need real world examples for complicated setups like mine.
    I
    > > am
    > > moving from Netware and permissions are turning into a nightmare.
    > >
    > > I appreciate help with the above and pointers to sites
    > > w/explanations/examples more involved than basic.
    > >


    Thanks, Oli, for your response. Let me see if I understand it correctly:

    share permissions: builtin\administrators:F, builtin\users:C (remove
    Everyone)

    then, ntfs permissions:
    root of g: (let's say directory name is data)
    builtin\administrators:F

    and for the project:
    cacls g:\projects\client1\94m43 /t /e /g proj94m43:C

    But won't they (Proj94m43 group) be able to create subdirectories under
    94m43 this way?

    Sorry if I sound dumb, I'm trying to learn... Thanks,
  4. Archived from groups: microsoft.public.win2000.file_system,microsoft.public.win2000.general,microsoft.public.win2000.security,microsoft.public.windows.file_system (More info?)

    "Grace" <yyy@yyy.com> wrote in message
    news:edQ0xoFcFHA.720@TK2MSFTNGP15.phx.gbl...
    >
    > "Oli Restorick [MVP]" <oli@mvps.org> wrote in message
    > news:u%23yhrZFcFHA.1568@TK2MSFTNGP10.phx.gbl...
    > > Unless I'm missing something, I don't see that this scenario as being
    > > complex at all.
    > >
    > > When you create the root directory, I'd set the ACL to
    > > builtin\administrators:F. Don't give any users access (you'll be used
    to
    > > this, coming from a Netware background). That way, any newly-created
    > > projects will have the right permissions by default.
    > >
    > > Then, create a group corresponding to each project, and set the ACL to
    > allow
    > > members of the group change permissions (C).
    > >
    > > If you prefer to do this from the command prompt, the following command
    > > would do the trick.
    > >
    > > cacls g:\projects\client1\94m43 /t /e /g proj94m43:C
    > >
    > > From what you've said, the ACL I'd use on the share would be
    > > builtin\administrators:F, builtin\users:C
    > >
    > > Where this scenario would get complex is if you wanted certain groups of
    > > users to be able to access only, for example, the calculations folders
    for
    > > each project they're working on. I haven't yet seen a convincing
    solution
    > > to that problem.
    > >
    > > Regards
    > >
    > > Oli
    > >
    > >
    > >
    > > "Grace" <yyy@yyy.com> wrote in message
    > > news:ekglsXEcFHA.3932@TK2MSFTNGP12.phx.gbl...
    > > > Scenario - Windows 2000 Server SP4, name server1:
    > > >
    > > > Created a share on the server called shared$
    > > >
    > > > On users' PCs g: is mapped to \\server1\shared$
    > > >
    > > > directories on g:
    > > >
    > > > projects
    > > >
    > > > client1
    > > > - 94m43
    > > > admin
    > > > estimate
    > > > calculations
    > > > - 94m44
    > > > admin
    > > > estimate
    > > > calculations
    > > >
    > > > client2
    > > > - 99r33
    > > > admin
    > > > junk
    > > > letters
    > > >
    > > > I know that I cannot limit what users will see at the root of g:, like
    > in
    > > > Netware environment
    > > >
    > > > I need the following file permissions:
    > > >
    > > > users need to have g: mapped to the "shared$"
    > > >
    > > > Then for example, a global group "Proj94m43" needs to be able to do
    > > > anything
    > > > in admin, estimate, calculation directories but it cannot create
    > > > directories
    > > > or files directly under 94m43. Also, I don't want this group to be
    able
    > > > to
    > > > open files in other projects, for example 94m44 or client2\99r33, even
    > for
    > > > read only. Admins should have access everywhere, of course.
    > > >
    > > > Another group, "Proj99r33" will need to work client2\99r33
    > subdirectories,
    > > > same way as above. There will be new groups, new project
    subdirectories
    > > > established when we get more work.
    > > >
    > > > I thought about leaving the share permissions alone (at default) and
    > > > control
    > > > everything thru NTFS but how exactly do I need to set it?
    > > >
    > > > I understand how they work together (share, ntfs), how they add up
    under
    > > > ntfs, but I need real world examples for complicated setups like mine.
    > I
    > > > am
    > > > moving from Netware and permissions are turning into a nightmare.
    > > >
    > > > I appreciate help with the above and pointers to sites
    > > > w/explanations/examples more involved than basic.
    > > >
    >
    >
    > Thanks, Oli, for your response. Let me see if I understand it correctly:
    >
    > share permissions: builtin\administrators:F, builtin\users:C (remove
    > Everyone)
    >
    > then, ntfs permissions:
    > root of g: (let's say directory name is data)
    > builtin\administrators:F
    >
    > and for the project:
    > cacls g:\projects\client1\94m43 /t /e /g proj94m43:C
    >
    > But won't they (Proj94m43 group) be able to create subdirectories under
    > 94m43 this way?
    >
    > Sorry if I sound dumb, I'm trying to learn... Thanks,
    >
    >

    You have restated it well, and also noticed that Oli apparently overlooked
    the requirement that the users not be able to create new subfolders or files
    directly under a project's folder.

    If you were to set the permissions manually in the NTFS Security dialog,
    assuming each project of say Client1 is to be totally separate from the
    other projects of Client1, then at the folder for the project you would
    grant List folder contents, and Read to the group of the project.
    The Read is not needed if there will be no files directly under the
    project's directory but instead only the subfolders, and it would need
    to be Read/Execute if there are to be executables directly under the
    project's directory.
    This grant could be done, using the prior example with
    cacls g:\projects\client1\94m43 /t /e /g proj94m43:R

    Then, and this part is not easily done with Cacls (but is with xcacls)
    on each subfolder within the project's directoy one would grant Modify
    to the project group. Now, in order to prevent them from modifying
    (as in deleting) the sobfolder itself you would click on Advanced to leave
    the generic grants view of the ACL and select the newly added grant to
    proj98m43 and use the edit button to access the bits of the ACE where
    you would use the Applies to dropbox to change the setting from
    This folder, subfolders, and file to instead say Subfolders and files.

    So, you end up with something like

    projects < Admins full from here on down

    client1 < This would be a good place to set Read for Client1
    owner/auditor etc.
    - 94m43 < group proj94m43 gets read (execute) from here on down
    admin < group proj94m43 gets change within this (not of
    this)
    estimate < group proj94m43 gets change within this (not of
    this)
    calculations < group proj94m43 gets change within this (not
    of this)
    - 94m44 < group proj94m44 gets read (execute) from here on down
    admin < group proj94m44 gets change within this (not of
    this)
    estimate < group proj94m44 gets change within this (not of
    this)
    calculations < group proj94m44 gets change within this (not
    of this)

    Finally, it actually is possible to set the three identical subfolder grants
    on
    their parent so that the permission does not apply to the parent but is only
    inherited from it, but that is a little tricky without direct setting of the
    ACE bits.

    xcacls is more flexible that is cacls and the script version xcacls.vbs
    (available at microsoft.com/downloads) is even more flexible when
    it comes to setting grants/denies that are not "generic" (applying set
    combinations to This folder, subfolders and files).

    --
    Roger
  5. Archived from groups: microsoft.public.win2000.file_system,microsoft.public.win2000.general,microsoft.public.win2000.security,microsoft.public.windows.file_system (More info?)

    Grace,

    Just as an FYI, although you have Windows 2000 you may be interested
    to know that Windows Server 2003 can now show the behavior you are
    used to in Netware, where a user sees only what they are allowed to
    access. For W2k3 Sp1 and later only
    http://www.microsoft.com/downloads/details.aspx?FamilyID=04A563D9-78D9-4342-A485-B030AC442084&displaylang=en

    --
    Roger Abell
    Microsoft MVP (Windows Security)
    MCSE (W2k3,W2k,Nt4) MCDBA
    "Grace" <yyy@yyy.com> wrote in message
    news:edQ0xoFcFHA.720@TK2MSFTNGP15.phx.gbl...
    >
    > "Oli Restorick [MVP]" <oli@mvps.org> wrote in message
    > news:u%23yhrZFcFHA.1568@TK2MSFTNGP10.phx.gbl...
    > > Unless I'm missing something, I don't see that this scenario as being
    > > complex at all.
    > >
    > > When you create the root directory, I'd set the ACL to
    > > builtin\administrators:F. Don't give any users access (you'll be used
    to
    > > this, coming from a Netware background). That way, any newly-created
    > > projects will have the right permissions by default.
    > >
    > > Then, create a group corresponding to each project, and set the ACL to
    > allow
    > > members of the group change permissions (C).
    > >
    > > If you prefer to do this from the command prompt, the following command
    > > would do the trick.
    > >
    > > cacls g:\projects\client1\94m43 /t /e /g proj94m43:C
    > >
    > > From what you've said, the ACL I'd use on the share would be
    > > builtin\administrators:F, builtin\users:C
    > >
    > > Where this scenario would get complex is if you wanted certain groups of
    > > users to be able to access only, for example, the calculations folders
    for
    > > each project they're working on. I haven't yet seen a convincing
    solution
    > > to that problem.
    > >
    > > Regards
    > >
    > > Oli
    > >
    > >
    > >
    > > "Grace" <yyy@yyy.com> wrote in message
    > > news:ekglsXEcFHA.3932@TK2MSFTNGP12.phx.gbl...
    > > > Scenario - Windows 2000 Server SP4, name server1:
    > > >
    > > > Created a share on the server called shared$
    > > >
    > > > On users' PCs g: is mapped to \\server1\shared$
    > > >
    > > > directories on g:
    > > >
    > > > projects
    > > >
    > > > client1
    > > > - 94m43
    > > > admin
    > > > estimate
    > > > calculations
    > > > - 94m44
    > > > admin
    > > > estimate
    > > > calculations
    > > >
    > > > client2
    > > > - 99r33
    > > > admin
    > > > junk
    > > > letters
    > > >
    > > > I know that I cannot limit what users will see at the root of g:, like
    > in
    > > > Netware environment
    > > >
    > > > I need the following file permissions:
    > > >
    > > > users need to have g: mapped to the "shared$"
    > > >
    > > > Then for example, a global group "Proj94m43" needs to be able to do
    > > > anything
    > > > in admin, estimate, calculation directories but it cannot create
    > > > directories
    > > > or files directly under 94m43. Also, I don't want this group to be
    able
    > > > to
    > > > open files in other projects, for example 94m44 or client2\99r33, even
    > for
    > > > read only. Admins should have access everywhere, of course.
    > > >
    > > > Another group, "Proj99r33" will need to work client2\99r33
    > subdirectories,
    > > > same way as above. There will be new groups, new project
    subdirectories
    > > > established when we get more work.
    > > >
    > > > I thought about leaving the share permissions alone (at default) and
    > > > control
    > > > everything thru NTFS but how exactly do I need to set it?
    > > >
    > > > I understand how they work together (share, ntfs), how they add up
    under
    > > > ntfs, but I need real world examples for complicated setups like mine.
    > I
    > > > am
    > > > moving from Netware and permissions are turning into a nightmare.
    > > >
    > > > I appreciate help with the above and pointers to sites
    > > > w/explanations/examples more involved than basic.
    > > >
    >
    >
    > Thanks, Oli, for your response. Let me see if I understand it correctly:
    >
    > share permissions: builtin\administrators:F, builtin\users:C (remove
    > Everyone)
    >
    > then, ntfs permissions:
    > root of g: (let's say directory name is data)
    > builtin\administrators:F
    >
    > and for the project:
    > cacls g:\projects\client1\94m43 /t /e /g proj94m43:C
    >
    > But won't they (Proj94m43 group) be able to create subdirectories under
    > 94m43 this way?
    >
    > Sorry if I sound dumb, I'm trying to learn... Thanks,
    >
    >
    >
  6. Archived from groups: microsoft.public.win2000.file_system,microsoft.public.win2000.general,microsoft.public.win2000.security,microsoft.public.windows.file_system (More info?)

    Hi Oli (or anyone who can answer this),
    Thanks for the info. I went to the link and downloaded the document. While
    I do have service pack 1 installed I do not the the access-based Enumeration
    tab on a shared folder or on a folder I want to be shared. Is there anything
    else I need to have setup besides SP1 My windows server2003?

    Thanks

    "Oli Restorick [MVP]" wrote:

    > "Grace" <yyy@yyy.com> wrote in message
    > news:ekglsXEcFHA.3932@TK2MSFTNGP12.phx.gbl...
    > > I know that I cannot limit what users will see at the root of g:, like in
    > > Netware environment
    >
    > Don't be so fast. If you happen to be using Windows Server 2003, check out
    > ABE, or Access-based Enumeration.
    >
    > Windows Server 2003 Access-based Enumeration
    > http://www.microsoft.com/windowsserver2003/techinfo/overview/abe.mspx
    >
    > This is a feature of Windows Server 2003 Service Pack 1.
    >
    > Regards
    >
    > Oli
    >
    >
    >
  7. Archived from groups: microsoft.public.win2000.file_system,microsoft.public.win2000.general,microsoft.public.win2000.security,microsoft.public.windows.file_system (More info?)

    "Roger Abell" <mvpNOSpam@asu.edu> wrote in message
    news:%23$JddxKcFHA.3184@TK2MSFTNGP15.phx.gbl...
    > You have restated it well, and also noticed that Oli apparently overlooked
    > the requirement that the users not be able to create new subfolders or
    > files
    > directly under a project's folder.

    Thanks, Roger. I did overlook that.

    Regards

    Oli
  8. Archived from groups: microsoft.public.win2000.file_system,microsoft.public.win2000.general,microsoft.public.win2000.security,microsoft.public.windows.file_system (More info?)

    No problem Oli - a short phrase that made much difference.
    Later,
    --
    Roger

    "Oli Restorick [MVP]" <oli@mvps.org> wrote in message
    news:uiBfe9ccFHA.2180@TK2MSFTNGP12.phx.gbl...
    >
    > "Roger Abell" <mvpNOSpam@asu.edu> wrote in message
    > news:%23$JddxKcFHA.3184@TK2MSFTNGP15.phx.gbl...
    > > You have restated it well, and also noticed that Oli apparently
    overlooked
    > > the requirement that the users not be able to create new subfolders or
    > > files
    > > directly under a project's folder.
    >
    > Thanks, Roger. I did overlook that.
    >
    > Regards
    >
    > Oli
    >
    >
Ask a new question

Read More

File System Microsoft Permissions Windows