On a similar note, is anyone using 2012 AD claims based permissions on their file servers?
Gavin Wilby IT Support Engineer From: [email protected] [mailto:[email protected]] On Behalf Of Matthew Topper Sent: 02 July 2015 14:28 To: [email protected] Subject: RE: [NTSysADM] permission/ share life lesson I much prefer to set the NTFS permissions the way I want them and leave the share permissions as everyone. I don’t want to need to think about making a change in both places, and keeping them in sync, when troubleshooting a permissions problem. Given the above premise (that I’m only changing one), I’d prefer the granularity of NTFS to share permissions. Matthew Topper From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Melvin Backus Sent: Thursday, July 2, 2015 9:22 AM To: [email protected]<mailto:[email protected]> Subject: RE: [NTSysADM] permission/ share life lesson While that may be true, I’ve spent the last couple of days trying to document the permissions on about 15 shares because the structure was created by someone who’s gone and chose to set them at the user level rather than by groups. Thousands of files and folders, and creating a comprehensive report is painful. Share permissions may be a hold over, but in all of our uses they are more than adequate and infinitely simpler to maintain. That all seems to have strayed from the original premise however. If share permissions and NTFS permissions match, what’s the benefit of setting both? Either set the share for full access for everyone and let the file permissions handle it or set the file permissions to everyone and set the share as needed. The later BTW is MUCH faster to change because there’s never any propagation to do. I’m not saying one is better than the other, simply that doing both seems redundant. -- There are 10 kinds of people in the world... those who understand binary and those who don't. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Rankin, James R Sent: Thursday, July 2, 2015 8:41 AM To: [email protected]<mailto:[email protected]> Subject: Re: [NTSysADM] permission/ share life lesson But you wouldn't ever want to change the share perms, at least not in my experience, once they're set once they're set forever. Permissions at the share level seems to be a hangover from pre-NTFS days, IMHO ------- James Rankin | Director | TaloSys | 07809668579 Sent from my Blackberry ________________________________ From: Melvin Backus <[email protected]<mailto:[email protected]>> Sender: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Date: Thu, 2 Jul 2015 13:08:13 +0100 To: [email protected]<[email protected]<mailto:[email protected]%[email protected]>> ReplyTo: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: RE: [NTSysADM] permission/ share life lesson Couldn’t the same be said in reverse? That also means they no longer match and there’s a new scenario. -- There are 10 kinds of people in the world... those who understand binary and those who don't. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of James Rankin Sent: Thursday, July 2, 2015 7:27 AM To: [email protected]<mailto:[email protected]> Subject: RE: [NTSysADM] permission/ share life lesson Easy example would be if you change the NTFS permissions in future, you don’t need to update the Share permissions. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Melvin Backus Sent: 02 July 2015 12:08 To: [email protected]<mailto:[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]> [mailto:[email protected]] On Behalf Of Michael B. Smith Sent: Wednesday, July 1, 2015 11:14 PM To: [email protected]<mailto:[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]> [mailto:[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]<mailto:[email protected]>> wrote: Having trouble figuring this. I need to be able to write files to a \\server\share\folder\folder\blah<file:///\\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<file:///\\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<tel:317.554.8190> | F: 317.554.8106<tel:317.554.8106> [Description: imcu email icon]<http://imcu.com/> [Description: facebook email icon] <https://www.facebook.com/IndianaMembersCU> [Description: twitter email icon] <https://twitter.com/IndMembersCU> [Description: email logo] [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. SMP Partners Limited, SMP Trustees Limited and SMP Fund Services Limited are licensed by the Isle of Man Financial Supervision Commission. SMP Accounting & Tax Limited is a member of the ICAEW Practice Assurance Scheme. SMP Partners Limited registered in the Isle of Man, Company Registration No: 000908V Directors: M.W. Denton, M.J. Derbyshire, S.E McGowan, O. Peck, J.J. Scott, S.J. Turner SMP Trustees Limited registered in the Isle of Man, Company Registration No: 068396C Directors: A.C. Baggesen, M.W. Denton, O. Peck, J.J. Scott, J. Watterson, J. Cubbon SMP Fund Services Limited registered in the Isle of Man, Company Registration No: 120288C Directors: V. Campbell, M.W. Denton, D.A. Manser, S.E McGowan, J.J. Scott, R.K. Corkill SMP Accounting & Tax Limited registered in the Isle of Man, Company Registration No: 001316V Directors: I.F. Begley, A.J. Dowling, P. Duchars, J.J. Scott, S.J. Turner SMP Capital Markets Limited registered in the Isle of Man, Company Registration No: 002438V Directors: M.W. Denton, M.J. Derbyshire, D.F Hudson, S.E McGowan, O. Peck, J.J. Scott. SMP Partners Limited, SMP Trustees Limited, SMP Fund Services Limited, SMP Accounting & Tax Limited and SMP Capital Markets Limited are members of the SMP Partners Group of Companies. This email is confidential and is subject to disclaimers. Details can be found at: http://www.smppartners.com/disclaimer.asp ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________
