This month CyberSheath co-sponsored a table with CyberArk at the annual California Tech Summit, at the convention center in Anaheim. We had a lot of great discussions with conference participants and conference presenters. Often times at events, like the Tech Summit, as a vendor you are asked many questions throughout the day regarding the service or product you are representing. One frequently asked question that came up was “what exactly is a privileged account?” In order to address that question, we should first discuss the various types of user and service accounts that exist in a typical enterprise.
There are three main types of accounts that exist: local accounts, directory accounts, and application accounts. We will take a look at them to discuss under which circumstances those accounts are typically considered “privileged,” although keep in mind that some organizations can have broader definitions of what it means for an account to be privileged.
The 3 Main Types of Privileged Accounts
1: Local Accounts
Local accounts are defined on specific systems, and can only be used to log into that system such as the Administrator account on a desktop PC. With local accounts, we can have identically named accounts on different systems, and they typically have their own individually managed password. For the most part, accounts that are members of the “Administrator’s” group on Windows-based systems are considered privileged. In Unix/Linux, accounts that have root-level access are considered privileged. On network appliances, devices that have write-capabilities are typically considered privileged. It’s possible to use local accounts for file access, so any account that has access to highly-sensitive data should also be considered privileged. A privileged access management tool can be used to keep track of who has access to those accounts and to rotate the passwords automatically. A good tool can reduce the risk of local accounts by setting each one of them up to have a different password.
2: Directory Accounts
Directory accounts, also known as Domain accounts are defined in a central location. For example, we can have a user called John.Smith defined within the Microsoft Active Directory. The accounts defined in directories have to have unique names and passwords. In order to login or use a particular system, the directory account has to be either defined individually or be a part of a group, that’s authorized on the system. The built-in Active Directory accounts, such as Administrator, should be considered privileged, as well as any accounts that are added to the Domain Admins group. Where it gets a little trickier is with standard “named” user accounts. Standard “named” accounts are typically used by end-users to log into their desktop PC’s and conduct routine functions such as checking their email and are not considered “privileged,” unless they’re added to the local “Administrator’s” group on a server or a desktop.
It can be difficult to detect and keep track of when a particular “named” user account is added to the “Administrator’s” group to one of the hundreds/thousands of computers in an enterprise, and tools like CyberArk’s DNA need to be utilized to discover these instances. Many enterprises create a secondary “named” account for users that need to have administrative access, for example, “John_Smith!,” where the exclamation point indicates that the account is privileged. After CyberArk’s DNA discovery process is complete, the privileged accounts should be defined, monitored, and controlled through a central PAM suite.
In some cases, directory accounts can be created to run a certain service or application, for example, a “bind” directory account for an application that needs to look up and/or change properties in the domain. The directory service accounts should be considered privileged, especially because their passwords are static, and often they are a member of the local “Administrator’s” group on the server where they operate. A privileged access management tool, such as CyberArk, can be used to rotate passwords, and “push” the application password to the service that needs to run it.
3: Application Accounts
Application accounts tend to be local and directory accounts, and are typically used for authorization into a specific application. For example, a Microsoft SQL database might have a user called SA. Sometimes application’s utilize local or domain accounts in order to run, the key differentiator from other accounts types is that the applications do not require an interactive login in order to work. The passwords for application accounts are often stored within the application, or in an external configuration file. Where an application account is considered privileged is highly dependent on the permissions and file-access that the account will have within the application. A mature PAM solution can help rotate the passwords of the Application accounts, and even provide the password directly to the application from the central vault, preventing the need to store it in a clear-text configuration file.
In next week’s blog, we will discuss a “shared” privileged account access model that is possible with a central PAM solution. In that model, enterprises control account access through a PAM solution, and instead of adding “named” domain accounts to servers, users are given access to the “shared” privileged accounts. Learn about our approach to within our Privileged Access Management service area.