This came up for a client recently, so we decided it was worth covering here on the blog. Also, it was supposed to be our first Tech Tuesday content but we had to get to a client early to ensure they passed a network security audit that was tied to a substantial amount of new business. Client – especially money-related projects – take precedent.
Standards = Time & Fewer Mistakes
The above is true whether coding (variables, function names, etc.), how you roll out network shares and changes, and, in this case, how you work with network security groups.
In our case, we are working with Windows Server and Active Directory. But we applied the same sort of strategy WAAAAAYYYYY back in the Netware days and with most subsequent deployments. In fact, when we don’t – for very small, simple networks, it’s proven to be a mistake.
Fortunately, we’ve been able to use scripts and other automation tools to help such implementations.
Security Group Naming
The first thing is to use logical prefixes. In its most simple form, we prefix groups with a “grp” prefix. grp = Group. Simple, right?
Accounting = grpAccounting
Finance = grpFinance
Sales = grpSales
This makes finding those groups easy. They are listed all together, rather than alphabetically with built-in and other objects between them.
For project groups – collecting groups and individuals across departments, we’ve used a prefix of “prj“. Now this leaves your above groups and your project groups separated. However, that isn’t the end of the world.
Recently, we used a modification to this. Using a lower case “g” for a group and then “dpt” for a departmental group and “prj” for a project-based group.
Accounting = gdptAccounting
Sales = gdptSales
CRM Project = gprjCRM
Dealing with Individuals
One place where security can be a hassle is with individuals. It is a bad strategy to apply specific security to an individual account. Do this enough times across a moderately complex network, and finding where those permissions have been applied (folders, files, etc.) in the case of personnel changes, is a problem.
Create Role Groups for Individuals
In this case, create a security group for a single person. Prefix it with “rl” or “grl” depending upon how you want your custom security groups to list alphabetically.
Chief Financial Officer = rlCFO
Controller = rlController
VP of Sales = rlVPSales
Note: I opt for rlVPSales rather than rlSalesVP to keep all company VP’s together.
Personnel Change Benefit
Here is why this is valuable:
Your CFO could leave. You could change the account and let the new CFO assume that account. But this is a problem for auditing reasons. Furthermore, a search for a replacement could take some time. If you use a role group, you can add one or more other executives to that group until a suitable replacement is found.
It might be that, for some time, you have various people inserted into the role as needed. Using a security group rather than a specific account, allows you to address this quickly and without disruption or trying to determine where individual security had been applied.
Furthermore, if you use any scripts or policies that are role specific, they should work for the new individuals in the role immediately.
This actually dovetails nicely with front-loading work, a concept we discuss a LOT. It takes a little more time on the front-end but pays remarkable dividends for future management, changes, and growth.
We apply a similar logic to naming servers, organizing server drives, naming shares, and other facets across a network. In fact, in my previous blog entries on Concept Over Process, I published the section about the Role of Technology. In that section I say, Information Should Inform. When you apply standards, like the above, the name of the object tells you something about it.
Let me know if you find this helpful.