Mike Winslow, Senior IAM Consultant, SecureITsource, Inc.
One of the hardest types of accounts to gain control of is the privileged administrator account. Every Windows system comes with an Administrator account built-in, every *Nix system has root. These accounts, if improperly used, can totally destroy a system, wipe out sensitive data, or worse. On the other hand, many maintenance tasks require the administrator or root account in order to run. These accounts can be disabled but can’t be deleted. Another problem with these accounts is that they can only be used by one person at a time. A common resolution for this problem is to create additional admin level accounts. This can be accomplished by either putting the desired admin user’s personal network account into the local administrators account directly or by putting it in a nested domain group that has admin access. Another way is to just create an admin level account, either domain or local, that grants the user the admin level access that they need.
The problem with these methods is that they can create potential security issues. One issue is trying to control all of these admin level accounts. If everyone that needs an admin account on a server is given their own account, the number of admin accounts available to be exploited grows exponentially. And as we all know, the more accounts you create, the more potentially weak passwords that are introduced into the environment. If a secondary account is created for a user, they tend to get forgotten when that user leaves the company or moves to a different job, leaving unused, unmanaged, admin accounts dangling like a carrot begging to be exploited. The more of these types of admin accounts you have, the easier it is for the black hats to find and exploit a vulnerable admin account inside your network.
So how do you provide the admin access to your environment that you require while at the same time reduce the number of admin accounts created and keep them secure from unauthorized use?
One solution that many enterprises are turning to is the CyberArk Privileged Access Security system with its enterprise encrypted password vault and password management system. Storing admin accounts within the PAS solution helps solve the problem of weak passwords and forgotten accounts. What it doesn’t answer is the number of accounts that are required to be created and somehow tracked. So how can you provide the admin level access required by your users while at the same time controlling the creation and spread of administrator level accounts? Again, the answer to this question is CyberArk.
In the following sections, I will describe how we solved the problem of out of control admin accounts with one of our clients. This client had two separate domains that required admin level access. Admin access was given to not only the system administrators but the DBAs on their database servers, Application admins on the servers running their applications, the security team, various levels of IT support, the data backup team, the team running monthly patches, etc. You get the idea. Admin access was spread heavily across both domains with some having access via their domain account and others having a specific account with admin access.
Our solution involved determining what teams required admin level access and on which servers they needed said access. Once we knew how many people were on a team, we created domain level accounts and granted those accounts the admin level access to the systems the team managed. Then we put these accounts in CyberArk where they could be properly managed. Next all of their access via their domain account or secondary account was removed. Accounts were deleted is secondary accounts or removed from nested Admin level AD security groups. Now in order to logon as an admin to the system they have to logon to CyberArk and use one of the team’s admin accounts and establish a session via the PSM session manager which not only controls access but records everything they do. But in order for this to work there are a lot of additional pieces and configuration involved in implementing this solution. These steps are described in detail below.
The first step was to determine team membership. Once we knew who was on the team we created a group in active directory and added all of the team members to it. We called this AD Group #2. Next we created a safe in CyberArk and provided the group with the Use and List permissions for the accounts that would be stored inside the safe.
For our naming convention we used the following for the safe: <Type>-<Environ>-<Team>-<Increment>. For example, APP-PRD-ITS-01 which means this safe is for Production systems managed by the ITS team and it is an application server of some kind. The 01 is just a way to increment the safes if needed in the future. Next for the AD level group #2 we named it as follows: EPV-<Safe Name>-MGR or EPV-<Safe Name>-USR.So using the safe created above, this group name would be EPV-APP-PRD-ITS-01-MGR or EPV-APP-PRD-ITS-01-USR. The MGR group provides additional permissions such as changing passwords or managing the safe. USR gets the basic Use and List permission.
The next step is to create the shared domain level accounts that the team will actually be logging on to CyberArk and using for access. The naming convention for these accounts were as follows: EPV-<Team>-<Acct Type>-<101-199>, EPV-<Team>-<Acct Type>-<901-999>. So an example would be EPV-ITS-WNDD-101 or EPV-ITS-WNDD-901. The 100 level accounts are for production and the 900 level are for the dev or test environment. This was done because they didn’t have a separate CyberArk environment for the dev/test systems. The WNDD means that these are Windows Domain accounts. EPV means Enterprise Password Vault. The number of shared accounts created depends on the number of team members that will be using these accounts. For example if the team has 20 members then you would create 5 to 6 accounts or 25 to 30 percent of the team total membership. In some cases we would create shared accounts on a one for one ratio if it was determined that all of the team members would be regularly needing access or involved in “all hands” type scenarios. The number of accounts created is really a function of the needed use of the team. These accounts would be setup for exclusive and one time use. The account platform was configured to automatically release the account after 8 hours if the users didn’t do it themselves. In order to overcome the password policy of not being able to change more than once within a 24 hour period, a reconcile account was also assigned at the platform level.
So now we have a safe with a number of shared accounts that all the members of the team can access. How do these accounts gain admin privilege on the servers? In order for this to work, we need to create two more groups in Active Directory. We called them AD group #3 and #4.
All of the shared privileged accounts created in the step above are nested as members of AD Group 3. AD group 3 naming convention is as follows: EPV-<Safe Name>-Target100, EPV-<Safe Name>-Target900. Again, Target100 for production access and Target900 for dev/test access. So using our example above, we would have EPV- APP-PRD-ITS-01–Target100 or EPV- APP-PRD-ITS-01–Target900
Next AD Group #3 is nested inside of AD Group #4. AD Group #4 naming convention is: EPV-<Host Name>-Administrators. So EPV-MYSERVER1-Administrators. This is an account created in Active Directory specifically to grant access to specific hosts/servers. Since there may be more than one team that needs access to a specific server, AD Group #4 is used to nest all of the AD Group #3 groups that need access. This AD Group #4 is then added to all of the local administrators groups for each server that requires admin access.
Finally we created a specific platform to use for all of these generic, shared, privileged accounts so that we could enforce check-in/check-out exclusive access, enforce one-time password access, and require privileged session monitoring and isolation with recording and saving of session activity.
So to recap the entire process.
1. Create an Active Directory group (AD Group #2) that contains the Domain userID’s of all the team members.
2. Create a safe and grant the AD group above the appropriate permissions. (We started with just giving everyone use and list permissions to the safe)
3. Create the shared, generic, privileged accounts that the team will use to logon to the servers.
4. Create an Active Directory group (AD Group #3) and add all of the shared privileged accounts.
5. Create an Active Directory group specific to each host/server (AD Group #4) and add all the AD Group #3’s that need access.
6. Add AD Group #4 to the local administrators group on each server that the group will access.
7. Created a specific platform with Exclusive access, one-time password access, privileged session monitoring and isolation and recording and saving of session activity.
The diagram below demonstrates the nesting of each AD group to allow access.
Once this solution is implemented, the enterprise no longer has to worry about forgotten accounts of terminated employees, weak passwords, out of control use of individual admin access, or unauthorized access and use of admin level accounts.
With this solution, the number of admin accounts are limited and easily managed and controlled. Passwords are constantly rotated, encrypted, and strong enough to be impossible to crack, beside the fact that they sit securely behind the 7 levels of security provided by the CyberArk Enterprise Vault solution.
Employees are easily added to and removed from one group without the need of tracking them through multiple accounts and numerous systems. And unlike in the past when they could use their own ID to logon and do things on the server without record, everything they do now is recorded and easily audited. If a team grows, it is easy to add additional generic shared accounts.
As we implemented this solution there was a learning curve that we had to deal with as users went from being able to use their own account to needing to logon to CyberArk and check out an account from their safe. Training sessions and documentation was required and some users had a more difficult time than others. But as they adapted to and learned how to use these accounts, they have found it much easier to connect to multiple servers and do their work. And the enterprise will have eliminated thousands of personal admin level accounts, thus adding an additional layer of security to their infrastructure.