One of the major time consuming tasks that administrators have to deal with is setting permissions on folders and files.
It is not the act of setting permissions but the design of security groups and permission levels that the organization requires.
Take the following folder structure:
At this level how many groups would be needed? I estimate 5 new groups + the default Authenticated Users group = 6 Groups. Pretty straight forward stuff and not too complicated.
Let’s take it down another level, Under Accounting there are 3 departments (Accounts Payable, Accounts Receivable and Auditing). This means we need 3 more groups bringing our total to 9 groups.
Under Accounts Payable, our mythical company, has a few departments of its own (Collections, Receiving Clerks, and Managers) which means we have 3 more groups to our collection and now we are up to 12 security groups for our org.
We could continue through all the folders and probably end up with somewhere between 50 and 100 groups just for security of the data folder. All bets are off if users have cross department responsibilities. This is the way security on Windows servers have been done since Windows NT4 days, and while this is still an acceptable solution there are a few gotchas that will come into play as organizations get more and more data and the number of groups start to grow.
Gotcha #1 is Manageability – When a new person in accounting is on-boarded how does the IT person know which groups that user becomes a member of, or when a user changes from accounts receivable to accounts payable now what groups does that user belong to.
Gotcha #2 is changing permissions on file shares can be time consuming, if accounting had a terabyte of data consisting of millions of little files, a small tweak at the root could take hours, days or weeks.
Once started if the process is canceled – could lead to ACL mismatch and be very hard to troubleshoot access permissions.
Gotcha #3 are the group documented for what the groups are used for i.e. a new SharePoint administrator decides to add the Accounting Group to a SharePoint site he created for the Accounting group – now any changes made to the group affects both SharePoint and file server. Repeat this process a hundred times and you begin to see how this becomes a very inefficient way to manage permissions.
Are groups going away? The simple answer is an emphatic NO! Groups will be around for a long time to come, but with 2012+ we now have a better way to secure files with Dynamic Access Control.
In this example we will go through the requirements and a simple setup to demonstrate:
So what is Dynamic Access Control (DAC)? DAC is really a claims based authentication based on attributes about a user. These claims are populated by Active Directory and are stored in the Kerberos TGT. In The Kerberos TGT there is a data field called Privilege Account Certificate – In this same data field is where SIDS, user profile information and password credentials are stored.
Won’t that cause Token Bloat in large environments? No Microsoft increased the size of MaxTokenSize from 12KB to 48KB in Windows 2012
What are the requirements?
1) For Central Access Policies based on groups – upgrade your file server to Windows 2012+
2) Issue claims to users and central access policies based on claims – upgrade your file servers and domain controllers to 2012+
3) Issue device claims – Upgrade your clients to Windows 8+, upgrade your file servers and domain controllers to 2012+
Simple Walkthrough for Dynamic Access Controls
Step 1. In the Default Domain Controllers group policy enable support for claims.
This tells the domain controllers to issue the claims to users
Step 2. Open Active Directory Administrative Center (ADAC) and browse to Dynamic Access Control, then select Claim Types
Step 3. Create a new Claim Type; under Claim types click New
In this example I selected the surname attribute which I gave a friendly display name of Last Name.
When done click ok – Now Last Name is not a terribly useful claim so let’s add a few more( Department) will be the one I use for the rest of this demonstration. Department is a pretty easy one but should get the wheels turning.
Step 4. On your 2012 File Server make sure the following 2 roles are installed (File Server And File Server Resource Manager)
Step 5. Create the Folder and Share
Setup the permissions on the file server under Advanced Security Settings and click Add
Note: The Authenticated Users have modify rights to the share, but below we added a condition where the user will have modify rights if the Department claim equals CIO
Step 6. Validate attribute in AD
Step 7. Test Access to share
Step 8. Test Access for users without the attribute set in Active Directory
In this step I am actually accessing with a domain administrator to see how the permissions react
Step 9. Go Forth and Prosper
A few scenarios where you could test claims on your own:
1) Global company, with stringent requirements that US data only be accessed by the correct department of US employees
2) Company needs to allow IT access to everything, but otherwise Accounting can access Sales Data unless the sales data is from Kansas where the R&D Sales team is
As you can see the complexity of security can get quite complex, almost as complex as your company
So now that you have seen how easy and fast claims was to setup its time to go forth and make this happen. I believe this is the future of file share permissions especially as more and more products move to the cloud.