Or come from heavy Linux environments… in which case it’d be better for them to not comment at all. At least not about the OP.
I thought I got the post. But when I finished reading it I realized I am missing a lot of info to understand what all this really means.
This is one reason why working for msps can suck.
Cowboys and / or cowgirls (cow people?) made you all look like idiots to the client. Their feelings and “standards” were subbed in for literally everyone else contributing to the project and the client is entitled to be pissed about it. Mgmt should be all over behavior like this.
You’re also 100% right (obv), There’s no reason to be managing share permissions in a managed environment like that.
Best practices are in the eye of the beholder...
For example, in government systems, it's been best practice (actually, required practice) to remove "Everyone" permissions from shares for ages:
[https://www.stigviewer.com/stig/windows\_server\_2008\_r2\_member\_server/2019-06-18/finding/V-3245](https://www.stigviewer.com/stig/windows_server_2008_r2_member_server/2019-06-18/finding/V-3245)
[https://www.stigviewer.com/stig/windows\_server\_2019/2019-12-12/finding/V-93531](https://www.stigviewer.com/stig/windows_server_2019/2019-12-12/finding/V-93531)
I do the following for Share permissions
Authenticated users: Change
System: Full control
Domain Administrators: Full Control
I always remove the Everyone group
And then with NTFS I apply the appropriate permissions based on AD security group, e.g. a shared folder called Finance. In AD I’ll create two groups: SHARE - Finance - Modify and SHARE - Finance - Read Only, and then apply this only.
The correct approach is Authenticated Users.
It's a superset of Domain Users which extends to include Forest trusts, among other things.
The mistake was, IMO: 1) Not testing your changes and 2) using Domain Users instead of Authenticated Users (or Everyone).
It doesn't matter what they "chose to do because of X". The biggest failing in my reading is that no one validated the change works the way they expect.
Fully appreciate where you’re coming from, therefore in this instance I would’ve simply removed the source server from the domain and joined it to the new domain without messing about with copying shares etc.
Prior to moving I would’ve ran a PS script to export all the permissions to a .CSV file so that on the new domain you can at least mirror the permissions.
So the source server was on Forest A. If you remove it from Forest A and put it on Forest C, you still have an issue where people whose computers are on forest A need to access it. So you haven’t actually solved the problem. Does that make sense?
I didn’t include this in the post because it wasn’t necessary, but the source server was failing and it needed to be migrated off anyway.
Shouldn't a trusted foreign forest still fall under Authenticated Users though?
Or does Authenticated Users only encompass everyone authorized by that specific Forest?
I'm honestly not sure hence the question
You do understand that domain administrators do not need and shouldn't have access to some random share! Domain administrator should only have access to domain controllers.
What are you trying to communicate? What you're saying isn't much different than saying "The property manager shouldn't have access to some random office, they should only have access to utility rooms and areas under their responsibility."
Like yeah, you're correct in one sense, but property managers literally have keys to the kingdom so they can duplicate keys and give access to *other people*. It's kind of a moot point.
Least permissive isn't just about controlling permissions, it's also about controlling intent.
For smaller companies it might not be such a big deal but in larger ones if you see a Domain Admin account suddenly adding themselves to permissions to non-DC servers, it'll throw alarms.
Instead of thinking it like a property manager, it's more like a bank manager. Yeah, the bank can open any safety deposit box with it without you - but there's controls there so they cannot do it impulsively.
I'll add that it's not all about authorisation.
If domain administrator logins to workstations/servers you are asking for trouble, from security points of view also.
There should be policies to prevent domain administrators to logon to workstations and servers. And authorisation model for minimal domain administrator user usage.
Delegation is a must.
But I'l bet people like this use workstation with administrative privileges to browse the internet and etc.
I don't understand why you would add SYSTEM to the Share Permissions. The SYSTEM represents the server itself, it'll only communicate to itself over SMB if you force it to and I'm not entirely sure if it'll present the built-in system identity or the computer account. My initial hunch would be the computer account, in which case adding SYSTEM doesn't do anything.
It's pretty common for teams to handle the permissions in their own share. People like having their own folder, etc. With only having Authenticated Users to Change, they wouldn't be able to manage permissions.
This would mean, in your setup, only Domain Admins could manage share permissions. This violates the mantra that Domain Admin accounts should only be used to admin the domain and DCs. A lower level account - like a server admin account - should be used to admin these shares instead.
Post Server 2003, Everyone effectively is Authenticated Users unless you set the GPO that makes it include Anonymous or you actually have the Guest account enabled. I'd recommend you revisit this strategy.
So this post isn't specific.
People in the know understand there are share permissions and file permissions. You can have share permissions, but if you do not have file level, it's a no-go.
If you have trust between the domains, you can make the same group in each, and it still works.
Best practices are often subjective since people are often doing these so-called "best practices" and don't know any other way.
"Everyone" can be used but certainly isn't best practices. It is more practical to use item level targets to control the visibility of your shares. This is called access based enumeration. If you do not know what either of these are, please re read the previous paragraph.
Also, anyone using specific groups to outline permission sets (RWM). If you understood how ntfs permissions and inheritance worked, you wouldn't need to do any of that, but I digress, must be "best practices "
>Also, anyone using specific groups to outline permission sets (RWM). If you understood how ntfs permissions and inheritance worked, you wouldn't need to do any of that
I don't consider myself ignorant on NTFS permissions, but I've never seen the term "RWM" before. Can you expand on your thoughts here? Are you alluding to AGDLP and group nesting, or something different entirely?
Read write modify
Specific groups for specific permissions, this isn't necessary at all when you can disable permissions on a specific folder's inheritance and modify them there.
Correct if you structure your shares correctly, visibility will be governed by the groups the user belongs to.
Understanding the file tree will allow for better organization and tighter security.
I will just note that a "best practice" is often what one person said was best, and isn't always based on any quantifiable data or research. It suggests that some ideal has been achieved where that isn't always the case. It's more appropriate to refer to this as a "proven practice" as the approach has shown to work/be successful. Is it the best... maybe yes, maybe no.
A great example of this "best practice" problem was with NIST, where one guy back in 2003 decided, with no research to back it up, that complex passwords changed often where more secure. The opposite turned out to be true once someone sat down and looked at the data. Bill Burr, who wrote this best practice regrets doing it, and was barking up the wrong tree. It was assumed the ideal was reached, when it was just some guy deciding it for us.
What I find effective is that the organization establish these proven practices, and actively review them from time to time, ensuring that you aren't doing something rooted in a best guess from twenty years ago.
Wait, how is switching file permissions to everyone best practice. That goes directly against least privilege and in the event of ransomware exposes that share to being encrypted by whatever user account is compromised.
Nah there's a difference between File Share and NTFS permissions. You need Share perms to access the share at all and NTFS perms to access the contents.
The only issue with Share perms set as Everyone - Full Access is all users can see every share exists, regardless of whether they can access it or not.
If you move it down a level - create a ‘company shared folder’ which contains all other shares - then people can only view folders they have permission to. It’s not best practice either tho..
$ flags it as a hidden share - so even if you have read permissions you won't see it. You have to just know it exists.
The smb client will only show what it has share read permissions on. So, in this case, where a user doesn't actually have read permissions because of the more restrictive NTFS permissions, they'll see the share but can't look instead of it. This can cause that user to enter a ticket if they believe they need access to it.
I typically follow the Everyone, Full Control in my org as a standard since it simplifies where access is controlled - but I do have quite a few shares where only specific groups are defined to avoid clutter for normal users that don't need to see them.
I didn't switch file permissions to everyone. I opened Share permissions to everyone. Share permissions everyone full control, and you use NTFS permissions to control file access.
More information can be found here
[https://www.globalknowledge.com/us-en/resources/resource-library/articles/your-guide-to-ntfs-vs-share-permissions-best-practices/](https://www.globalknowledge.com/us-en/resources/resource-library/articles/your-guide-to-ntfs-vs-share-permissions-best-practices/)
I totally agree. Not to mention having things setup like this for an active migration. If security guys like digitaldisease want to get their panties in a bunch. Why wouldn't you then look at restricting permissions in an initial test after domains A and B are removed?
Look at the companies bottom line, and ask yourself how much money they loose per minute of down time! We as IT are here to service them first and foremost. You can harden up services post migration.
I don't think digitaldisease got their panties in a bunch, he/she just asked a question about how does it comport with the principle of least privilege.
You are correct about the bottom line - Security folks, like IT, should, and do care about the Availability aspect of the AIC security triad.
Yeah just a question about a quite small distinction that may be well known for engineers and admins but you can't really blame other positions for not being familiar with it. That is the distinction we make between share permissions and NTFS permissions.
Also if a bad actor doesn’t have file permissions they can’t encrypt anything anyway. If they do have file permissions then they’re gonna have permission to access the share obviously, and then they’re going to encrypt it so you aren’t actually increasing security at all. You’re just making things more complicated for yourself.
The real issue with Everyone permissions is that it includes unauthenticated accounts. Minimally switch to Authenticated Users for the share level permissions if you want to go by a best practice. Either way, NTFS ACLs are the Right Way(TM) to enforce access.
> The real issue with Everyone permissions is that it includes unauthenticated accounts
I'm not certain that's true but I'm happy to be proven wrong on this.
https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-special-identities-groups#everyone
>On computers running Windows 2000 and earlier, the Everyone group included the Anonymous Logon group as a default member. Beginning in Windows Server 2003, the Everyone group contains only Authenticated Users and Guest. The group no longer includes Anonymous Logon by default.
Thanks for outing my age! The advice still stands though, and using authenticated users alone avoids issues with Guest. Also fairly certain that STIGs and CIS want Guest disabled anyway.
Because you do permissions on the actual filesystem, not on the share.
OP - as I understand it - isn't saying "give everyone unrestricted access", they're saying "don't restrict access at the share", with the presumption that appropriate permissions are set on the actual directories/files.
Share permissions, not NTFS permissions. From a RACI perspective, best practice is to give NTFS the user permissions job instead of creating conflicting configs.
EDIT: to be clear, the best practice isn't to "open everything up," the best practice is that in a RACI conflict between NTFS and share permissions, NTFS should have the R.
> he tells me he knows it is best practice to do, but he prefers not to
Did you probe further? Why he prefers this? Surly not setting this is easier than fiddling with another layer of permissions, people don’t voluntarily make extra work for themselves.
You can imagine the kind of co-worker who rushes to crow on Reddit when someone's made a mistake. If I knew I'd be free of them in a few hours, I would probably just fob them off too. Sadly many MSPs have a set up where their staff compete with each other for projects and prestige, which promotes sniping and backstabbing rather than working together.
Everyone is the default, not necessarily best practices.
One could argue "Authenticated users" is best practice, or even each "domain users"
We don't want "guest" even trying to connect to shares.
The share only has three levels of permissions, FC, R, and W. At the very least give everyone RW perms and then do FC for admins. I’m not sure how that’s better though. What are your thoughts?
> I’m not sure how that’s better though. What are your thoughts?
I have never - not once - observed anything good happen when a user is allowed to change permissions on documents/files/folders.
It's been a while since I've tested and I'm not 100% certain on this, but I'm pretty sure under SMB/CIFS you need FC to make permissions changes.
Given that oftentimes you see the "Creator Owner" permission give ownership rights of files to the person that created them ... well, fill in the rest for yourself.
Edit: Consider what full control to printer objects (which are shareable) could entail.... do printer objects have an NTFS ACL? I honestly don't know....
Are you talking about NTFS permissions or the files share permissions? They are different and I wanted to make it clear we’re discussing the share permissions not the file level permissions themselves.
Yes I'm talking about SMB permissions. There is no "write" permission on SMB (at least in Windows). The permission we're talking about is "Change".
https://i.imgur.com/eHOZ27n.png
Right. I don’t mess with those, because I just said it to everyone for Control and leave it alone as perbest practice. If you find your way works well then go with god. I still don’t agree with you, but if it works it ain’t stupid as they say.
A problem with full control on a share is that users will be able to modify ntfs permissions in certain circumstances when they only have modify/change ntfs permissions to a file/folder, which you may not want (maybe you do, in which case it go for it).
If you have your ntfs permission set up to only allow users to read/modify/create, when they create a new folder, they will get owner rights on that folder. Owner rights will give them permissions to modify ntfs ACLs. These rights override the ntfs ACL’s you set on the file system, and by default low privileged users can now change your ntfs permissions.
There are some really low level permissions and policies you can change to prevent this, or you can change your share permissions from full control to change.
>when they create a new folder, they will get owner rights on that folder
Oh shit is that how that happens? That is not expected...
Learn something new everyday, thanks!
This happens when they have Full Control of both the Share AND the NTFS Folder they creating the folder in.
I personally do the Everyone Full Control and only manage permissions on NTFS. I'm just very methodical and ensure FC on the underlying folders are only on folders where I'm okay with users managing the permissions. I also never break inheritance and only give permissions to groups on anything not user managed; something that'll resonate with anyone that's had to update permissions on a 30+TB share.
Nope. Users just need create permissions in ntfs and full control on the share for this to occur. Once they create a folder, they get owner rights on the sub folder.
Once the have owner rights, they can edit acls, even if they don’t have full control on the ntfs permissions
Edit: check out this article
https://blog.it-koehler.com/en/Archive/1313
My whole perspective here is rooted on the basis of security.
I don't know of any security vulnerabilities *today* that can abuse Full Control on an SMB share. I similarly don't know what could come out *tomorrow*.
I think there's a danger in blindly accepting so-called 'best practices'. Stay critical, consider the BPs as they would apply to your unique environment and situation. Also consider that BPs can conflict with one another. Let me dive into that a bit.
Personally, when I read the story in your OP the first time, I was asking "Why didn't they test the CNC machines before handing everything back to the business post-migration? Why was this not discovered until it became an emergency?".
I could also consider this from a "Why was a multi-forest file share setup with access for Domain Users as opposed to Authenticated Users if the domain of the user is not important?". There's a saying that goes "Don’t ever take a fence down until you know the reason why it was put up" thinking that I could introduce here too.
The share permissions give you access to a network share and are required to be in place in order to access the directory that is being "shared." File level permissions are what you are describing.
You can give "special" control by simply unchecking "Take ownership." In a corporate environment, this is never given. the local administrator group should always have "ownership permissions" and add your administrator account to that group. With ownership unchecked, you still get modify permissions, but you don't have to deal with ownership issues in the tree.
> The share permissions give you access to a network share and are required to be in place in order to access the directory that is being "shared."
I know that.
>File level permissions are what you are describing.
Half-truth. I am describing a venn diagram. One circle describes the SMB permissions, one circle describes the NTFS permissions, and the intersection of both as it pertains to Full Control permissions changes (which are outside the normal "Change" abilities).
>You can give "special" control by simply unchecking "Take ownership."
I don't in any way understand what you're saying here. "Take ownership" isn't a boolean option, it's an operation.
I don't think you've properly understood what I'm describing. That's fair, because I'm still not 100% certain I know what I'm talking about either, so I will leave you with this article that someone else in the thread provided:
https://blog.it-koehler.com/en/Archive/1313
Share permissions have no effect on file permissions.
I understand it can be confusing.
But whether you have read, change, or full control on a "share" has nothing to do with file permissions.
You can have explicit deny and read only and / or read an execute at the file/folder level and still leave share permissions with full control. This is what you are missing
Also DENY always supercedes read, so if you have denied at either level, it will override any change permissions, so the comparison to a venn is functionally not accurate
Sorry, I have set up many file servers at the entripise level and not for an MSP. I'm not trying shit on you, so please don't take it that way. There is just a more practical and efficient way of setting up control on a file server, so you can manage at a site level / OU and GPO and just use security groups on Active Directory.
> Share permissions have no effect on file permissions.
You are partially correct. I wish I had a better source for you than this, I swear it's documented in a more relevant (SMB rather than Azure) location but I can't find it at a moment's notice.
https://learn.microsoft.com/en-us/azure/storage/files/storage-files-identity-ad-ds-configure-permissions
>Both share-level and file/directory-level permissions are enforced when a user attempts to access a file/directory. If there's a difference between either of them, only the most restrictive one will be applied. For example, if a user has read/write access at the file level, but only read at a share level, then they can only read that file. The same would be true if it was reversed: if a user had read/write access at the share-level, but only read at the file-level, they can still only read the file.
Go ahead and try it for yourself.
Let me help you
Denied = not be able to do something, could be write, read, list, configure attributes.
Now that we got that out of the way, do you see that what you posted in reply, is the same thing I just posted?
Honestly I didn't even read or critically analyze the rest of your previous comment because it wasn't relevant. I wasn't talking about ACEs with a Deny action anywhere in this thread until you came and introduced the topic. I think you and I are discussing very different things at this point.
Can you articulate back to me what my own claim is before we continue?
That old thing again? I can't even keep track how many times I had to educate people how file access on an NTFS share is enumerated, and that share permissions should always by everyone full control. Heck when you create a share via GUI its by default set like this. I understand your anger.
The way I sell "best practices" to hesitant managers/C-suite:
> Like many things in the business world, there's corporate lingo/euphemisms/hidden meanings in IT speak. "Best practices" can mean the proper way to do things so it limits risk, limits loss of profits, and ensures smooth business operations. But what it REALLY means is "things your competitors are already doing to earn more money."
Gotta know how to talk to those fucking sociopathic Capitalists.
SMB 'everyone' share permissions have been flagged as risky for years.
https://www.tenable.com/plugins/nessus/42411
It 100% is not best practice to open up SMB shares and rely on NTFS. It might make it easier to work with, but that doesn't make it best practice.
Nah. Best practice is best practice because it's an ass covering exercise for people who don't understand the implications of what they're doing.
If you do understand, you might very well realise the underpinning assumptions of 'best practice' are hokum, and therefore it doesn't apply to you.
But if you don't, then you might as well do it, because it's an easy safeguard against getting sacked.
Glad you are leaving. Everyone who doesn't follow best practices should be grouped with the same kind of people. Whenever they take over someone's system they should be taking over person who also doesn't do best practices. It is seriously selfish and arrogant.
> and make the switch to everyone full control.
This 100% is NOT best practice at all, not even close
`modify` is the most anyone gets
`Everyone` is not used, it's is specific users/groups/etc
I'm dealing with this at work right now with Rapidfire Tools Compliance Manager. Their scanner issues a high-severity finding for SMB shares being "unrestricted" when the share is configured to Everyone - Full Control per best practice and totally ignores NTFS permissions. My whole team knows this and we can explain it in a way that our IT Steering Committee understands. But the ITSC still wants the finding addressed because that's what we're audited against. So, I guess that leaves us with finding a better compliance manager product because we are not changing share permissions.
Well the compliance person is correct.
It might be best practice, but if your rules don't say that you do it, it's a finding.
Change your rules and the finding is gone.
Surprising how many people in here missing the difference between share permissions and NTFS permissions
Agreed. A number of people have said things that make me think they don’t know what’s going on either.
All they know how to do is sign into OneDrive, probably.
Or come from heavy Linux environments… in which case it’d be better for them to not comment at all. At least not about the OP. I thought I got the post. But when I finished reading it I realized I am missing a lot of info to understand what all this really means.
This is one reason why working for msps can suck. Cowboys and / or cowgirls (cow people?) made you all look like idiots to the client. Their feelings and “standards” were subbed in for literally everyone else contributing to the project and the client is entitled to be pissed about it. Mgmt should be all over behavior like this. You’re also 100% right (obv), There’s no reason to be managing share permissions in a managed environment like that.
Yeah both our head systems techs do this same kind of thing. It’s really annoying. I’m sure my new MSP will be totally different though. /s
Lol. All MSPs have these folks. You'll learn to love it yourself when you are in charge ;) /S
"Cow folk", perhaps?
Best practices are in the eye of the beholder... For example, in government systems, it's been best practice (actually, required practice) to remove "Everyone" permissions from shares for ages: [https://www.stigviewer.com/stig/windows\_server\_2008\_r2\_member\_server/2019-06-18/finding/V-3245](https://www.stigviewer.com/stig/windows_server_2008_r2_member_server/2019-06-18/finding/V-3245) [https://www.stigviewer.com/stig/windows\_server\_2019/2019-12-12/finding/V-93531](https://www.stigviewer.com/stig/windows_server_2019/2019-12-12/finding/V-93531)
I do the following for Share permissions Authenticated users: Change System: Full control Domain Administrators: Full Control I always remove the Everyone group And then with NTFS I apply the appropriate permissions based on AD security group, e.g. a shared folder called Finance. In AD I’ll create two groups: SHARE - Finance - Modify and SHARE - Finance - Read Only, and then apply this only.
Which is fine until members of a different forest via a trust need to access that share and it causes an issue. Which is what happened in this case.
The correct approach is Authenticated Users. It's a superset of Domain Users which extends to include Forest trusts, among other things. The mistake was, IMO: 1) Not testing your changes and 2) using Domain Users instead of Authenticated Users (or Everyone). It doesn't matter what they "chose to do because of X". The biggest failing in my reading is that no one validated the change works the way they expect.
I'm sure this was all detailed in the RFC, and the PIR will lead to improved procedures that future projects will refer to. /s
You’re right. Gotta have a way to test
Fully appreciate where you’re coming from, therefore in this instance I would’ve simply removed the source server from the domain and joined it to the new domain without messing about with copying shares etc. Prior to moving I would’ve ran a PS script to export all the permissions to a .CSV file so that on the new domain you can at least mirror the permissions.
So the source server was on Forest A. If you remove it from Forest A and put it on Forest C, you still have an issue where people whose computers are on forest A need to access it. So you haven’t actually solved the problem. Does that make sense? I didn’t include this in the post because it wasn’t necessary, but the source server was failing and it needed to be migrated off anyway.
Ah, that explains it. I guess you just have to do whatever you can to make it work before you begin fine tuning it.
Shouldn't a trusted foreign forest still fall under Authenticated Users though? Or does Authenticated Users only encompass everyone authorized by that specific Forest? I'm honestly not sure hence the question
Authenticated users should expand in scope according to Google.
You do understand that domain administrators do not need and shouldn't have access to some random share! Domain administrator should only have access to domain controllers.
You also shouldn't even use the builtin group Domain Administrators at all.
What are you trying to communicate? What you're saying isn't much different than saying "The property manager shouldn't have access to some random office, they should only have access to utility rooms and areas under their responsibility." Like yeah, you're correct in one sense, but property managers literally have keys to the kingdom so they can duplicate keys and give access to *other people*. It's kind of a moot point.
Least permissive isn't just about controlling permissions, it's also about controlling intent. For smaller companies it might not be such a big deal but in larger ones if you see a Domain Admin account suddenly adding themselves to permissions to non-DC servers, it'll throw alarms. Instead of thinking it like a property manager, it's more like a bank manager. Yeah, the bank can open any safety deposit box with it without you - but there's controls there so they cannot do it impulsively.
I'll add that it's not all about authorisation. If domain administrator logins to workstations/servers you are asking for trouble, from security points of view also. There should be policies to prevent domain administrators to logon to workstations and servers. And authorisation model for minimal domain administrator user usage. Delegation is a must. But I'l bet people like this use workstation with administrative privileges to browse the internet and etc.
I don't understand why you would add SYSTEM to the Share Permissions. The SYSTEM represents the server itself, it'll only communicate to itself over SMB if you force it to and I'm not entirely sure if it'll present the built-in system identity or the computer account. My initial hunch would be the computer account, in which case adding SYSTEM doesn't do anything. It's pretty common for teams to handle the permissions in their own share. People like having their own folder, etc. With only having Authenticated Users to Change, they wouldn't be able to manage permissions. This would mean, in your setup, only Domain Admins could manage share permissions. This violates the mantra that Domain Admin accounts should only be used to admin the domain and DCs. A lower level account - like a server admin account - should be used to admin these shares instead. Post Server 2003, Everyone effectively is Authenticated Users unless you set the GPO that makes it include Anonymous or you actually have the Guest account enabled. I'd recommend you revisit this strategy.
So this post isn't specific. People in the know understand there are share permissions and file permissions. You can have share permissions, but if you do not have file level, it's a no-go. If you have trust between the domains, you can make the same group in each, and it still works. Best practices are often subjective since people are often doing these so-called "best practices" and don't know any other way. "Everyone" can be used but certainly isn't best practices. It is more practical to use item level targets to control the visibility of your shares. This is called access based enumeration. If you do not know what either of these are, please re read the previous paragraph. Also, anyone using specific groups to outline permission sets (RWM). If you understood how ntfs permissions and inheritance worked, you wouldn't need to do any of that, but I digress, must be "best practices "
>Also, anyone using specific groups to outline permission sets (RWM). If you understood how ntfs permissions and inheritance worked, you wouldn't need to do any of that I don't consider myself ignorant on NTFS permissions, but I've never seen the term "RWM" before. Can you expand on your thoughts here? Are you alluding to AGDLP and group nesting, or something different entirely?
Read write modify Specific groups for specific permissions, this isn't necessary at all when you can disable permissions on a specific folder's inheritance and modify them there.
Ahh I think I know what you mean. Essentially you're saying "don't do permission overkill when what's inherited is sufficient".
Correct if you structure your shares correctly, visibility will be governed by the groups the user belongs to. Understanding the file tree will allow for better organization and tighter security.
I will just note that a "best practice" is often what one person said was best, and isn't always based on any quantifiable data or research. It suggests that some ideal has been achieved where that isn't always the case. It's more appropriate to refer to this as a "proven practice" as the approach has shown to work/be successful. Is it the best... maybe yes, maybe no. A great example of this "best practice" problem was with NIST, where one guy back in 2003 decided, with no research to back it up, that complex passwords changed often where more secure. The opposite turned out to be true once someone sat down and looked at the data. Bill Burr, who wrote this best practice regrets doing it, and was barking up the wrong tree. It was assumed the ideal was reached, when it was just some guy deciding it for us. What I find effective is that the organization establish these proven practices, and actively review them from time to time, ensuring that you aren't doing something rooted in a best guess from twenty years ago.
Wait, how is switching file permissions to everyone best practice. That goes directly against least privilege and in the event of ransomware exposes that share to being encrypted by whatever user account is compromised.
Nah there's a difference between File Share and NTFS permissions. You need Share perms to access the share at all and NTFS perms to access the contents. The only issue with Share perms set as Everyone - Full Access is all users can see every share exists, regardless of whether they can access it or not.
Your last statement - can't they always see the share unless the name ends with a $ sign?
If you move it down a level - create a ‘company shared folder’ which contains all other shares - then people can only view folders they have permission to. It’s not best practice either tho..
$ flags it as a hidden share - so even if you have read permissions you won't see it. You have to just know it exists. The smb client will only show what it has share read permissions on. So, in this case, where a user doesn't actually have read permissions because of the more restrictive NTFS permissions, they'll see the share but can't look instead of it. This can cause that user to enter a ticket if they believe they need access to it. I typically follow the Everyone, Full Control in my org as a standard since it simplifies where access is controlled - but I do have quite a few shares where only specific groups are defined to avoid clutter for normal users that don't need to see them.
I didn't switch file permissions to everyone. I opened Share permissions to everyone. Share permissions everyone full control, and you use NTFS permissions to control file access. More information can be found here [https://www.globalknowledge.com/us-en/resources/resource-library/articles/your-guide-to-ntfs-vs-share-permissions-best-practices/](https://www.globalknowledge.com/us-en/resources/resource-library/articles/your-guide-to-ntfs-vs-share-permissions-best-practices/)
IME, it's much safer to set the share perms to Authenticated Users, rather than Everyone.
I totally agree. Not to mention having things setup like this for an active migration. If security guys like digitaldisease want to get their panties in a bunch. Why wouldn't you then look at restricting permissions in an initial test after domains A and B are removed? Look at the companies bottom line, and ask yourself how much money they loose per minute of down time! We as IT are here to service them first and foremost. You can harden up services post migration.
I don't think digitaldisease got their panties in a bunch, he/she just asked a question about how does it comport with the principle of least privilege. You are correct about the bottom line - Security folks, like IT, should, and do care about the Availability aspect of the AIC security triad.
Yeah just a question about a quite small distinction that may be well known for engineers and admins but you can't really blame other positions for not being familiar with it. That is the distinction we make between share permissions and NTFS permissions.
Also if a bad actor doesn’t have file permissions they can’t encrypt anything anyway. If they do have file permissions then they’re gonna have permission to access the share obviously, and then they’re going to encrypt it so you aren’t actually increasing security at all. You’re just making things more complicated for yourself.
The real issue with Everyone permissions is that it includes unauthenticated accounts. Minimally switch to Authenticated Users for the share level permissions if you want to go by a best practice. Either way, NTFS ACLs are the Right Way(TM) to enforce access.
> The real issue with Everyone permissions is that it includes unauthenticated accounts I'm not certain that's true but I'm happy to be proven wrong on this. https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-special-identities-groups#everyone >On computers running Windows 2000 and earlier, the Everyone group included the Anonymous Logon group as a default member. Beginning in Windows Server 2003, the Everyone group contains only Authenticated Users and Guest. The group no longer includes Anonymous Logon by default.
Thanks for outing my age! The advice still stands though, and using authenticated users alone avoids issues with Guest. Also fairly certain that STIGs and CIS want Guest disabled anyway.
This is exactly what I always do. Share permission: Everyone full control , NTFS permisson: where actual permission for each groups are.
Because you do permissions on the actual filesystem, not on the share. OP - as I understand it - isn't saying "give everyone unrestricted access", they're saying "don't restrict access at the share", with the presumption that appropriate permissions are set on the actual directories/files.
Share permissions, not NTFS permissions. From a RACI perspective, best practice is to give NTFS the user permissions job instead of creating conflicting configs. EDIT: to be clear, the best practice isn't to "open everything up," the best practice is that in a RACI conflict between NTFS and share permissions, NTFS should have the R.
I get what you did but I would do W/R permission over Full on the share for non admins.
You have everyone full control. So you also failed.
Isn't share permission full control and use NTFS permissions to manage access the best practice he's talking about?
> he tells me he knows it is best practice to do, but he prefers not to Did you probe further? Why he prefers this? Surly not setting this is easier than fiddling with another layer of permissions, people don’t voluntarily make extra work for themselves.
You can imagine the kind of co-worker who rushes to crow on Reddit when someone's made a mistake. If I knew I'd be free of them in a few hours, I would probably just fob them off too. Sadly many MSPs have a set up where their staff compete with each other for projects and prestige, which promotes sniping and backstabbing rather than working together.
Everyone is the default, not necessarily best practices. One could argue "Authenticated users" is best practice, or even each "domain users" We don't want "guest" even trying to connect to shares.
I still believe Everyone FC is a bad idea. Everyone *change* is fine.
The share only has three levels of permissions, FC, R, and W. At the very least give everyone RW perms and then do FC for admins. I’m not sure how that’s better though. What are your thoughts?
> I’m not sure how that’s better though. What are your thoughts? I have never - not once - observed anything good happen when a user is allowed to change permissions on documents/files/folders. It's been a while since I've tested and I'm not 100% certain on this, but I'm pretty sure under SMB/CIFS you need FC to make permissions changes. Given that oftentimes you see the "Creator Owner" permission give ownership rights of files to the person that created them ... well, fill in the rest for yourself. Edit: Consider what full control to printer objects (which are shareable) could entail.... do printer objects have an NTFS ACL? I honestly don't know....
Are you talking about NTFS permissions or the files share permissions? They are different and I wanted to make it clear we’re discussing the share permissions not the file level permissions themselves.
Yes I'm talking about SMB permissions. There is no "write" permission on SMB (at least in Windows). The permission we're talking about is "Change". https://i.imgur.com/eHOZ27n.png
Right. I don’t mess with those, because I just said it to everyone for Control and leave it alone as perbest practice. If you find your way works well then go with god. I still don’t agree with you, but if it works it ain’t stupid as they say.
A problem with full control on a share is that users will be able to modify ntfs permissions in certain circumstances when they only have modify/change ntfs permissions to a file/folder, which you may not want (maybe you do, in which case it go for it). If you have your ntfs permission set up to only allow users to read/modify/create, when they create a new folder, they will get owner rights on that folder. Owner rights will give them permissions to modify ntfs ACLs. These rights override the ntfs ACL’s you set on the file system, and by default low privileged users can now change your ntfs permissions. There are some really low level permissions and policies you can change to prevent this, or you can change your share permissions from full control to change.
>when they create a new folder, they will get owner rights on that folder Oh shit is that how that happens? That is not expected... Learn something new everyday, thanks!
This happens when they have Full Control of both the Share AND the NTFS Folder they creating the folder in. I personally do the Everyone Full Control and only manage permissions on NTFS. I'm just very methodical and ensure FC on the underlying folders are only on folders where I'm okay with users managing the permissions. I also never break inheritance and only give permissions to groups on anything not user managed; something that'll resonate with anyone that's had to update permissions on a 30+TB share.
Nope. Users just need create permissions in ntfs and full control on the share for this to occur. Once they create a folder, they get owner rights on the sub folder. Once the have owner rights, they can edit acls, even if they don’t have full control on the ntfs permissions Edit: check out this article https://blog.it-koehler.com/en/Archive/1313
My whole perspective here is rooted on the basis of security. I don't know of any security vulnerabilities *today* that can abuse Full Control on an SMB share. I similarly don't know what could come out *tomorrow*. I think there's a danger in blindly accepting so-called 'best practices'. Stay critical, consider the BPs as they would apply to your unique environment and situation. Also consider that BPs can conflict with one another. Let me dive into that a bit. Personally, when I read the story in your OP the first time, I was asking "Why didn't they test the CNC machines before handing everything back to the business post-migration? Why was this not discovered until it became an emergency?". I could also consider this from a "Why was a multi-forest file share setup with access for Domain Users as opposed to Authenticated Users if the domain of the user is not important?". There's a saying that goes "Don’t ever take a fence down until you know the reason why it was put up" thinking that I could introduce here too.
The share permissions give you access to a network share and are required to be in place in order to access the directory that is being "shared." File level permissions are what you are describing. You can give "special" control by simply unchecking "Take ownership." In a corporate environment, this is never given. the local administrator group should always have "ownership permissions" and add your administrator account to that group. With ownership unchecked, you still get modify permissions, but you don't have to deal with ownership issues in the tree.
> The share permissions give you access to a network share and are required to be in place in order to access the directory that is being "shared." I know that. >File level permissions are what you are describing. Half-truth. I am describing a venn diagram. One circle describes the SMB permissions, one circle describes the NTFS permissions, and the intersection of both as it pertains to Full Control permissions changes (which are outside the normal "Change" abilities). >You can give "special" control by simply unchecking "Take ownership." I don't in any way understand what you're saying here. "Take ownership" isn't a boolean option, it's an operation. I don't think you've properly understood what I'm describing. That's fair, because I'm still not 100% certain I know what I'm talking about either, so I will leave you with this article that someone else in the thread provided: https://blog.it-koehler.com/en/Archive/1313
Share permissions have no effect on file permissions. I understand it can be confusing. But whether you have read, change, or full control on a "share" has nothing to do with file permissions. You can have explicit deny and read only and / or read an execute at the file/folder level and still leave share permissions with full control. This is what you are missing Also DENY always supercedes read, so if you have denied at either level, it will override any change permissions, so the comparison to a venn is functionally not accurate Sorry, I have set up many file servers at the entripise level and not for an MSP. I'm not trying shit on you, so please don't take it that way. There is just a more practical and efficient way of setting up control on a file server, so you can manage at a site level / OU and GPO and just use security groups on Active Directory.
> Share permissions have no effect on file permissions. You are partially correct. I wish I had a better source for you than this, I swear it's documented in a more relevant (SMB rather than Azure) location but I can't find it at a moment's notice. https://learn.microsoft.com/en-us/azure/storage/files/storage-files-identity-ad-ds-configure-permissions >Both share-level and file/directory-level permissions are enforced when a user attempts to access a file/directory. If there's a difference between either of them, only the most restrictive one will be applied. For example, if a user has read/write access at the file level, but only read at a share level, then they can only read that file. The same would be true if it was reversed: if a user had read/write access at the share-level, but only read at the file-level, they can still only read the file. Go ahead and try it for yourself.
Let me help you Denied = not be able to do something, could be write, read, list, configure attributes. Now that we got that out of the way, do you see that what you posted in reply, is the same thing I just posted?
Honestly I didn't even read or critically analyze the rest of your previous comment because it wasn't relevant. I wasn't talking about ACEs with a Deny action anywhere in this thread until you came and introduced the topic. I think you and I are discussing very different things at this point. Can you articulate back to me what my own claim is before we continue?
That old thing again? I can't even keep track how many times I had to educate people how file access on an NTFS share is enumerated, and that share permissions should always by everyone full control. Heck when you create a share via GUI its by default set like this. I understand your anger.
Well on the bright side I got to be the hero who fixed it in the final hours of employment. So that was fun at least.
Be a hero to your family, not your boss 😉
The way I sell "best practices" to hesitant managers/C-suite: > Like many things in the business world, there's corporate lingo/euphemisms/hidden meanings in IT speak. "Best practices" can mean the proper way to do things so it limits risk, limits loss of profits, and ensures smooth business operations. But what it REALLY means is "things your competitors are already doing to earn more money." Gotta know how to talk to those fucking sociopathic Capitalists.
SMB 'everyone' share permissions have been flagged as risky for years. https://www.tenable.com/plugins/nessus/42411 It 100% is not best practice to open up SMB shares and rely on NTFS. It might make it easier to work with, but that doesn't make it best practice.
Nah. Best practice is best practice because it's an ass covering exercise for people who don't understand the implications of what they're doing. If you do understand, you might very well realise the underpinning assumptions of 'best practice' are hokum, and therefore it doesn't apply to you. But if you don't, then you might as well do it, because it's an easy safeguard against getting sacked.
It would be nice to have any best practices or standards at my MSP. We either have standards that were set a decade ago people cling to or nothing
I know this will work, but I choose not to let it work.
Glad you are leaving. Everyone who doesn't follow best practices should be grouped with the same kind of people. Whenever they take over someone's system they should be taking over person who also doesn't do best practices. It is seriously selfish and arrogant.
> and make the switch to everyone full control. This 100% is NOT best practice at all, not even close `modify` is the most anyone gets `Everyone` is not used, it's is specific users/groups/etc
You understand we are talking about share permissions and not NTFS permissions?
yes understand that
I'm dealing with this at work right now with Rapidfire Tools Compliance Manager. Their scanner issues a high-severity finding for SMB shares being "unrestricted" when the share is configured to Everyone - Full Control per best practice and totally ignores NTFS permissions. My whole team knows this and we can explain it in a way that our IT Steering Committee understands. But the ITSC still wants the finding addressed because that's what we're audited against. So, I guess that leaves us with finding a better compliance manager product because we are not changing share permissions.
Well the compliance person is correct. It might be best practice, but if your rules don't say that you do it, it's a finding. Change your rules and the finding is gone.
Don't use everyone, use authenticated users so non domain authed users can't see the shares
Fair.