Some major steps we could take to secure user accounts on Active Directory:
- Group Managed Service Accounts
There are two types of accounts that can be used to protect an Active Directory, Managed Service Accounts (MSAs) and Group Managed Service Accounts (GMSAs). The basic premise of Managed Service accounts was to provide the management and isolation of a domain user account with automated password management. Microsoft’s trial to improve MSAs in Windows 2012 gave birth to a gMSAs which can be used on more than one device, run scheduled tasks, and work with applications such as IIS and Exchange. Windows Server 2012 domain controllers manages the 120-character password assigned to each gMSA throug Key Distribution Service (KDS). To use gMSAs we must have at least one Windows Server 2012 (or a higher domain) controller in your domain.
- Long Passwords
The applications that are not compatible with gMSAs can use passwords of at least 25 characters for service accounts. It should also implement a process for changing service account passwords. We have to place the service accounts in a dedicated organizational unit (OU) in AD so that they can be managed separately from other accounts, and make sure that a strong password policy is applied to them.
- Unnecessary access privileges
While creating a service account, we should always keep in mind that the Active Directory should only have the minimum privilege required to complete the task at hand among the privileges like remote access functionality, terminal service logons, internet and email access and remote control rights.
- Creating service accounts from scratch
The history of service account misuse includes accounts that had extra privileges because they were created by copying old accounts with high privileges. Copying lightens the administrative burden, but it comes with a risk. When we are creating a new service account by copying, we should always run the risk to inadvertently assigning excessive privileges, because the old account’s role may differ from the new one.
- Avoiding putting service accounts in built-in privileged groups
Assigning service accounts in built-in privileged group lets everybody in the group to know the service account’s credentials, that has high chance to be misused. Hence, with several administrators in that group knowing the credentials, tracking the offender becomes difficult.
- Denying access permissions to service accounts through ACL
We can use the ACL (Access Control List)/ DACL (Discretionary Access Control List) to secure important objects, like files, folders, shared folders and registry objects, from service account misuse.
- Taking away redundant user rights
We should review and eliminate unnecessary user rights to secure user accounts on AD. The rights that can be explicitly denied are “Deny access to this computer from the network” and “Deny logon as a batch job”.
- “Log On To” option
We can use the “Log On To” option to limit the number of computers to which a service account can log on denying the service accounts to be able to access file servers with sensitive data.
Click here for MCSE Certification