2

We have recently gotten a new system delivered to us. It's a standard Server 2008 and Windows 7 server-client solution with some tightened security. One of the new security policies have caused a little ruckus among us administrators.

The written policy stipulates that when sharing a resource (file or something) we must now set security on both NTFS and the share. To the best of my knowledge (and my colleagues) Microsoft best practices says that you share a resource to Everyone with full access and then you set the security on the resource itself. This how we've done it since the days of NT 4.

We feel that this new policy has been written by someone who doesn't really grasp how Windows permissions work. Some who thinks that sharing to Everyone is a major security hole, even though NTFS should suffice. We haven't been able to get a straight answer so I ask here. Are we wrong in our assumption that permissions set on the NTFS level is perfectly sufficient?

Improve this question
5
  • If my memory doesn't totally fail me I believe that the best practice was at some time changed to 'Authenticated Users' instead of 'Everyone', and that null session exploits were a part of the picture. I don't have time to verify/piece it together now and hopefully someone else has this fresher up in their heads and can provide a quality answer. There are a couple of default policies in the newer OS versions to prevent these exploits too, but you could perhaps google, and informaticapressapochista.com/windows/…
    – ErikE
    Jan 31, 2014 at 9:51
  • Would perhaps make sense, but our policy says that the permissions set for NTFS also must be set on the share. To me that is both overkill and gives a false sense of security.
    – Sandokan
    Jan 31, 2014 at 9:55
  • 1
    I confess to having difficulty seeing that as a great problem. It is some extra legwork, yes. But how often will you be setting up those shares? And it can easily be scripted if you wish to avoid sprawl between ntfs and share perms down the road. As for security I can't see it being lessened, whilst your current policy certainly had security issues in the past, if no longer. Why the big deal?
    – ErikE
    Jan 31, 2014 at 10:30
  • The problem is that we haven't been given a reason as to why. Experience says that our security department base alot of their policies on assumptions rather than actual facts. If said policy provides a true security benefit then I'm ok with it, but as it is now, no technical background or reason has been given.
    – Sandokan
    Jan 31, 2014 at 11:49
  • 1
    There's a tedious discussion about this from a couple of years ago here: serverfault.com/a/283139/7200 Also, this question is sort of a duplicate of: serverfault.com/questions/286282/windows-share-permissions
    – Evan Anderson
    Jan 31, 2014 at 13:02

2 Answers 2

Reset to default
2

our policy says that the permissions set for NTFS also must be set on the share

They're confused. NTFS offers an extended set of permissions that don't exist for SMB shares so it's impossible to set the same share permisisons as NTFS permissions. Eg. 'List folder Contents'.

http://technet.microsoft.com/en-us/library/cc753731.aspx (Managing Permissions for Shared Folders)

By default, the Everyone group does not include the Anonymous group, so permissions applied to the Everyone group do not affect the Anonymous group.

Improve this answer
0

Recently i had to make user shares in a windows network, basically the same idea as you have with a share in which the file system security defines if users can read it or not.

If you want specific user share rights you need to make a share for every user, share rights only apply to what folder or drive you apply it to. If you wanted to give share rights to parts in the shared object then there should be something like this:

\share{folder1} (accessible by her) \share{folder2} (accessible by him) But that is just plain file system security, so i think you're right

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.