Create Multiple Groups

Question

Is there a way to have a business rule create multiple groups or users? I have a security model that creates 4 groups for a new work project. There is a Project Owner group, a Read/Write access group, a Read Only group and a No Access group.

I'd love to be able to add this to the Self Service portal. I would ask for the Project name, then create the 4x groups based on our naming convention. However, the current Business Rules don't allow for creating new objects, users, groups, etc.

A similar scenario is one where a user IT Admin comes on board. It would be nice to have a Check Box for an Admin account. The Create User process would then create a normal non-priv user account as well as an admin priv account.

I assume I can do this with PowerShell. However, I'm really stuck with getting the web interface customized to say "Project Name" instead of Group Name, or creating a Check Box for Create Admin Account Also and getting that information into a PS variable.

Thx!

--Joel

Comments

It would be very cool to be able to access all the commands from business rules or custom commands. It'd be nice to be able to right click an IT worker and select the Create Admin Account custom command.

Answer 1

Update 2019

Starting with Adaxes 2019.1, you can use the Create an Active Directory object action in your business rules, scheduled tasks and custom commands. For details, have a look at the following tutorial: https://www.adaxes.com/tutorials_ActiveDirectoryManagement_CreateMultipleAdObjectsInOneOperation.htm.

Original

Hello,

Is there a way to have a business rule create multiple groups or users? I have a security model that creates 4 groups for a new work project. There is a Project Owner group, a Read/Write access group, a Read Only group and a No Access group.

I'd love to be able to add this to the Self Service portal. I would ask for the Project name, then create the 4x groups based on our naming convention. However, the current Business Rules don't allow for creating new objects, users, groups, etc.

Whenever you need to create new objects in Business Rules, you can always resort to PowerShell scripts. To implement the scenario with project groups, you can create a Home Page Action available on the Web Interface home page. When a user clicks on the Action, they will be presented with only 1 field, where they are supposed to enter the project name.

To pass the project name to the script, the Action will store the entered project name in one of attributes of the users' own accounts. A Business Rule triggered after modifying the attribute will create the groups based on the entered project name. To pass the entered project name, you can use one of Adaxes virtual attributes that can store text (string) values, for example, CustomAttributetext1. They are not stored in AD, but can be used the same as any other attributes of AD objects. To implement such a solution, you will need to:

• Create a Home Page Action so that users can input a project name.
• Configure a Business Rule to create the groups based on the project name.
• [Optionally] Give the attribute your own display name.

i. Create a Home Page Action

To enable users to input a project name, you need to create a Home Page Action that allows them to edit a certain attribute of their own accounts. The attribute will be used to pass the project name to the script. For information on how to create such a Home Page Action, see section ​Modify Object​ in the following tutorial: http://www.adaxes.com/tutorials_WebInte ... htm#modify. Use the section as a guide.

• On ​Step 1 of the section, select ​Modify User​.
• Since users are going to modify their own accounts via this Home Page Action, on ​Step 3​ of the section, select ​Always perform for the current user​.
• Also, you need to customize the form used by the Home Page Action. On the form, you need to leave only one field that will be used to input the project name. For detailed instructions, see ​Step 4​ of the section.

​ii. Configure a Business Rule

To configure a Business Rule to create the necessary groups:

1. Create a new Business Rule.

2. On the ​2nd​ step of the Create Business Rule wizard, select ​User​ and ​After ​Updating a User​.
   

3. On the ​3rd​ step, add the ​Run a program or PowerShell script action and paste the following script in the Script field.
   

    $ouDN = "OU=Groups,OU=Projects,DC=example,DC=com" # TODO: modify me
    $propertyName = "adm-CustomAttributeText1" # TODO: modify me
    [Softerra.Adaxes.Interop.Adsi.ADS_GROUP_TYPE_ENUM]$groupType = "ADS_GROUP_TYPE_GLOBAL_GROUP, ADS_GROUP_TYPE_SECURITY_ENABLED" # TODO: modify me
   
    # Function to create groups
    function CreateGroup($ouDN, $name, $description, $displayName, $sAMAccountName, $groupType)
    {
        $ou = $Context.BindToObjectByDN($ouDN)
        $group = $ou.Create("group", "CN=$name")
        $group.Put("description", $description)
        $group.Put("displayName", $displayName)
        $group.Put("sAMAccountName", $sAMAccountName)
        $group.Put("groupType", [int]$groupType)
        $group.Put("managedBy", $ownerDN)
        $group.SetInfo()
        $groupSid = $group.Get("objectSid")
    }
   
    # Get project name
    $value = $Context.Initiator.UserAdsObject.Get($propertyName)
   
    # Create group for Project Owners
    $groupReviewersSid = CreateGroup $ouDN "$value - Project Owners"`
    "$value - Project Owners" "$value - Project Owners"`
    "$value-PO" $groupType
   
    # Create group for Read/Write access
    $groupReviewersSid = CreateGroup $ouDN "$value - RW Access"`
    "$value - RW Access" "$value - RW Access"`
    "$value-RW" $groupType
   
    # Create group for Read-Only access
    $groupReviewersSid = CreateGroup $ouDN "$value - RO Access"`
    "$value - RO Access" "$value - RO Access"`
    "$value-RO" $groupType
   
    # Create group for No access users
    $groupReviewersSid = CreateGroup $ouDN "$value - Access Denied"`
    "$value - Access Denied" "$value - Access Denied"`
    "$value-NA" $groupType
   
    # Clear the custom attribute
    $Context.Initiator.UserAdsObject.Put($propertyName, $NULL)
    $Context.Initiator.UserAdsObject.SetInfo()

4. In the script, modify the following to match your requirements:

   • $ouDN - specifies the Distinguished Name (DN) of the OU where the groups will be created,
   • $propertyName - specifies the LDAP name of the property that will be used to pass the project name to the script,
   • $groupType - specifies the group type. For a complete list of the possible values, see ADS_GROUP_TYPE_ENUM.

5. Enter a short description for the script and click ​OK​.

6. Now, you need to specify when the script will be run. For this purpose, you need to add conditions. Right-click the action that you've just added and click ​Add Condition​.
   

7. Select the ​If <property> changed​ condition type.

8. Specify ​If ​CustomAttributeText1 has changed, where CustomAttributeText1 is the name of the property that will be used to pass the project name.
   

9. Click ​OK​.

10. Right-click the action and click Add Condition again.

11. Select the If <property> <relation> <value> condition type.

12. Specify If CustomAttributeText1 is not empty, where CustomAttributeText1 is the name of the property that will be used to pass the project name.
    

13. Click ​OK​.

14. Finish creation of the Business Rule.

iii. Give the property your own display name (optional)

Since a name like CustomAttributeText1 will not tell much to your users about the function and the meaning of the field, you'll probably want to give it your own name. For information on how to do that, see the following help article: http://www.adaxes.com/help/?HowDoI.Mana ... Names.html.

Comments

Hello Joel,

A similar scenario is one where a user IT Admin comes on board. It would be nice to have a Check Box for an Admin account. The Create User process would then create a normal non-priv user account as well as an admin priv account.

It would be very cool to be able to access all the commands from business rules or custom commands. It'd be nice to be able to right click an IT worker and select the Create Admin Account custom command.

This is also easy to achieve. You can use the IADsContainer::CopyHere method supported by all AD containers (including OUs) to make a copy the non-privileged account of an admin, and then add the account to the administrator groups etc with the help of Business Rules triggered after creating a new user. The following sample script copies an account on which a Custom Command, Scheduled Task or Business Rule is executed to the OU specified by $targetOUDN:

$targetOUDN = "OU=Users,DC=domain,DC=com" # TODO: modify me

# Bind to the target OU
$targetOU = $Context.BindToObjectByDN($targetOUDN)

# Copy user
$userRdn = "CN=admin-%name%"
$user = $targetOU.CopyHere($Context.TargetObject.AdsPath , $userRdn)

# change sAMAccountName and userPrincipalName
$user.Put("sAMAccountName", "admin-%sAMAccountName%")
$user.Put("userPrincipalName", "admin-%userPrincipalName%")

$user.SetInfo()

To create administrator accounts for already existing users, you can create a Custom Command that runs the script for the user account on which the Command is executed. For information on how to create Custom Commands, see the following tutorial: http://www.adaxes.com/tutorials_ActiveD ... ommand.htm. To run a script as a part of a Custom Command, you need to add the Run a program or PowerShell script action on step 4 of the tutorial.

To allow selecting whether it is necessary to create an administrator account for new users, you can add a boolean attribute to the page that is used for creating new users. The attribute will be used as a flag to indicate whether it is necessary to create an administrator account. For information on how to add a field to the page for creating new users, see step 6 of the following tutorial: http://www.adaxes.com/tutorials_WebInte ... tomization. As soon as you add a boolean attribute to the page, you'll need to specify how it will be displayed on the page. You can select to display the attribute as a checkbox for convenience.

As for an attribute that you can use as a flag, you can use one of Adaxes custom attributes that can store boolean (true/false) values, for example, CustomAttributeBoolean1. This attribute is not stored in AD, but can be used the same as any other attributes of AD objects.

To automatically create administrator accounts for users who have the attribute set to True, you need to configure a Business Rule that will execute the Custom Command for new administrative accounts. To configure such a Business Rule:

1. Create a new Business Rule.
2. On step 2 of the Create Business Rule wizard, select User and After Creating a User.
   
3. On step 3, add the Execute a Custom Command action and click Select.
   
4. Select the Custom Command that you've created for enabling administrative accounts.
5. Click OK.
6. Right-click the action you've just added and click Add Condition.
   
7. Select the If <property> <relation> <value> condition.
8. Specify If CustomAttributeBoolean1 equals True, where CustomAttributeBoolean1 is the boolean attribute that is used as a flag to mark administrative accounts.
   
9. Click OK and finish creation of the Business Rule.

---

Thanks, that works in my lab!

One thing I noticed though, is that when a script creates a group in AD, that doesn't appear to trigger a business rule that looks for newly created groups, specifically the built-in "Set Owner of Group" rule.

Is there a way to trigger a business rule from a script?

---

Hello Joel,

Yes, for this purpose, find the following line in the script:
$ou = $Context.BindToObjectByDN($ouDN)

and replace it with the following:
$ou = $Context.BindToObjectEx("Adaxes://$ouDN", $True)