“Change how you think; Change your life.”
If you think you know how to administer a file server, maintain permissions and groups, but want to know a better way; a more efficient way, then you have to change how you think about permissions and security. Watch these videos (2.5 hours) and it will change the way you look at security and Active Directory. These videos will give you a strong Role Based Access Control (RBAC) foundation to build your security permissions on, and best practices for Active Directory.
These videos are by fellow Microsoft MVP – Dan Holme years ago on Role Based Access Control and Active Directory Best Practices. Even though they are over 7 years old, they still have the knowledge and foundation concepts for a scalable structure today.
Active Directory Best Practices – Ten Years Later
Techdays 2011 – Role-Based Management Extreme Makeover
If you want to an extra 1.5 hours with similar content:
Administrators’ Idol: Windows and Active Directory Best Practices
Role Based Access Control – Is it for Me or My Company?
From the small 1 person company to the large Fortune 500 companies – this solution just plain works. You will create a whole lot of groups, for nesting, but the other side is that with the scripts that he provides, you just need to run his script and you can see who has what access to what folders, and what type of access they have. (Eg. who has access to this folder? what does this user have access to? Run the script, it will tell you.)
It will change the way you assign permissions to everything – and it will make your life easy. It will take a bit of grunt work to switch over to RBAC but if you do it right, it’s a 1 time change. On each file share’s NTFS Permissions tab, you will only have 1 security group with Read, 1 with modify, 1 with list folder contents, and 1 with Full and 1 SYSTEM. Nothing else. Share permissions will ALWAYS be Everyone > Full Control (unless there is a specific need that the share must stay read only). Grant access based on groups, not individuals, and not groups that individuals are a part of (eg Sales Department). Create a nested group Access Control List (ACL) Structure. This way, you can find out EVERYTHING by using included scripts.
Microsoft has been pushing this method since as long as I can remember (Remember the AG(U)DLP method?). Microsoft gave you the tools and method, but many people still can’t wrap their heads around this concept. The concept is:
- Accounts are put into Global Groups
- Global Groups are put into Universal Groups (Optional if you’re only a single forest domain – instead they would directly be inserted into the Domain Local Groups)
- Universal Groups are put into Domain Local Groups
- And Domain Local Groups are assigned the appropriate permissions.
Do not confuse “Domain Local Groups” with computer local groups. No where do we use computer local groups in this method.
The problem in teaching this method, is that conceptualizing the expansion of this knowledge to your own environment is subjective and leaves a whole lot of information open to interpretation and implementation. This is where many go wrong. I hope to help by giving an example below to help start you out on your journey of RBAC.
What about domain Admins? They can access all files by default.
If you wanted to take it a step further for having a File Admins group (not just Domain Admins), set up a “File Admins” group, use it instead of Domain Admins on all root folder NTFS Permissions for where the rest of your files are located (eg. D:\CompanyFiles). Set up this “File Admins” group as a member of every ACL that has Full Control. Don’t make Domain Admins a member of that group, but control the individuals as members of that File Admins group. Then you can give Domain Admin to any other Admin user (if needed), and then they will not have access to the files and folders of your company’s files. Of course they can take ownership of the folder structure as they are a Local Administrator of the file server (by rights of Domain Admin), but that will eradicate all security on the object and they will be caught in the act.
Hey, that’s great! Anything else I should know before I start?
I also recommend that you couple RBAC with Access Based Enumeration (ABE). This way users can only see files and folders that they have access to. If they don’t have access, they can’t see it. It makes it much more secure, and an easier experience for the user. This is a very simple option that you can turn on that makes a world of difference. You can turn this on with both Windows and Linux file servers including many NAS devices. Check your favourite search engine out for how to enable ABE with the system you’re using.
On top of everything mentioned above, make your life easier by enabling Distributed File System (DFS) with replication (DFSR) if you have multiple servers for files. Using DFS(R) coupled with RBAC, you have a secure, easy to manage, least privilege, best practice file system in effect at your company. The beauty of DFS is that if you change servers in the future (buy a new server, etc) or you need some extra space that is not utilized on a different server, you can adjust DFS to suit your needs, or introduce DFSR and sync across the data automatically, keeping High Availability (HA) and/or faster access at multiple locations, or even replication of data to replacement server. Don’t forget, DFS(R) is a service and needs to be duplicated for HA, just like Domain Controllers (DCs), which is why I suggest using the DCs as your DFS Namespace Servers as they usually are already distributed properly for HA (separate hardware, separate UPSs, etc) and AD already uses DFSR (Server 2012) to replicate SysVol and other AD folders. There are downsides to using DFSR with respect to opening the same file in both locations due to the way lock files work. Please investigate DFS(R) before you start so that you can accurately gauge if it’s the right method for you right now. If you have a single server housing your file system, you SHOULD use DFS because it will make the replacement simple.
OK Great! How do I start switching to RBAC?
The best advice is to do it step by step. Start by mapping out your entire folder structure’s permissions set using AccessEnum (http://live.sysinternals.com/AccessEnum.exe). This will not only give you a backup of the security settings, but also a map as to how to create your security groups.
Start with your job titles – create groups for them. Add the appropriate people into the job titles as members. Then go to the other end of the scale – file structure – create your groups with regards to your department security. Example: Sales will need 4 groups minimum.
ACL_Sales_Read
ACL_Sales_Modify
ACL_Sales_ListFolderContents
ACL_Sales_Full
Add these groups to the Sales folder’s discretionary access control list (DACL) in the Security tab of Properties. Don’t forget when adding ACL_Sales_ListFolderContents, go into advanced permissions, and set this for “This folder only”. This step is very important or people who end up getting this permission set will be able to view all the names of the folders and files and any subfolders and files. They will not be able to open the files as they don’t have the permission, but they’ll be able to view the names.
Add the sales oriented job title groups you just created as “member of” the ACL_Sales_Modify group.
LEAVE IT FOR A FEW DAYS. – you haven’t taken away anyone’s access, you’ve only added groups, and you need to make sure that all users have at least logged in 1 time again so that the ticket granting ticket (TGT) from Kerberos has been updated to include the group memberships you added them to. After a few days (a week is good – it gives those who are remote users who don’t connect to the network often enough time to get the updates. If all are internal, next day is fine) remove direct members permissions on the Sales folder.
What about specific sub-folder access for people?
Create another set of groups for the subfolders inside
ACL_Sales.2018 Sales Folder_Modify
Make this group a “Member Of” ACL_Sales_ListFolderContents, and add the member’s ROLES to this group. Add the group to the folder security for “2018 Sales Folder”. Wait a week, and then remove the direct memberships. At this point you can remove or include inheritance from the folder structure above depending on the nature of the folder.
You then rinse and repeat to finish this for all of your file shares.
You may have some roles that contain multiple ACL groups that replicate across roles – eg, if you have a committee like Health & Safety. Then create a new role for that, add all the ACL memberships in the member of tab, and for the members, add the individual users as you’re creating a new role. Wait for the TGT to be recreated at next login for each user (wait a few days) and then remove the direct ACL groups from their employee role. Now the user Sally has a role of Sales Representative, and also Health & Safety Committee Representative.
Can I do this for more than just file shares?
This is a concept. It can be applied to anything. Printers, SSRS Reporting Server, intranet site permissions, GPO permissions (Scoping), Permissions for 3rd party contractors, … the list is endless.
- Printers = ACL_Printer1_Print, ACL_Printer1_Manage, ACL_Printer1_Full, etc.
- SSRS Reporting Server = ACL_SSRS_Publisher, ACL_SSRS_System Administrator, ACL_SSRS_My Reports, ACL_SSRS_Browser, ACL_SSRS-Sales_Browser, ACL_SSRS-System Reports_Browser, etc
- Intranet Site Permissions = ACL_Intranet.Corporate_Browse, ACL_Intranet.Sales_Browse, etc
- GPO Permissions = ACL_GPO.WSUS – Workstations & Test_Apply, ACL_GPO.WSUS – Workstations & Test_Deny, etc
- Permissions for 3rd party contractors = ACL_ERP.Server Administrators, ACL_ERP.SQL Server Administrator, ACL_ERP.RDS Server Administrator, ACL_CRM_Server Administrators, ACL_CRM_Application Server Administrator, etc.
