Creating a OneFuse Active Directory Policy

The OneFuse Active Directory (AD) module offers features for placing deployed computer objects into the appropriate Active Directory (AD) organizational units (OU).  This includes support for pre-build organization units (OU), final Organizational Unit placement, as well as placement of computer objects into Active Directory (AD) security groups. 

Active Directory (AD) Policies are able to be dynamically driven offering flexibility in placement decisioning.  This is a critical feature as most Active Directory (AD) structures have grown organically over time and are very complex in nature.

OneFuse empowers you to wrap organization specific business logic into the policies removing the need to complex custom code as well as complex configurations within your CMP to align with your Active Directory (AD) architecture.  Below is a list outlining some of the features and value offered with the OneFuse Active Directory (AD) module:

• Support for pre-build OU’s
• Support for Final OU Placement
• Ability to dynamically create OU’s
• Ability to destroy empty OU’s
• OneFuse Template Engine syntax (based on Jinja2)
• Add computer object to Active Directory (AD) Security Groups
• Dynamic Policy Targeting
• Supports direct connection to Active Directory (AD) Domain Controllers
• Supports use of a Jump Host
• Leverages industry standard SSH connectivity

In this article, we are going to walk through creating a simple Active Directory (AD) policy that will later be used to show how OneFuse Active Directory (AD) policies can be consumed within upstream platforms.  In future articles, I will cover more advanced topics related to the features listed out above.

AD Considerations

1. Will you be using a jump host or connecting directly to an Active Directory (AD) domain controller?
   1. If using a jump host do you have a jump host with OpenSSH enabled?
   2. If connecting directly to a domain controller is OpenSSH enabled?
2. Will you be utilizing a pre-build OU?
   1. Are there any policies associated with the OU(s) that may prevent certain scripts or activities from being performed?
   2. What build OU(s) will be utilized? 
3. What final OU(s) will be used for this example?
4. Will you be communicating with more than one Active Directory (AD) domain?
   1. Is there trusts in place for the domains?
5. Will your computer objects be placed into a security group(s)?
6. What account will be used by OneFuse to communicate with Active Directory (AD)

Prerequisites

• Active Directory (AD) domain controller
• Jump host if planned for use
• Service Account with appropriate permissions for domain being utilized
• Open SSH needed on endpoint being used (domain controller or jump host)
• Information regarding the OU(s) and or Security Groups(s)

Tasks to complete

1. Create Microsoft Credential
2. Create Microsoft Endpoint
3. Create Active Directory (AD) Policy

Creating a OneFuse Microsoft Credential

The first thing we need to do is a create a Microsoft credential for the service account that will be used to communicate with Active Directory (AD).  

1. Select “Module Credentials” from the left menu.
2. Select “Create” and then select “Microsoft” from the list.
3. Here you will need to give your credential a name, a description, ensure “Microsoft” is selected as the “Endpoint Type”, input the username and password for your service account and then select “Create”.
4. You will then see your new credential in the list of available credentials.

Create a Microsoft Module Endpoint

Now that the “Module Credential” has been created we can go ahead and create the “Module Endpoint. .  If you have multiple domains without trusts you can create multiple endpoints to connect them all to OneFuse.

1. Select “Module Endpoints” from the left menu.
2. Select “Create” and then select “Microsoft” from the menu.
3. On the create a “Module Endpoint” page provide the following information:
   • Microsoft Endpoint Name – Name to identify endpoint
   • Description – Optional
   • Version – Currently only 2019 listed, however 2016 is supported if you install OpenSSH
   • Connection Method – OpenSSH currently only supported connection
   • Use Jump Server – Will you be using a Jump Server or No
   • Jump Host – (If selected) Input the FQDN of the jump host
   • Jump Host Port – 22 unless changed from the default
   • Microsoft Host – Input FQDN of Domain Controller
   • Microsoft Host Port – 22 unless changed from default.
   • Module Credential – Select credential that was created in previous step
   • Single Threaded Operation – Do you want to operate a single-thread or multi-thread?
4. Select “Next Defaults” from the top-right of the page.  On the “Defaults” you can change the temporary directory and optionally associate a share path for the temporary directory if one exists.
5. Select “Create” once finished.  You will then see your new “Microsoft Endpoint” listed under “Module Endpoints”

Creating an Active Directory Policy

Now that we have our “Microsoft Module Endpoint” we can create our “Active Directory Policy”.  If you haven’t read my previous articles this is what will be consumed by the upstream providers.  Policies define the specifics on how the integrations should behave.

1. Select “Microsoft Active Directory” from the home page.
2. On the “Microsoft Active Directory” page select “Create”
3. On the “Create a Microsoft Active Directory Policy” page provide the following information:
   • Microsoft Active Directory Policy Name – Policy name
   • Description – Optional description for your policy
   • Microsoft Endpoint – The Microsoft Endpoint we created in previous steps.
   • Computer Name Lettercase – Do you want your computer object to be all uppercase or all lowercase?
   • Use a Build OU? – Will you be using a build OU?
   • Interim OU during Build – Your OU in LDAP format. The following example is what I have used in my test environment.  A few things to note OU, DC, and other designators should be in all capitals. In my example you will also see template language in my example.  If we break down {{ouGroup | required}} this statement.  We are taking in an input variable called ouGroup and the required statement is exactly as it sounds.  This is a required component.  If null it will fail the build.
     • OU={{ouGroup | required}}, OU={{ouEnv | required}}, OU=build, DC=2k19ad, DC=sovlabs, DC=net
     • Create Build OU – If enabled OneFuse will create the OU if it does not exist.
     • Remove Build OU – If enabled OneFuse will remove the OU if empty.
   • Destination OU after Build – The final OU for the build.  This is where OneFuse will move the computer object to once the build is complete.
     • Create OU – If enabled OneFuse will create the OU if it does not exist.
     • Remove OU – If enabled OneFuse will remove the OU if empty.
   • Security Group(s) – AD security groups that you would like the computer object joined to.
   • *Note – Remember anywhere you see {} template engine syntax can be used.  Wherever you have {{somevalue}} designated a variable that needs to be passed in as an input to the request.
4. Once Finished inputting all the information select “Create: to create the policy.
5. You will then see your policy in the list, and it is now ready to be consumed.

We have now successfully created an Active Directory (AD) policy within OneFuse.  In future articles, I will discuss how to drive the OneFuse module dynamically from upstream tools like vRA8 and Terraform.