AD module best practices

Best practices for the OneFuse Microsoft Active Directory module

  4 minute read  

The CloudBolt OneFuse integration platform offers an Active Directory Module that provides enterprise-grade Active Directory integration for Organizational Unit (OU) and Group Members for provisioned servers.

The OneFuse Active Directory module offers flexible support for dynamically creating computer objects into Organizational Units, including OUs for use during build time.

Resources

For additional information regarding OneFuse Active Directory, refer to the following documentation:

Prerequisites

For each Active Directory Policy you create, gather the following information:

  1. Domains that you will be interacting with.
  2. OU path(s) where the computer object will need to be created.
  3. Build OU path if Build OU is being used.
  4. Active Directory security group(s) that computer objects will be added to, if used.

Use jump servers for connectivity

Most organizations have security requirements that do not allow direct connectivity to domain controllers. In these cases, use a jump server that has the Microsoft RSAT tools available. In OneFuse, jump servers are called Jump Hosts. When using Jump Hosts, follow these best practices to ensure reliable and secure access to your Active Directory domain environment:

  1. Utilize OpenSSH connectivity between OneFuse and a Jump Server. This allows for a secure connection between the servers and supports easily managed firewall configuration to limit access to the Jump Server only from the OneFuse Server.
  2. Utilize trusts between domains to limit the number of OneFuse Endpoints and Service Accounts needed.

Use an isolated Build OU for automated deployments

An isolated Build OU is best practice for automated deployments. Build OUs should not have Group Policy restrictions that could interfere with automated build processes. Group Policies associated with Build OUs should include the following:

  1. Disable user access controls (UAC).
  2. Set PowerShell execution policy to “remote signed”.

Create a single Build OU

Although OneFuse allows you to dynamically create and destroy Build OUs, it is best practice to create a single Build OU for all server builds with tested and validated Group Policies applied. Dynamically creating and removing Build OUs is an edge case scenario that should only be used if absolutely needed.

Destination OU

Use separate Active Directory policies for production and other domains. This keeps logic to a minimum within any given policy, making policies easier to understand and maintain.

Limit if and case logic to edge case scenarios. The following two methods are recommended for destination OU targeting.

  1. If your OU strategy is structured within a domain, use a template like the following in the policy:

    OU={{app | required("Application is required")}}, OU={{group | required("Group is required")}}, OU={{env | required("Environment is required")}}, DC=domain, dc=com

    The variables should be relevant to your environment. app, group, and env are examples for illustrative purposes. Use the required filter to ensure all necessary values are present for OU placement. It is also best practice to use capitalization for OU, DC, and similar tokens.

  2. If your OU strategy is not very structured, define the OU path closest to the final OU. For example, if each group in your organization uses a different OU structure, define AD OU placement at the group level by referencing a single property in the policy:

    Destination OU within policy = {{ouPath | required("OU Path is required")}}

Then, within a Static Property Set that represents the groups, define the OU path:

GroupA
    ouPath = OU={{app | required("Application is required")}}, OU=devGroup, OU={{env | required("Environment is required")}}, DC=domain, dc=com.

GroupB
    ouPath = OU={{Component | required("Component is required")}}, OU={{Service | required("Application is required")}}, OU=InternalIT, OU={{env | required("Environment is required")}}, DC=domain, dc=com.

In the above example, GroupA and GroupB have very different OU placement strategies. By defining these within a Group-focused Static Property Set, you can maintain different OU strategies for each group without the need to create completely separate Active Directory policies for each.

For this scenario, the best practice is to leverage the above approach or use separate Active Directory policies. Having additional policies could result in additional management overhead depending on your environment.

Outcomes

Use best practices for build OUs, jump hosts, and destination OUs to make AD policies easy to maintain.