The matter of managing the security for all account types in a network is very important to managing risk. Internal and external threats must be taken into account, and the solution to these threats must balance the need for security with the functionality a business demands from their network resources.
Before proceeding, a number of terms need some clarification, as
- Services are executables that run at startup or can be triggered by other events or scheduled instances. Services often run in the background without much user prompting or interaction.
- Service accounts. Simply put, a service account is often described as any account that does not correspond to an actual person. These are often built-in accounts that services use to access resources they need to perform their activities. However, some services require actual user accounts to perform certain functions, and many businesses still employ the practice of using domain accounts to run services as well.
- Administrative account. Although there is a default Administrator account created on any new installation of a software like Microsoft Windows or Active Directory domain, the term administrator account is often used in a general sense to describe any account that has been granted administrator level privileges.
- Critical accounts. This document uses the term “critical account” to describe default accounts that are considered high risk because they have high-level privileges or present elevated risks due to their ubiquitous use.
- Limited account. A limited account is any account that is not a member of any administrative group and that does not have any elevated privileges that are equal to that of a local or domain administrator account. Typically, a limited account would be a member of the Domain Users group or the local Users group.
- Guest Account – It is an account for users who don’t have a permanent account in the computer or domain. It allows people to use computer without having access to personal files. People using the guest account can’t install software or hardware, change settings, or create a password.
(e.g., user accounts, service accounts, temporary accounts, default accounts, guest accounts, account expiration,
User Lifecycle
User lifecycle is a term to describe the process flow of how a user entity is created, managed, and terminated in the system based on certain events or time factors. A user entity goes through various stages in the lifecycle. The stages are non-existent, disabled, active, and deleted. The below figure depicts the different lifecycle stages, all possible transitions, and the operations that set up those transitions
There is a possibility of process rules or business requirements being defined for each transition of the user lifecycle. You can use the sample scenarios listed in the below table to establish the link between user lifecycle transitions and business objectives with sample scenarios.
| Current State | Operation | Sample Scenario | Process Description |
| Non-existent | Create | HR enters user profile information for a new hire. If the new hire is not introduced to the system immediately, then HR sets a future start date for the user. | If the start is not a future date then the user is introduced into the system in an Active state. If the Start Date is in future then the create process creates the user in a disabled state. |
| Disabled | Enable | User’s start date is in effect. The system initiates provisioning for the new hire. | User is marked enabled in the system and the user is now able to login and use the system. By default, all necessary memberships and accounts are established as part of the workflow. |
| Active | Modify | User is promoted to a new position. As a result, HR changes the job title of the user. | New resources are provisioned to the user, and old irrelevant resources are de-provisioned from the user. |
| Active | Disable | User takes one year sabbatical from the company. HR manually disables the user on the last working day of the user. The user re-joins the company after some period. HR can make the user Active again. | User is marked disabled in the system, and the user is no longer able to login to the system. The disabled users can be made Active again. |
| Active | Deleted | User retires from the company. HR manually disables the user on the last working day of the user. | User is marked disabled in the system, and the user is no longer able to login to the system. By default, all users’ accounts are de-provisioned as part of the workflow. |
The management of user accounts must also coincide with the management of groups, computers, domain controllers, services, security, applications, files, and everything else that must be managed on a typical corporate network. Managing user accounts through the life of the account can be both taxing and unrelenting. However, some solutions manage users from creation, through changes over their employment, to removal when the user account is no longer needed. Such systems reassure administrators that all user accounts will be correctly managed and the daily tasks of user life cycle management will be addressed.
You have several types of users: internal & external, person & application, permanent & temporary.
- Internal/external users: these should be in a metadirectory that allows you to manage them separately and not equally. Internal users should have their lifecycle determined by an HR system, you really don’t need to set an expiration date unless they are temps/contractors. External users should have a set policy on how long they live with an internal user attesting to their account on a scheduled basis.
- Person v. application users: The person object is an EmpowerID terminlogy to note the user’s identity, linking each application user account (AD, SalesForce, Google Apps for example) to the person object. Application accounts should either have a lifecycle that needs attestation and certification or be tied to a role or group membership (which likewise has a lifecycle).
- Permanent v. temporary users: Temporary users come with a built-in lifecycle, you know that you are only authorized to hire a contractor for a 3 month engagement, it is easy to tie an expiration date to that user but you need to have an attestation workflow that easily extends the user without having to re-grant all of their privileges.
