How to change the group type before the action?

Question

Dear Support

We have a business rule in the old Adaxes 2017 that was working: Before adding a universal security group to a global security group, the group type of the target group is changed to universal.

In the current Adaxes 2021, however, universal groups are no longer displayed during the target group selection if the target group is global. This makes the business rule redundant.

Is there a way to change the target group type from Global to Universal before adding a universal group to a global group?

<br> Our action: Best regards Johann

Answer 1

Hello Johann,

Unfortunately, there is no such possibility as Adaxes follows group membership criteria defined in AD. It means that if you select a member, on the next step you will see groups according to the logged on user permissions in Adaxes and according to the AD membership rules. For details, have a look at section Group scopes of the following Microsoft article: https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/active-directory-security-groups#group-scope.

As a workaround, you can use a custom command with an AD object picker parameter. The command will be executed on a global group and the parameter will be used to select the members. In the command itself, there will be an action changing it to universal and then a script adding selected members to the group.

Comments

Good morning,

Thanks for the quick answer. The workaround sounds like a good option. We have no experience with the Object picker yet. Can you give me more details about the workaround, or are there examples for the two steps already? Many thanks in advance Johann

---

Johann,

Thank you for your patience. Actually, it will be more convenient to configure the workflow using a single script executed in a custom command. The command should be executed on a group where you want to add new members. It will have an AD object picker parameter where you will be able to select new members. If any of the new members are universal groups, the scope of the target group will be changed to universal. To implement the workflow, you need several things:

Create a custom command

1. Create a custom command for Group object type.

2. On step 3 of the Create Custom Command wizard, add an AD object picker parameter to the command. You can configure the parameter to limit which groups can be selected as members. For example, to allow selecting only group objects located under the IDM-Managed-Groups OU, specify the OU and the corresponding LDAP filter in the Object Selection Parameters dialog. Also, make sure that the Allow multiple selection checkbox is enabled.

3. After configuring the settings for object selection, specify a character that will be used as a separator for multiple parameter values (e.g. ;). Important: do not use the comma (,) character and English letters as they are used in distinguished names, hence the parameter value will be incorrectly parsed in the script.

4. On step 4 of the Create Custom Command wizard, add a Run a program or PowerShell script action and paste the following script into the Script field. In the script:

   • $memberDNsParameterName – specifies the name of the AD object picker parameter you added.
   • $separator – specifies the separator character you selected on step 3.
   • $pipelined – specifies whether the membership update should be performed via Adaxes pipeline i.e. if set to $True, all applicable business rules will trigger after adding a member to a group, log records for adding group members will be created, etc.

$memberDNsParameterName = "param-members" # TODO: modify me
$separator = ";" # TODO: modify me
$pipelined = $True # TODO: modify me

# Get parameter value
$memberDNsParameterValue = $Context.GetParameterValue($memberDNsParameterName)
$memberDNs = $memberDNsParameterValue.Split($separator)

# Get target group type
$targetGroup = $Context.BindToObjectEx($Context.TargetObject.AdsPath, $pipelined)
$targetGroupType = $targetGroup.Get("groupType")
$isTargetGroupUniversal = $targetGroupType -band [Softerra.Adaxes.Interop.Adsi.ADS_GROUP_TYPE_ENUM]::ADS_GROUP_TYPE_UNIVERSAL_GROUP
$targetGroupSecurityEnabled = $targetGroupType -band [Softerra.Adaxes.Interop.Adsi.ADS_GROUP_TYPE_ENUM]::ADS_GROUP_TYPE_SECURITY_ENABLED

# Check if members contains Universal group
foreach ($dn in $memberDNs)
{
    $member = $Context.BindToObjectByDN($dn)
    if (-not($isTargetGroupUniversal) -and 
        $member.Class -eq "group")
    {
        $groupType = $member.Get("groupType")
        if (($groupType -band [Softerra.Adaxes.Interop.Adsi.ADS_GROUP_TYPE_ENUM]::ADS_GROUP_TYPE_UNIVERSAL_GROUP) -and
            -not($isTargetGroupUniversal))
        {
            $targetGroupType = [Softerra.Adaxes.Interop.Adsi.ADS_GROUP_TYPE_ENUM]::ADS_GROUP_TYPE_UNIVERSAL_GROUP -bor $targetGroupSecurityEnabled
            $targetGroup.Put("groupType", [Int32]$targetGroupType)
            try
            {

                $targetGroup.SetInfo()
            }
            catch
            {
                $Context.LogMessage("An error occured while changing the group type. Error: " + $_.Exception.Message, "Error")
                return
            }

            $isTargetGroupUniversal = $True
        }
    }

    try
    {
        $targetGroup.Add($member.AdsPath)
    }
    catch
    {
        $Context.LogMessage("An error occured while adding a member. Error: " + $_.Exception.Message, "Error")
    }
}

5. Finish creating the custom command.

Add the custom command to the Web interface and grant permissions

1. Add the custom command as a Web interface action. For details about configuring Web interface actions, see this tutorial.
2. Grant the permissions to execute the command to your users. For details, see this tutorial.

---

Hello,

Great, thanks for the detailed work! I will try it out as soon as possible.

Have a nice week Johann

---

Hello Support,

I was able to successfully implement the custom command with the picker and parameters.

Thanks for the great help Johann

---

Hello Support

The script runs great, thanks again. I have begun to understand about the parameters and configurations :-)

Unfortunately, I have another problem. In the 2017 version, we had added another business rule to be able to add users from another domain:

If a user from our wobben.br.com domain should be added to a user group of enercon.de the target group must also be changed to a "universal" group.

Do you have any idea, or would we have to do it again with a script? Would you support us with the script if necessary?

Many thanks in advance Johann

---

Hello Johann,

Do you have any idea, or would we have to do it again with a script?

Yes, you will have to use a similar custom command with an AD object picker parameter and a script to configure this workflow.

Would you support us with the script if necessary?

We can update your current script so that it will convert the target group type to Universal if a user from another domain is being added as a member. In this case, you will be able to use the same custom command for adding Universal groups and users from another domain to Global groups.

Alternatively, if you would like to use a separate custom command for adding users to groups, you will need a separate script. Please let us know which approach meets your needs.

---

Thanks for the quick response. I think I would prefer a new custom command with a new script. Would like to try it first.

---

Thank you for clarifying. Here is the script for the new custom command. In the script:

• $memberDNsParameterName – specifies the name of the AD object picker parameter.
• $separator – specifies the separator character for multiple values of AD object picker.
• $pipelined – specifies whether the membership update should be performed via Adaxes pipeline i.e. if set to $True, all applicable business rules will trigger after adding a member to a group, log records for adding group members will be created, etc.

$memberDNsParameterName = "param-members" # TODO: modify me
$separator = ";" # TODO: modify me
$pipelined = $True # TODO: modify me

# Get parameter value
$memberDNsParameterValue = $Context.GetParameterValue($memberDNsParameterName)
$memberDNs = $memberDNsParameterValue.Split($separator)

# Get target group type
$targetGroup = $Context.BindToObjectEx($Context.TargetObject.AdsPath, $pipelined)
$targetGroupType = $targetGroup.Get("groupType")
$isTargetGroupGlobal = $targetGroupType -band [Softerra.Adaxes.Interop.Adsi.ADS_GROUP_TYPE_ENUM]::ADS_GROUP_TYPE_GLOBAL_GROUP
$targetGroupSecurityEnabled = $targetGroupType -band [Softerra.Adaxes.Interop.Adsi.ADS_GROUP_TYPE_ENUM]::ADS_GROUP_TYPE_SECURITY_ENABLED
$targetGroupDomain = $Context.GetObjectDomain("%distinguishedName%")

# Check if new members contain users from other domains
foreach ($dn in $memberDNs)
{
    $memberDomain = $Context.GetObjectDomain($dn)
    if ($isTargetGroupGlobal -and 
        $targetGroupDomain -ne $memberDomain)
    {
        $targetGroupType = [Softerra.Adaxes.Interop.Adsi.ADS_GROUP_TYPE_ENUM]::ADS_GROUP_TYPE_UNIVERSAL_GROUP -bor $targetGroupSecurityEnabled
        $targetGroup.Put("groupType", [Int32]$targetGroupType)
        try
        {
            $targetGroup.SetInfo()
        }
        catch
        {
            $Context.LogMessage("An error occured while changing the group type. Error: " + $_.Exception.Message, "Error")
            return
        }
        $isTargetGroupGlobal = $False
    }

    $path = New-Object Softerra.Adaxes.Adsi.AdsPath $memberDomain, $dn

    try
    {
        $targetGroup.Add($path)
    }
    catch
    {
        $Context.LogMessage("An error occured while adding a member. Error: " + $_.Exception.Message, "Error")
    }
}

You can configure the custom command exactly as the one before, except you need to specify different object selection settings for the AD object picker parameter so that only users can be selected. For your reference, the workflow where you have to change the group scope before adding a member might indicate that there are some issues with how your groups are set up. You might want to review your group structure to avoid such workarounds in the future.

---

Hi Support I have the script in use now in several actions. It works exactly as desired. Thanks a lot for the support. Johann