Agreed. And I prefer that people who shouldn't be able to see the data, also can't connect to the share. Otherwise, they're just using up resources and one mistake away from having access to something they probably shouldn't.
I like defensive layers... *ASB **http://XeeMe.com/AndrewBaker* <http://xeeme.com/AndrewBaker> *Providing Virtual CIO Services (IT Operations & Information Security) for the SMB market…* On Thu, Jul 2, 2015 at 10:31 AM, Michael B. Smith <[email protected]> wrote: > I script everything, so it’s not work. > > > > I don’t give FC, because that’s just too much power. Modify, at best. > > > > Different strokes. > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Melvin Backus > *Sent:* Thursday, July 2, 2015 7:08 AM > *To:* [email protected] > *Subject:* RE: [NTSysADM] permission/ share life lesson > > > > Perhaps I’m missing something but I’m curious as to the benefit of > changing the NTFS permissions if they match the share permissions. It > seems like more work for no gain. Obviously you have greater granularity > with file permissions, but when they match I’m not seeing the point. > > > > -- > There are 10 kinds of people in the world... > those who understand binary and those who don't. > > > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *Michael B. Smith > *Sent:* Wednesday, July 1, 2015 11:14 PM > *To:* [email protected] > *Subject:* RE: [NTSysADM] permission/ share life lesson > > > > That’s completely a workable solution as well. I have simply a “habit” to > match share and NTFS permissions. > > > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *Kurt Buff > *Sent:* Wednesday, July 1, 2015 9:59 PM > *To:* ntsysadm > *Subject:* Re: [NTSysADM] permission/ share life lesson > > > > While MBS says give them modify permissions on the share, it's been my > long-standing practice to give Full permissions to Everybody on the share, > and then use NTFS permissions underneath. MBS' approach surely works, but I > just find it easier to remember/manage if all shares are set the same way. > > I also only use grant permissions - never deny. > > For instance, assume DirectoryA1 should not be writeable for users, and > not should DirectoryB1, but DirectoryB1 should be read-write for users. In > the security dialog for each directory's properties, select Advanced to set > the type of inheritance (This folder only, vs. This folder, subfolders and > files.) > > > > Volume <<<< Grant Administrators Full (This folder, subfolders and > files), Users Read (This folder only) > > | > > DirectoryA1 <<<< Grant Users Read (This folder only) (Administrators > inherit Full from volume root) > > | > > DirectoryB1 <<<< Grant users Read (This folder, subfolders and > files) (Administrators inherit Full from volume root) > | > > DirectoryB2 <<<< Grant Users Read-write (This folder, subfolders > and files) (Administrators inherit full from volume root) > > This can be scripted with any number of tools, probably including > PowerShell, though I haven't done that yet, icacls and my old favorite > fileacl. > > Here's a writeup I did for our file server, for the Groups share (which is > basically the departmental share, where each department gets their own > subdirectory). It includes the fileacl syntax for the initial configuration > of a new departmental directory, along with guidelines on how IT will > manage the directory: > > FILEACL "k:\groups\Example" /INHERIT /REPLACE /SUB > > FILEACL "k:\groups\Example" /S "CORP\Domain Users":RX/U/U /S > "CORP\ExampleManagers":RAWaWeXDc/U /S "CORP\ExampleUsers":RX/U/U /REPLACE > > FILEACL "k:\groups\Example\Private" /S "CORP\ExampleManagers":RWXD /S > "CORP\ExampleUsers":RWXD > > FILEACL "k:\groups\Example\Public" /S "CORP\Domain Users":RX /S > "CORP\ExampleManagers":RWXD /S "CORP\ExampleUsers":RWXD > > > Directions for using this directory: > > 1) Only new directories can be created at the top level of this directory > (k:\groups\Example) - not new files - and those can only be created by > usGroupsExampleManagers or by IT. > > 2) If a new top-level directory is created, initial permissions on it will > only be for usHomeGroupsExampleManagers - any further permissions will need > to be added by IT. > > 3) The Private directory is restricted to members of the department. The > Public directory is read-write for members of the department, and read-only > for the rest of the org. > > 4) Permissions will only be placed on top-level directories within the > departmental directory. If permissions need to be modified further down the > directory tree, the subdirectory in question should be moved to another > top-level folder. > > HTH, > > Kurt > > > > > > On Wed, Jul 1, 2015 at 5:56 PM, David McSpadden <[email protected]> wrote: > > Having trouble figuring this. > > I need to be able to write files to a \\server\share\folder\folder\blah. > That relates to volume:folder\share\folder\folder\blah > > I have permission of volume:folder\share\folder\folder\ domain admin:full > everyone:read and share permission \\server\share domain admin:full > everyone:read. > > Well come to find out everyone needs to be able to write to blah. > > How do I give them that ability with giving them write on folder\folder as > well? > > And yes, please smack me around I should know this easily but it is > escaping me for some reason. > > > > > > > > > > > > > > > > *David McSpadden* > > Systems Administrator > > Indiana Members Credit Union > > P: 317.554.8190 | F: 317.554.8106 > > [image: Description: imcu email icon] <http://imcu.com/> [image: > Description: facebook email icon] > <https://www.facebook.com/IndianaMembersCU> [image: Description: twitter > email icon] <https://twitter.com/IndMembersCU> > > > > [image: Description: email logo] > > [image: mcp2] > > > > This e-mail and any files transmitted with it are property of Indiana > Members Credit Union, are confidential, and are intended solely for the use > of the individual or entity to whom this e-mail is addressed. If you are > not one of the named recipient(s) or otherwise have reason to believe that > you have received this message in error, please notify the sender and > delete this message immediately from your computer. Any other use, > retention, dissemination, forwarding, printing, or copying of this email is > strictly prohibited. > > > > Please consider the environment before printing this email. > > >
