0 votes

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

by (750 points)

1 Answer

0 votes
by (216k points)

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.
0

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.

0

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.

0

That would be a great solution!

Thank you a lot

0

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.

0

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.

0

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.

Related questions

0 votes
1 answer

Hi, I am currently working on an interface that allows our HR tool to create users in Adaxes. I got the whole thing to work up to that point where I want user creation to be ... it obviously won't find the user as it has not yet been created at that point...

asked Dec 10, 2018 by Yannik (100 points)
0 votes
1 answer

how can i create a report which gives me the details from an exchange mailbox as described in the subject? I would like to have a Report for Exchange Mailboxes with OU, Send on Behalf, Full Rights and Send As Rights thank you

asked Feb 22, 2021 by m_st (200 points)
0 votes
1 answer

Dear Support, how am I able to use that powershell command: Add-MailboxFolderPermission -Identity $Mailbox":\Kalender" -User $Benutzer -AccessRights $AccessType I want set on the calendar of the user the permission modify for a group. Thanks,

asked Aug 20, 2013 by Napoleon (700 points)
0 votes
1 answer

Hello, When a user account is created, we would like for that user to be added to a group whose name is based on a certain naming convention. If the group doesn't yet exist ... If that group doesn't exist, it will first create the group and then add the user.

asked Mar 11 by sjjb2024 (60 points)
0 votes
1 answer

I need a group created based on %ipPhone% when ever a new user is provisioned. The group name has to match %ipPhone% and have email enabled and to be hidden from the address list. We are on Version 3.8.314823.0

asked Nov 6, 2018 by hgletifer (1.3k points)
3,410 questions
3,105 answers
7,900 comments
545,798 users