Collections
Deploying Active Directory
Security
Administrative Rights

Administrative Rights

In this article, we’ll walk through the process of managing and controlling administrative rights across our infrastructure. This is a critical step in configuring a domain as it helps to prevent lateral movement if an administrative credential is compromised.

In essence it allows to you box in various hosts so if one set of hosts are compromised, other hosts remain unaffected; limiting damage.

Using an Example

To demonstrate configuring administrative rights, its best done using an example. Assume a fictitious company has the following servers:

Managing these servers, this company has the following staff:

  • A Systems Administrator.
  • A Junior Systems Administrator, who helps with helpdesk tickets.
  • An internal developer who maintains a core business app running on the app servers.

Given the above, how would we divide this environment so laternal movement is limited if a compromise occurs? Here’s one possible layout:

In this example, we’re dividing all hosts based on their function: Remote Desktop Services, App Servers, File Servers etc. Another option would to be go even further and subdivide the app servers based on what service each app is offering or if security isn’t as large of a concern, you could combine services into one area. For example, the hypervisors and file servers.

Here are some best practices.

Remote Desktop Services

Remote Desktop Services, as one of the most exposed services to the internet, should always be segmented as a general best practice. It’s also recommended this service always be network segmented (DMZ) as well due to the same concerns.

If compromised, hackers would gain access to the server(s) however between the segmentation of both administrative and network access, lateral movement deeper into your network would prove difficult.

Domain Controllers

The Domain Controllers are considered one of the juiciest targets on a network by hackers and should always be administratively segmented no matter the size of your organization. If compromised, hackers will use Active Directory to simply allow themselves access to all other parts of the infrastructure. You can consider Active Directory the literal keys to the castle.

App Servers

In our fictitious company segmenting the app servers would be benefitical as it:

  1. Further reduces laternal movement if a host is compromised.
  2. Allows administrative access for the developer without giving administrative access to other unrelated hosts or services.

Organization

With our plan determined, we now need to layout how it will look within Active Directory. There are three core components:

  1. A security group for each segement controlling administrative access.
  2. A GPO for each segment to configure administrative rights.
  3. A suitable OU structure for the GPOs.

Security Groups

Within a suitable OU (it doesn’t really matter where), create a Domain Local security group for each segment. For now, don’t create a group for the Domain Controllers.

As always, it’s recommended that you use a naming convention for your security groups so you can easily tell which group controls which segment. One example would be: AdminRights_Hypervisors, AdminRights_RDSHosts, etc.

New-ADGroup -Name "GroupName" `
    -SamAccountName "GroupName" `
    -GroupCategory Security `
    -GroupScope DomainLocal `
    -Path "OU=YourOU,DC=domain,DC=com" `
    -Description "Description of the group" `
    -DisplayName "Group Display Name"

Next, add the users who should gain administrative rights for each segment to their respective security group.

Add-ADGroupMember -Identity "GroupName" -Members "Username"

GPOs

For each segment create a GPO. As with the security groups, its recommended a naming convention be followed. Again, don’t create a GPO for the domain controllers.

For each GPO:

  1. Browse to Computer >> Windows Settings >> Security Settings >> Restricted Groups.
  2. Right-click on Restricted Groups and select Add Group.
  3. Under Group, locate the respective security group.
  4. Within the next window that appears, under This group is a member of: select Add and enter (don’t search): BUILTIN\Administrators.
  5. Press OK to close out of all windows.

OU Structure

It’s now time to apply our changes. The GPOs can be applied in one of two methods depending on your OU structure:

By OU

If you have each computer object for each segment under a dedicated OU, apply the respective GPO to the OU.

By Group

If you have all computer objects within one OU, apply all GPOs to the OU but filter based on segment so only that segment will have the respective GPO applied. If using this method, you’ll typically already have a security group with the hosts of each segment configured.

The Exception

Lastly! For the domain controllers, you’ll notice that we really didn’t setup anything… This was purposeful as Domain Controllers are a special case in how administrative rights are handled.

To correctly configure a Domain Controller, add all users requiring administrative rights to the Domain Admins group. This group is apart of the Administrators group so they will also simultaneously gain administrative rights over the host.

The reason we didn’t configure domain controllers as we did other segments is due to the fact that granting a user administrative rights over a domain controller effectively grants that user Domain Admins privileges (as they can just add themselves to the group).

Due to this, its easiest to simply control access using the Domain Admins group so we immediately know that anyone within this group has administrative rights over the host but also full control over Active Directory.

Protected Users GroupCompability Access Group