Tagged: ADSIedit

Securing Active Directory in a multitentant environment

Securing Active Directory

This article describes how to isolate Active Directory in an environment which is shared by many organisations or where departmental or business division administration is delegated.

Setting the Active Directory Access Mode

Using ADSIedit modify the dsHeuristics value to 001

ADSIedit > Configuration > Services > Windows NT > Directory Service > dsHeuristics > Properties > attribute value = 001

This setting allow you to define granular access control to objects within a container or OU to a particular group or user.

Setting the default security descriptor for a Organisational Unit

Using ADSIedit modify the defaultSecurityDescriptor for Organisational Units.

ADSIedit > Schema > Organisational-Unit > Properties > defaultSecurityDescriptor =

D:(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)(OA;;CCDC;bf967a86-0de6-11d0-a285-00aa003049e2;;AO)(OA;;CCDC;bf967aba-0de6-11d0-a285-00aa003049e2;;AO)(OA;;CCDC;bf967a9c-0de6-11d0-a285-00aa003049e2;;AO)(OA;;CCDC;bf967aa8-0de6-11d0-a285-00aa003049e2;;PO)(A;;LCRPLORC;;;ED)(OA;;CCDC;4828CC14-1437-45bc-9B07-AD6F015E5F28;;AO)

This removes the Authenticated Users Access Control Entry (ACE) from the new OU template.

Creating a OU hierarchy

This depends completely on the business but as an example you could have:

  • Domain
    • Business Departments
      • Service Groups
      • Finance
        • Service Groups
        • Users
        • Computers
      • Development Team
        • Service Groups
        • Users
        • Computers
    • Business Computer Infrastructure
      • Backup Servers
      • Deployment Servers
      • Service Groups
        • Groups
      • Users

This above hierarchy will make sense later on in the article.

Securing the default containers

The following containers will be viewable by all users i.e.  Authenticated Users unless you remove the Authenticated Users ACE.

  • Builtin
  • Computers
  • Domain Controllers
  • Users

Creating groups for delegation of Administration and other Active Directory functionality

The following groups are required to ensure the OU hierarchy defined above works i.e. users can read group policies, delegated administrators can create users, change passwords etc.

  • Business Departments/Service Groups
    • g_allAdminsGroup@yourCompany
    • g_allUsersGroup@yourCompany
  • Business Departments/…/Service Groups
    • g_Allusers@DepartmentName
    • g_Admins@DepartmentName
    • g_Users@DepartmentName
    • g_ServiceUsers@DepartmentName
    • dl_ComputerAdministrators@DepartmentName
    • dl_RemoteDesktopUsers@DepartmentName
  • Business Computer Infrastructure/Service Groups/Groups
    • g_CompanyAdministators (Level 1)
    • g_CompanyAdministrators (Level 2)
    • g_CompanyAdministrators (Level 3)
    • dl_BackupServerOperators
    • dl_BusinessComputerInfrastructureAdmins
    • dl_BusinessAdministrators
    • dl_EnterpriseAdministrators

Creating a group membership strategy

The following group membership strategy utilises the groups created above to create a secure Active Directory environment.

  • g_AllUsers@DepartmentName
    • Member Of:
      • g_AllUsersGroup@yourCompany
    • Members:
      • g_Users@DepartmentName
      • g_Admins@DepartmentName
      • g_ServiceUsers@DepartmentName
  • g_Admins@DepartmentName
    • Member Of:
      • dl_ComputerAdministrators@DepartmentName
  • g_AllAdminsGroup@yourCompany
    • Member Of:
      • g_AllUsersGroup@yourCompany
    • Members:
      • g_CompanyAdministrators (Level 3)
  • g_CompanyAdministrators (Level 3)
    • Member Of:
      • dl_BusinessAdministrators
      • dl_BackupServerOperators
    • Members:
      • g_CompanyAdministrators (Level 2)
  • g_CompanyAdministrators (Level 2)
    • Member Of:
    • Members:
      • g_CompanyAdministrators (Level 1)
      • Member Of:
        • dl_BusinessComputerInfrastrucutreAdmins
        • dl_EnterpriseAdministrators
      • Members:

The group membership strategy basically has g_CompanyAdministrators (Level 1) as the senior administrators for the enterprise, g_CompanyAdministrators (Level 2) and (Level 3) would be administrators and juniors. The enterprise administrators (senior to junior) could have access to the business divisions or departmental administrators hierarchy for support etc.

Creating a user membership strategy

Departmental or business division users would be members of g_Users@DepartmentName, delegated administrators would be members of g_Admins@DepartmentName.

I have defined a group called g_ServiceUsers@DepartmentName this would be used for service users specific to that department e.g. Microsoft SQL server for the development team or users that run scheduled tasks.

The departmental computers would be members of domain computers by default but would also be a member of g_AllUsers@DepartmentName.

Securing departmental organisational units and delegating administration

Assign the group g_AllUsersGroup@yourCompany read permission (this object only) on the Business Departments OU.

Assign the group g_AllUsers@DepartmentName read permission (this object and all child objects) on the respective department OU.

Assign the group g_Admins@DepartmentName create / delete group objects, create / delete user objects (this object and all child objects) and full control (group and user objects) on the respective department OU.

(if enterprise administrators support departmental administrators  delegate these privileges) Assign the group g_AllAdminsGroup@yourCompany list contents, list object, read all properties, write all properties, read permissions, modify permissions, all validated writes, all extended writes and create all child objects (this object and all child objects) on the Business Departments OU.

Group Policy Management delegation

Template policies

A number of template policies would be required. The most important one would determine the local computer membership and users rights for a particular department e.g.

Computer Configuration/Windows Settings/Security Settings/Restricted Groups/

  • Administrators
    • dl_BusinessAdministrators
    • dl_ComputerAdministrators@DepartmentName

You may also configure the Remote Desktop Users group, if depends on how you would support the departmental users. In that scenario it would be wise to determine who can logon via Remote Desktop Services using Group or Local policy

Computer Configuration/Windows Settings/Local Policies/User Right Assignment/

  • Allow log on through Remote Desktop Services
    • dl_RemoteDesktopUsers@DepartmentName
    • dl_BusinessAdministrators
    • dl_ComputerAdministrators@DepartmentName

Policy delegation

Below are some example group policy delegation permissions e.g. the enterprise administrators are allowed to link existing GPOs to the Business Departments OUs, juniors enterprise administrators are allow to editing existing GPOs as are enterprise administrator but juniors cannot link them; think peer review of GPOs.

Linking GPOs

Open GPMC.msc and navigate to Forest/domains/domain.name/Business Departments/

Select the delegation tab and assign the ‘link’ permission to g_CompanyAdministrators (Level 2)

Editing GPOs

Open GPMC.msc and navigate to Forest/domains/domain.name/Group Policy Objects/templatePolicy1

Select the delegation tab and assign the ‘edit settings’ permission to g_CompanyAdministrators (Level 3)

Creating GPOs

Open GPMC.msc and navigate to Forest/domains/domain.name/Group Policy Objects

Select the delegation tab and assign the ‘add’ permission to g_CompanyAdministrators (Level 1)

You could also deploy something similar at the Business Department level so departmental adminstrators could link specific policies.

Advertisements