Active Directory is essential to any Microsoft network built on the client-server network model. It provides a simplified query for administrators and users to manage resources, sites, services, and users on a network
Active Directory was first provided in Microsoft Windows 2000. It is often managed and controlled through the MMC (Microsoft Management Console).
In this post, I will be discussing the most common practices in securing Active Directory.
Before we begin, let’s get familiar with some Active Directory concepts.
Domain
A domain is basically a set of resources, like users, passwords, printers, etc which are managed by a domain controller. The key benefit of this is the fact that any user that is in the system can login to the arbitrary machine in the network with the same username and password. In a Windows environment, all the information is stored in an Active Directory (AD).
Domain Controller
A domain controller (DC) or network domain controller is a Windows-based computer system that is used for storing user account data in a central database. A domain controller in a computer network is the centerpiece of the Active Directory services that provide domain-wide services to the users, such as security policy enforcement, user authentication, and access to resources [2].
Domain controllers can greatly simplify the administration, since we can use it to grant or deny access to resources on the network, such as printers, documents, and shared folders, with one single user account. By using the domain controller, a user can also get access to his personal resources like files on a Desktop from anywhere in the network; all he has to do is login with his existing user account.
With that being said, let us now take a look at the Security /Risk concerns common with Active Directory
1. Numerous Domain Admins
By default, Domain Admins group members have full administrative rights on all workstations, servers, Domain Controllers, Active Directory, Group Policy, etc. This is too much power for any account in an organization which contradicts the good practices of securing Active Directory environment. Only Active Directory Administrators require Domain Admins privileges. Whoever is not actively managing Active Directory, should not be in the Domain Admins group. Delegations must be used if in case someone needs to work on a specific part of the Active Directory. Also, service accounts should not be in this group.
2. Delegated Access are not tracked
In securing an Active Directory environment, default groups provide too much privileges. Ensure you know the function of the default group before granting it to any user.
3. Service Accounts with short password and over-permissioned
I have seen many times when vendors simply ask for Domain Admins rights for its service account which actually may not be needed at all. Hackers are fond of privileged accounts and especially loves service accounts because it is less attentive. Additional privileges to service accounts can be used maliciously to escalate privilege on the network. It should be noted that service accounts credentials are in the protected memory of LSASS process, thus an attacker can easily extract that password which may lead to compromise.
Another mitigation against Kerberos brute force attack (offline) is to use the password longer than 15 characters. This can be achieved by configuring a fine-grained password policy for service accounts.
4. Using credential in Group Policy Preferences (GPP)
Windows 2008 came out with Group Policy Preferences which provide additional functionality to system administrators. They can manage local accounts and credentials, local groups and schedule tasks, etc. This has created a big issue because encrypted credentials are stored in an XML file which is located in SYSVOL share. This share can be accessed from any domain-joined system. If the credential is already configured in GPP, remove it immediately. Delete the XML files from the SYSVOL. Microsoft also released the patch MS14-068 to address this vulnerability which removes the functionality to manage credentials.
5. Unpatched Servers and workstations
Regular patching of servers has been an issue in many organizations. Records have consistently proven that the vulnerabilities exploited were successful as a result of servers that have not been patched for more than a year. Patching is very critical for securing Active Directory environments. It is actually not realistic having a system not patched for months when there is a vendor-released patch. Unpatched systems provide the ability for attackers to gain privileged access to the systems.
see this link to learn more
6. Unmanaged Admin group membership
Most of the time group membership keeps increasing. Admin groups especially in Active Directory need to be monitored and scrutinized closely. Some of them, Domain Admins, Administrators group, Account Operators, and any other user-created group which provides privileged access to systems, if not monitored can be a serious cause for concern.
7. Local administrator account password is same across the network
Local account is used to login to the system when Active Directory is not available. Most of the time, system administrators build servers with the same password for local administrator account. It may happen that all systems will have the same password for local administrator account. If the account is hacked, this will provide the access to all the system, making life easy for hackers. Therefore, each system must have a unique password for its local administrator password. There are many softwares available that will not only manage the unique password but also rotate them on regular basis.
8. Unmanaged inactive user and computer accounts
Enabled redundant/inactive accounts in Active Directory always attract attackers because they can be leveraged to get access to resources without being noticed. There are few different ways to take control of the account, since it is inactive, most probably the usage will not be noticed. We should have a plan to deal with inactive user accounts.
9. No isolation for highly privileged accounts and systems
Pass-the-Hash attack is the perfect example for such type of environment where the same privilege account is being used to logon to servers, domain controllers, and workstations. We have been talking about this attack for so many years but still organizations are lagging behind. Imagine if the malware gets into computers inside the network. Attackers using this malware will search for the credentials to steal and re-use it. if the privileged account’s logon to various computers, those credentials on the system can be stolen. It is important that all highly privileged accounts must be isolated. Domain Admin accounts must not be used to logon to workstation and member servers. Regular accounts must not be given administrative level of privileges on any system, rather separate accounts must be created for admin level of work.
Download this Article
[hubspot type=form portal=8577853 id=f82bb3f2-ac04-48d5-a36a-26a8b33e7b8a]
Leave a Reply