Attribute rights on creation

Question

Hello again,

I created granular rights for users and allowed only specific attributes to be written.

In the webGUI, the edit works fine, the fields without write rights are grayed. But, when I create a user those fields are not grayed and the attribute are stored in the AD.

Is there a way to fully deny access to those attributes without removing those from the create form?

Thank you in advance

Answer 1

Hello,

The same as in Active Directory, in Adaxes, users who have the permission to create an object of a specific type are also allowed to write any properties of the objects being created, and such behavior is by design.

To workaround this, you have two options:

1. As you've already mentioned, you can remove the fields that you do not want users to be able to edit from the form for creating objects of the respective types. For details on how to do this, see the following tutorial: http://www.adaxes.com/tutorials_WebInte ... diting.htm.

2. Alternatively, you can check with Business Rules, which properties are set for new objects and disallow creating objects if the user specifies some properties that they are not allowed to edit. To implement such a solution:

   • Create a new Business Rule.
   • On the 2nd step of the Create Business Rule wizard, select the object, creation of which you would like to check, and then select a Business Rule type that is triggered before creating objects of the selected type. For example, if you want to check, which properties are set for new users, select User and Before Creating a User.
     
   • On the 3rd step, add the Cancel this operation action. This will allow canceling creation of the objects of the selected type when certain conditions are met.
     
   • Click OK.
   • Double-click Always.
   • In the dialog box that appears, select the If <property> <relation> <value> condition type.
   • In the <property> drop-down list, select the property that you would not like users to be able to set.
   • Select is not empty and click OK.
     
   • Also, you can add additional conditions to prevent modification of the properties only in certain cases. For example, if you would like only members of the Help Desk group to be able to specify telephone numbers for users, you can add a condition to cancel the operation only when the operation initiator is not a member of the Help Desk group. For this purpose, click the Add Condition button.
     
   • Select the If initiator is a member of <Group> condition.
   • Select the is not condition operator.
   • Click Select Group and select the Help Desk group.
     

Comments

Thank you for this input!

Is there a way through the SDK to check if a user has write rights on a specific attribute? (something like $targetOU.ObjectTypesAllowedToCreate in Check role in Before User creation event)

If yes I will consider writting a little script that will run after user creation and do those check.

---

Hello,

Even when using scripts, you will encounter the same issue: you cannot check permissions for an object before the object is actually created. The only workaround that we can suggest is to allow creating a user anyway and checking the permissions after actual creation as follows:

1. A user is created in Active Directory, and all the properties specified are set for the new user account.
2. A Business Rule is triggered after user creation and checks with the help of a script whether the operation initiator can modify the properties that the initiator specified for the new user.
3. If the initiator does not have sufficient permissions to edit any of the properties, the properties are removed by the script.

If this solution is OK with you, we will provide you with details and the script required to implement it.

---

That would be a great solution!

Thank you a lot

---

To implement such a solution, you need to create a Business Rule executed after creating an object. The Business Rule will launch a PowerShell script to find and clear all the properties that the user cannot modify. To create such a Business Rule:

1. Create a new Business Rule.

2. On the 2nd step of the Create Business Rule wizard, select the object type, creation of which you would like to check, and then select a Business Rule type that is triggered after creating objects of the selected type. For example, if you want to check, which properties are set for new users, select User and After Creating 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.
   

    $propertiesToCheck = @('description', 'manager') # TODO: Modify me
   
    # Get the properties that the user can modify
    $pipelinedTargetObject = $Context.TargetObject.AsPipelined()
    $comparer = [System.StringComparer]::OrdinalIgnoreCase
    $allowedToModifyProperties = New-Object "System.Collections.Generic.HashSet[System.String]" $comparer
    foreach ($propertyName in $pipelinedTargetObject.PropertiesAllowedToModify)
    {
        $allowedToModifyProperties.Add($propertyName) | Out-Null
    }
   
    # Remove the properties that the user cannot modify
    $removedProperties = New-Object "System.Collections.Generic.List[System.String]"
    foreach ($propertyName in $propertiesToCheck)
    {
        if ($allowedToModifyProperties.Contains($propertyName))
        {
            continue
        }
   
        # Check whether the property is set for the target object
        try
        {
            $Context.TargetObject.Get($propertyName)
        }
        catch
        {
            # Property is not set
            continue
        }
        $removedProperties.Add($propertyName)
        $Context.TargetObject.Put($propertyName, $NULL)    
    }
    if ($removedProperties.Count -ne 0)
    {
         $Context.TargetObject.SetInfo()
         $messageBuilder = New-Object "System.Text.StringBuilder"
         $messageBuilder.Append("The following properties were cleared because you are not allowed to modify them: ")
         $friendlyNamesCache = [Softerra.Adaxes.Directory.AttributeFriendlyNamesCache]::GetInstance([System.Globalization.CultureInfo]::CurrentUICulture)
         for ($i = 0; $i -lt $removedProperties.Count; $i++)
         {
             $propertyFriendlyName = $removedProperties[$i]
             if ($friendlyNamesCache.HasFriendlyName($propertyFriendlyName))
             {
                 $propertyFriendlyName = $friendlyNamesCache.GetFriendlyName($propertyFriendlyName, $Context.TargetObject.Class)
             }
             $messageBuilder.Append($propertyFriendlyName)
             if ($i -lt ($removedProperties.Count - 1))
             {
                 $messageBuilder.Append(", ")
             }
         }
         $Context.LogMessage($messageBuilder.ToString(), "Warning") 
    }
   

4. The script will check if the user has sufficient permissions to modify the properties specified in $propertiesToCheck. If necessary, modify the list of properties to your requirements. The properties need to be specified by their LDAP names.

---

Thank you very much, this was very helpful! You did this really quick as well!

For my code I needed to check every attribute but a few exceptions (samAccount & upn are generated dynamically, the support has no rights on it); here is the final code implementing that (I changed the first lines only):

$exclusion=@("objectClass","samAccountName","userPrincipalName","pwdLastSet","adm-CanNotChangePassword")
$propertiesToCheck=@()
for($i=0;$i -lt $Context.Action.PropertyList.PropertyCount;$i++){
    $propertyName=$Context.Action.PropertyList.Item($i).Name
    if($exclusion -notcontains $propertyName) {
        $propertiesToCheck+=$propertyName
    }
}

# Get the properties that the user can modify
$pipelinedTargetObject = $Context.TargetObject.AsPipelined()
$comparer = [System.StringComparer]::OrdinalIgnoreCase
$allowedToModifyProperties = New-Object "System.Collections.Generic.HashSet[System.String]" $comparer
foreach ($propertyName in $pipelinedTargetObject.PropertiesAllowedToModify)
{
    $allowedToModifyProperties.Add($propertyName) | Out-Null
}

# Remove the properties that the user cannot modify
$removedProperties = New-Object "System.Collections.Generic.List[System.String]"
foreach ($propertyName in $propertiesToCheck)
{
    if ($allowedToModifyProperties.Contains($propertyName))
    {
        continue
    }

    # Check whether the property is set for the target object
    try
    {
        $Context.TargetObject.Get($propertyName)
    }
    catch
    {
        # Property is not set
        continue
    }
    $removedProperties.Add($propertyName)
    $Context.TargetObject.Put($propertyName, $NULL)    
}
if ($removedProperties.Count -ne 0)
{
     $Context.TargetObject.SetInfo()
     $messageBuilder = New-Object "System.Text.StringBuilder"
     $messageBuilder.Append("The following properties were cleared because you are not allowed to modify them: ")
     $friendlyNamesCache = [Softerra.Adaxes.Directory.AttributeFriendlyNamesCache]::GetInstance([System.Globalization.CultureInfo]::CurrentUICulture)
     for ($i = 0; $i -lt $removedProperties.Count; $i++)
     {
         $propertyFriendlyName = $removedProperties[$i]
         if ($friendlyNamesCache.HasFriendlyName($propertyFriendlyName))
         {
             $propertyFriendlyName = $friendlyNamesCache.GetFriendlyName($propertyFriendlyName, $Context.TargetObject.Class)
         }
         $messageBuilder.Append($propertyFriendlyName)
         if ($i -lt ($removedProperties.Count - 1))
         {
             $messageBuilder.Append(", ")
         }
     }
     $Context.LogMessage($messageBuilder.ToString(), "Warning") 
}

One last tiny question remains; is it possible to remove the checkbox password never expires and so on from the create mask? Thanks to the granular authorization I was able deny rights on those features (those are grayed in password reset mask) but it is still possible to set it when the user is created.

If not, this is not an issue at all; I will implement a condition that cancel the user creation if "password never expires" is checked.

---

Hello,

Currently it is impossible to remove only some of the Account Options from a Web Interface form, it is only possible to remove the Account Options property completely. We have such a feature in our TODO list. If you apply the same Account Options to all newly created users, you can use the following workaround: you can remove the Account Options property from the form used for user creation, and also create a Property Pattern to set default Account Options for newly created users. Since the Account Options property will not be present on the form for user creation, users will not be able to change the default options, thus the default Account Options will be applied to all new users.

On how to modify the form for user creation, see Customize Forms for User Creation and Editing: http://www.adaxes.com/tutorials_WebInte ... diting.htm. In step 6 you will find information on how to remove a particular field from the form.

On how to set default Account Options for new users, see Set Default Account Options for New Users: http://www.adaxes.com/tutorials_Simplif ... gUsers.htm.