The concept of functional accounts is used within privileged access management (PAM) and identity access management (IAM), referring to accounts used to perform automated account management functions regardless of being local, centralized, within an operating system, application, on-premise, or in the cloud. Simply put, functional accounts help to manage other accounts. Functional accounts have elevated privileges and, in many implementations, domain administrator or root privileges across multiple resources. Management functions can include, but are certainly not limited to, account creations and deletion, password rotation, account enablement or disablement, and group membership placement or revocation.
A good functional account architecture limits the reach of each instantiation and prefers multiple functional accounts governing zones, resources, assets, and applications versus a few that have nearly god-like, or domain privileges, across the entire environment. These accounts typically also fall outside of any just in time management for identity and privileged access management solutions since they must be considered “always-on” in order to perform their automated functions. The latter makes it easy to understand that, if a functional account is compromised, repercussions are quite pronounced, and every account under the functional account’s control (managed account) is in jeopardy too.
As an example, consider a deployment of Windows resources within your environment. They could be servers or laptops. In this scenario, a functional account would manage all of the privileged and service accounts assigned to the resource and linked to other systems that must share the same credentials. They can be rotated and checked in and out on-demand, or based on a workflow. All management for these accounts, whether they are local or domain-joined, is accomplished via the functional account. The goal is to ensure the credentials are always unique, never become stale or dormant, and are changed frequently enough to mitigate risks of the privileged credentials being stolen or misused.
If you consider the power and purpose of functional accounts, there are several things that administrators and end users should always heed:
- Functional accounts should never be associated with any identity. They operate independently.
- They are strictly used for automation from an IAM and PAM solution. They should not be used by other applications.
- They should never be used for any daily work. Ever!
- They should be managed like any other highly privileged account and passwords or certificates combination and be rotated periodically to prevent them from becoming stale. This must be done with great care to ensure dependent management functions do not break due to a missed password change or error.
- Functional accounts should be excluded from any just in time IAM or PAM initiatives.
- Whenever possible, they should be local accounts and not domain accounts. However, certain applications and implementations will necessitate exceptions. Follow this simple rule: if it can be managed or implemented without using a domain account, that is probably a lower risk method.
- They should be delegated the least amount of privilege necessary to perform their automated functions. For example, rather than making an account domain admin be able to control active directory accounts, delegate only the right to rotate passwords or change group membership of other accounts.
Functional accounts are a necessary concept to place privileged accounts under management. While they have elevated privileges to perform their functions, they must be treated as a high security risk and deserve protection that even exceeds that of domain administrator credentials. IAM and PAM solutions can manage these expectations for an environment, but some basic do’s and don’ts should always be honored.
For more information on how BeyondTrust can help you manage credentials within your environment, minimize the risk of functional accounts, and even enable just in time privileged access management, please contact us here.
Morey J. Haber, Chief Technology Officer and Chief Information Security Officer at BeyondTrust
Morey J. Haber is Chief Technology Officer and Chief Information Security Officer at BeyondTrust. He has more than 25 years of IT industry experience and has authored four Apress books: Privileged Attack Vectors (2 Editions), Asset Attack Vectors, and Identity Attack Vectors. In 2018, Bomgar acquired BeyondTrust and retained the BeyondTrust name. He originally joined BeyondTrust in 2012 as a part of the eEye Digital Security acquisition. Morey currently oversees BeyondTrust strategy for privileged access management and remote access solutions. In 2004, he joined eEye as Director of Security Engineering and was responsible for strategic business discussions and vulnerability management architectures in Fortune 500 clients. Prior to eEye, he was Development Manager for Computer Associates, Inc. (CA), responsible for new product beta cycles and named customer accounts. He began his career as Reliability and Maintainability Engineer for a government contractor building flight and training simulators. He earned a Bachelor of Science degree in Electrical Engineering from the State University of New York at Stony Brook.