Active Directory Best Practices

Before taking any actions with Active Directory, review these best practices carefully.

AD Bridge Cells provide a means of directly managing Unix identities in Active Directory. Best practices are to use Cells rather than Unprovisioned mode wherever possible.

This is so a user’s Unix group membership can be limited to less than 16 groups when required for NFS (or 32 groups for Solaris) without impacting normal Windows group membership management practices.

Directory Integrated Mode

After installing the AD Bridge tools, the first determination that must be made regards Directory Integrated or ID Range. Directory Integrated Mode is strongly preferred.

This causes all lookups to use indexed attributes in AD, lowering the cost of each lookup against the AD domain controller (DC). Windows 2012 Forest Mode forests with Windows 2012 R2 domain controllers can be transitioned to Directory Integrated Mode without extending the AD Schema. Because Microsoft forest modes are moving in this direction, and because of performance increases, Schemaless Mode should be avoided where possible.

Cell Design

AD Bridge Cells allows managing overlapping Unix identities within a single Active Directory organization for AD Bridge. Cells work in Directory Integrated or Schemaless Mode, as described above. There are two possible cell structures:

  • Named Cells: Named Cells store Unix identity information (uid, uidNumber, gidNumber, gecos, unixHomeDirectory, logonShell) in a subcontainer of whichever Organizational Unit (OU) is associated with the cell. Whether a user exists in the local domain or a trusted domain, the Unix identity information exists in an object in the cell. In other words, a Named Cell may reference users or groups from outside the current AD domain, but stores data in the domain where the computer is joined.
  • Default Cell: In contrast to Named Cells, there is a single Default Cell, and it is enterprise wide. That is to say, all trusted Microsoft Active Directory Global Catalogs are part of the single Default Cell. However, individual AD Domains opt-in to the Default Cell by creating the Default Cell object in the root of those domains. In the Default Cell, the Unix identity information is stored in the same OU as the user object that the Unix Identity information is related to. This enforces a single Unix identity for a single AD user across the entire enterprise. Therefore, the Default Cell should be viewed as the ultimate authority for Unix information within an enterprise.

Cells store Unix identity information separate from other cells. This allows a single user or group to have different names, or different numerical ID values (UID or GID) in different environments, all tied back to the same AD identity. This also allows multiple users or groups to have overlapping names or numerical ID values (UID or GID) in separate environments. Each cell will require additional overhead for Standard Operating Procedure for account management and for troubleshooting end-user log in issues, as both cases will require the additional step of determining which cell the operation must be performed against.

To keep end-user and help desk troubleshooting complexity to a minimum, while allowing the flexibility of cells, BeyondTrust suggests no more than four cells.

Cells are only a method of managing conflicting Unix identities within an environment. While they can technically be used to limit end-user access to a system, this is against the design of AD, which allows all users to be seen by any joined client, but limits authorization based on other methods. Therefore, BeyondTrust suggests strongly that cells not be used as access control (authorization), but only as a part of the authentication system, and that the AD Bridge setting RequireMembershipOf or Allow Logon Rights be used for authorization.

Directory Integrated Mode Cells

In Directory Integrated Mode, the Default Cell stores the Unix identity information directly on the user or group object, in the exact same manner that First Name (givenName), Address (address, city, state), and Email (emailAddress) attributes are.

In Directory Integrated Mode, Named Cells create objects of class PosixAccount and serviceConnectionPoint which are linked back to the user or group object associated with the cell object.

Because the Directory Integrated Mode Default Cell stores the information directly on the user or group object, existing Identity Management (IDM) products do not need to be modified to provision users for the Default Cell in Directory Integrated Mode. This also allows non-AD Bridge systems which use the RFC2307 attributes to use the same identity information as AD Bridge.

Default Cell Directory Integrated Mode is therefore the preferred method for all AD Bridge installations. In all cases where Unix identity information can be made to be non-overlapping, the Directory Integrated Mode Default Cell should be used.

Directory Integrated Mode Named Cells are recommended wherever multiple cells beyond the Default Cell are required.

Schemaless Mode

 

Schemaless mode is deprecated. The content below is for information only.

Because of the performance benefits of Directory Integrated Mode Cells, and that Microsoft AD is moving towards Directory Integrated Mode by default, Schemaless Mode is deprecated, but 100% supported. The AD Bridge clients determine cell and schema configuration upon every startup. This allows migration from Schemaless Named Cells to Directory Integrated Named Cells to be as simple as dragging a computer object between OUs.

However, because of how the data is stored, migration from a Non-Schema Default Cell to a Directory Integrated Mode Default Cell configuration requires more work, more steps, and more potential risks than any other cell migration.

For migration and long-term support purposes, Schemaless Mode cells should only be created as Named Cells.

User Rights

Because AD Bridge software joins the Unix computers to AD with the same API calls as Microsoft Windows uses, in most cases, the same rights are required in AD for Unix administrators as Windows administrators need to join the domain. BeyondTrust recommends that Unix computer accounts be either pre-staged or that the Unix administrators be delegated control to an OU that all Unix computers will be joined to.

For more information on pre-creating computer accounts, see Microsoft's documentation at https://support.microsoft.com.

Do Not Provision the Domain Users Group

By default, the Domain Users group is provisioned to new cells so there is a GID for new users. This is to streamline deployment but is not recommended for production use.

In environments with frequent user or group enumeration, this will generate a lot of LDAP traffic to list all the provisioned users and groups. By default, all users are part of Domain Users and this will cause enumeration of all users in the domain.

We recommend creating a group for the cell to limit the enumeration.

Netlogon Authentication

 

This is an early release feature. We recommend enabling the feature in a test environment and sending in feedback.

We recommend enabling Netlogon authentication to validate the domain controller (DC) through a secure channel connection. This adds an extra level of security when communicating with the domain.

Enable Netlogon authentication using the following command:

/opt/pbis/bin/config DCValidationSupport true

DCValidationSupport

/opt/pbis/bin/config --verbose DCValidationSupport
Current local policy value: false
Using default value: false
Executing command: /opt/pbis/bin/lwsm refresh lsass
Refreshing service: lsass

DCCacheExpiryInterval

DCCacheExpiryInterval is the length of time the agent holds onto the cached DC information.

/opt/pbis/bin/config --verbose DCCacheExpiryInterval
Current local policy value(s): 1440
Using default value(s): 1440m
Executing command: /opt/pbis/bin/lwsm refresh lsass
Refreshing service: lsass

 

DCCacheEnabled

The DCCacheEnabled allows the agent to cache the DC information.

/opt/pbis/bin/config --verbose DCCacheEnabled
Current local policy value(s): true
Using default value(s): true
Executing command: /opt/pbis/bin/lwsm refresh lsass
Refreshing service: lsass

Active Directory Best Practices Summary

  • Use Cells.
  • Use Directory Integrated Mode.
  • Use Allow Logon Rights or RequireMembershipOf for access control.
  • Use the Default Cell in Directory Integrated Mode where possible.
  • If Schemaless Mode is required, use only Named Cells.
  • Delegate Control to Unix Administrators to join AD Bridge computers.
  • Do not provision the Domain Users group.