Creating an AD Security Group with PTA: How to Handle Required Distinguished Name via Action: AD

Identity Security Cloud (ISC) ISC Discussion and Questions
, ,
1

I recently built a SailPoint Interactive Workflow - Privileged Task Automation (PTA) to create an AD security group.

I started with a simple flow:
Interactive Trigger (user launches workflow)
Interactive Form (collect group name from user)
PAG: Search AD Group (check if group exists)
PAG: Create Group (Action: Active Directory- creates the AD security group)
Message: Group Created

The main challenge I ran into was that the PAG Create Group action (Action: Active Directory), requires a Distinguished Name, but the DN field does not support dynamic string concatenation or JSONPath expressions directly.

Whilst I know you can create a PowerShell script and execute it via PTA, I wanted to use SailPoint’s native workflow capabilities.

I attempted to add the following in the DN field, as a valid DN is mandatory:
CN={{form.groupName}},OU=Permissions,…
CN=$.interactiveForm.formData.groupName,OU=Permissions,…

However, these were treated as literal strings and failed DN validation.
In some cases the workflow completed without errors, but the group appeared in AD with the literal name, “{{form.groupName}}” instead of the value provided in the form.

Solution:
I added a Define Variable operator to make the DN before the Create Group step (after the interactive form).

Variable Name: GroupDN
Variable A: CN=X,OU=Permissions,OU=Groups,…
Operator: Replace = choose variable = interactive form - formData - GroupName
Define Variable Operator - SailPoint Identity Services

Now that the DN is fully constructed - we can add it as a “Choose Variable” - groupDN and voila! It is now an acceptable action without errors.

TLDR:
If you need to dynamically create AD objects with PTA and the connector requires a Distinguished Name:
Build the DN using Define Variable, then pass it into the PAG action using “Choose Variable

Any other solutions / comments welcome!

Thanks.

Guidance / Example Workflow for AD Group Creation using Privileged Task Automation
2

Hello, Laura. Hope you’re doing great!

At this part:

"I attempted to add the following in the DN field, as a valid DN is mandatory:
CN={{form.groupName}},OU=Permissions,…
CN=$.interactiveForm.formData.groupName,OU=Permissions,…"

Have you also tried like this?
CN={{$.form.formData.groupName}},OU=Permissions,…
CN={{$.interactiveForm.formData.groupName}},OU=Permissions,…

According to the error it looks to me the it accepts the dynamic variable, but it is not getting the right one.

In any case, using defineVarible was a great idea. Good job.

1 Like
3

Hi @t-9lmorg

Two quick enhancements I’ve seen help in real tenants:

  1. Sanitize the CN input before building the DN
    AD DNs require escaping/reserving certain characters (comma, plus, quotes, angle brackets, semicolon, leading #, trailing space, etc.). If users can type group names freely, a small “cleanup” Define Variable step (strip/replace risky chars, trim) prevents intermittent DN syntax failures.

  2. Don’t hardcode the OU — let the workflow pick it
    PTA already includes AD OU commands (search/list OUs). You can populate a dropdown in the interactive form (or map “environment → OU DN”), store the selected OU DN, then build:
    GroupDN = "CN=<cleanName>," + <selectedOuDn>
    This keeps the workflow reusable across domains/environments and reduces mistakes when OU paths change.

2 Likes
4

I would just like to add for point 2, I agree it’s less error prone if a list of values is provided to users to choose from. But I do have to mention that Form Inputs are limited to 100 values, if the OU list retrieved with PTA contains more results only the first 100 will be visible in the list. Unfortunately I came across this issue and it’s very limiting at the moment → select field documentation

And for point 1 a regex in the input field in the form might also be used to clean the CN

1 Like