Active Directory Security Management is the second part of a series. In the first part we have that Basics of Active Directory taken up and explained simply.
We reported on what makes up the Active Directory and clarified important terms. In this article we will discuss techniques that help administrators make Active Directory secure.
When used correctly, Active Directory is a powerful tool. But it can also become a massive threat in the wrong hands. Therefore, the requirements for a secure Active Directory are increasing.
In many industries that are subject to all regulations such as BSI-Grundschutz, TISAX or BAIT, it is essential to ensure transparent and secure authorization management.
Giving people or groups direct permissions to a directory is a practice that should be avoided. As the number of employees increases, not only does the clarity of authorizations disappear, but security is also slowly undermined. Especially in times when... Insider Threats As the threat becomes ever greater, such an approach can prove problematic.
Instead, the best practice from Microsoft should be used. AGDLP describes exactly this recommended approach from Microsoft to the topic of role-based access control - RBAC for short. The abbreviation AGDLP stands for (computer and user) accounts, global groups, domains, local groups and permissions.
The approach states that permissions to a specific resource are not assigned to individual individuals. But is only given to the domain local groups. Within these domain-local groups are the global groups in which the individual computer and user accounts are located. Such an approach has several advantages:
Despite the large administrative effort - Microsoft has not yet published a standard tool for managing the required structures - AGDLP is a good approach to integrating a secure authorization structure into the Active Directory. But here too, the market offers third-party solutions that replace the missing tool, minimizing manual management.
Manually setting up security settings for each user or computer is a tedious and, above all, error-prone task. What sounds like a feasible task for small companies quickly becomes a mammoth task that can no longer be implemented safely when the hoped-for growth is achieved. Microsoft has also come up with a solution for this problem – group policies.
Group Policy allows administrators to define entire blocks of policies and then assign them according to the groups to which they should be applied.
Collectively, these group policies are referred to as GPOs - Group Policy Objects – or in German as Group Policy Objects. These individual settings, which an administrator defines, can then be applied as a group policy setting at the site, domain, organization level or locally to enforce rules and settings within their scope. For example, specific policies can be created for “notebooks”, which then act as a GPO for all notebooks in the domain.
The different levels at which group policies can be applied create a hierarchy:
Local Group Policies come first. They always have priority, followed by the location, domain and organizational levels. This means that the minimum password length can be defined as 12 at the organization level. However, if the policy is set to 16 locally on an administrator's device, the local policy takes effect. It is therefore all the more important to coordinate the guidelines precisely.
In order to achieve the best possible security, local and global group policies must not only be defined, but also understood and implemented during device onboarding in-house or at the service provider. Otherwise, it may happen that partially unsafe local guidelines are enforced over the more secure global guidelines.
Group policies, which are centrally managed in Active Directory, are only enforced when a user or device logs in within the domain.
To prevent this, group policies can also be applied locally on a device or on devices managed by a domain controller. These policies then only have a local scope and are not centrally managed via the Active Directory.
Accordingly, it is essential to use a combination of local and central group policies to ensure security even when a user is not logged in to the domain. In any case, it should be noted that larger security changes may have to be implemented on devices that cannot be distributed via the GPO domains.
