This article describes the enhanced rights for Security Officers (SO) that are available with SafeGuard LAN Crypt version 126.96.36.199.
In order to obtain this new functionality you must download and apply the patch Patch - SGLC Admin 188.8.131.52
Applies to the following Sophos product(s) and version(s)
SafeGuard LAN Crypt Administration, v 184.108.40.206 and above
All supported operating systems
A short history of SO Rights Management
The SO (Security Officer) security permissions set on groups are only evaluated / only affect users that the group is the parent object to. For users that are only member of the group and where the group is not the parent object, the SO security permissions are not evaluated and the SO does not have permission to perform actions on these users.
This behavior was changed with SGLC Admin 3.61 in order to make the security permission evaluation consistent for all objects (the parent object only evaluation had been partially implemented before).
But in a scenario where an organization synchronizes and administers all their users within the Active Directory, and additionally administers the Security Officer permissions in an “own” hierarchy “outside” the AD hierarchy (e.g. a dedicated Lancrypt User group, which users spread over the AD hierarchy are members of, and where permissions of SOs are set) it is no longer possible for the SO to perform actions (e.g. profile creation) on these users, as the group is not the parent object. The SO can only perform permitted actions on users that have the group as parent object. Users who are only members of a group and have different parent objects are not handled.
New permissions for group members
Currently profile creation and certificate assignment is only allowed if the SO has the rights needed for the parent group of the user. To allow the SOs to also execute these tasks on the groups where a user is just a member, new permissions and group rights are introduced with this patch.
For the new permissions, the user memberships are evaluated instead of thos of the parent group.
- There is a slight difference according to the context in which the task is started.
If an action is initiated from the 'Selected users and certificates' node under central settings, all memberships of the selected user are evaluated.
The operation is allowed:
- If the SO has the right to execute this action on the user’s parent group
- If the SO has the right to execute the action for all members in at least one group where the user is member of.
- If a group is selected and an action is started for this group or for members of this group, only the rights of the user’s parent group and the rights on the currently selected group are evaluated. No rights on other groups, where the user is member of, will be considered.
The new permissions are called 'Create profiles for all Members', 'Assign Certificates to all Members', and 'Copy Users'. They are available as a “global permission” and also as a “group permission”
Create Profiles for all Members
Assign Certificates to all Members
Create Profiles for all Members
Note: As the global permission Create Profiles is a prerequisite for Create Profiles for all Members following applies: Deactivating the permission Create Profiles automatically also deactivates the permission Create Profiles for All Members. Activating the permission Create Profiles for all Members automatically activates the permission Create Profiles
This group right requires that the group right Create Profiles is set. Create Profiles for all Members allows the SO to create profiles for all users in the group: users where the group is the parent group of and also users that are member of the group and have a different parent group.
Note: Setting Create Profiles for All Members to Allow automatically sets Create Profiles to Allow. Setting Create Profiles to deny automatically denies Create Profiles for All Members.
Assign Certificates to all Members
Note: As the global permission Assign Certificates is a prerequisite for Assign Certificates to all Members following applies: Deactivating the permission Assign Certificates automatically also deactivates the permission Assign Certificates to all Members. Activating the permission Assign Certificates to all Members automatically activates the permission Assign Certificates.
This group right requires that the group right Assign Certificates is set. Assign Certificates to all Members allows the SO to assign certificates to all users in the group: users where the group is the parent group of and also users that are member of the group and have a different parent group.
Note: Setting Assign Certificates to all Members to allow automatically sets Assign Certificates to allow. Setting Assign Certificates to deny automatically denies Assign Certificates to all Members.
The SO is allowed to add (copy) users to groups. This global permission is the prerequisite for setting the correct Copy User for a specific group for a SO. To add a user to a group or to copy them into a group, the SO must have the correct Copy User on the parent group of the user.
In earlier versions, it was possible to add users from another group if the SO had the group rights Read and Visible on the parent group of the user. The new rights for profile creation and certificate assignment allow the SO to also execute actions for users that are members of the group but have a different parent group. Given this implementation, an SO may only need Read and Visible on the parent group of an user to be able to add the user to a group, where the SO may have more rights (e.g. Create Profiles for all Members) and could perform actions for that user that may be not allowed on the parent group (e.g. creating profiles). Therefore, adding users to another group will now only be allowed if the new permission and right Copy Users is granted to the SO on the parent group of the user.
Note: After installing this patch it is no longer possible for SOs to add users to another group unless the new permission Copy Users and the group right Copy Users on the user’s parent group are granted to the security officer.
Together with this patch, the VisualBasic-Script GrantCopyUserPermAndRight.vbs is available. This script sets the necessary permissions and group rights for the SOs to be able to copy users from groups as was allowed before installing the patch.
Setting the new permissions is done in the following way:
For each security officer who has the global permissions Administer Groups and Administer Users the rights on all groups are evaluated.
- If the security officer has the rights Read and Visible on a group, the global permission Copy Users is set and the group right Copy Users is granted on the group.
- If the right Read or Visible is denied on a group, Copy Users will also be denied on this group.
The script must be executed as Master Security Officer, in a command prompt using the command cscript.exe GrantCopyUserPermAndRight.vbs.
Modification of users
An SO was previously allowed to modify user properties via the “Members” page of a group, even if the SO did not have the proper rights to administer this user.
After installing the patch it is still possible to open the user properties, but modification of the user data is only possible if the SO has the following rights:
- Global permission Administer Users.
- Add Users and Delete Users on the user’s parent group.
Parent group change if a user is removed from a group
Previously, there was an error when a user was removed from a group. The parent group of the user was changed in some situations.
Now the assignment to a new parent group works as follows:
- If the user is removed from a group which is not his parent group, just this assignment is removed and the parent group stays unchanged.
- If the user is removed from his parent group, a new parent group will be sought. If the current parent group is an OU or ROOT group, then the new parent group must also be an OU or ROOT group. If the current parent group is not an OU or ROOT group, the new parent group can be of any kind.
If no new parent group is available for the user, the user is deleted.
It is possible to set a new registry key to change this behaviour:
- If this value is set to 1, a user will always be deleted if he is removed from his parent group
- If the value is set to 0 or not present, a new parent group is sought, as described above.