NOTE: As long as an account definition for an employee is valid, the employee retains the user account that was created by it. If the account definition assignment is removed, the user account that was created from this account definition, is deleted.
To delete a user account
- Select the SharePoint > User accounts (group authenticated) or the SharePoint > User accounts (user authenticated) category.
- Select the user account in the result list.
- Click
to delete the user account.
- Confirm the security prompt with Yes.
To restore a user account
- Select the SharePoint > User accounts (group authenticated) or the SharePoint > User accounts (user authenticated) category.
- Select the user account in the result list.
- Click
in the result list.
When an authentication object assigned to a SharePoint user account is deleted from the One Identity Manager database, the link to the authentication object is removed from the SharePoint user account. Define a custom process to delete these user accounts from the One Identity Manager database.
Configuring deferred deletion
You can use deferred deletion to specify how long the user accounts remain in the database after deletion is triggered before they are finally removed. By default, user accounts are finally deleted from the database after 30 days. First, the user accounts are disabled or blocked. You can reenable the user accounts up until deferred deletion runs. After deferred deletion is run, the user accounts are deleted from the database and cannot be restored anymore.
You have the following options for configuring deferred deletion.
-
Global deferred deletion: Deferred deletion applies to user accounts in all target system. The default value is 30 days.
In the Designer, enter a different value for deferred deletion in the Deferred deletion [days] property of the SPSUser table.
-
Object-specific deferred deletion: Deferred deletion can be configured depending on certain properties of the accounts.
To use object-specific deferred deletion, in the Designer, create a Script (deferred deletion) for the SPSUser table.
Example:
Deferred deletion of privileged user accounts is 10 days. The following Script (deferred deletion) is entered in the table.
If Not $IsPrivilegedAccount:Bool$ Then
End If
For more information on editing table definitions and configuring deferred deletion in the Designer, see the One Identity Manager Configuration Guide.
NOTE: SharePoint user accounts cannot be locked. A user account marked for deletion remains enabled until deferred deletion has expired and the user account is finally deleted from the One Identity Manager database.
Lock the user account linked to the SharePoint user account as authentication object to prevent a user from logging into a site when the SharePoint user account is marked for deletion.
User accounts inherit SharePoint permissions through SharePoint roles and SharePoint groups. SharePoint groups are always defined for one site collection in this way. SharePoint roles are defined for sites. They are assigned to groups, and the user accounts that are members of these groups inherit SharePoint permissions through them. SharePoint roles can also be assigned directly to user accounts. User account permissions on individual sites in a site collection are restricted through the SharePoint roles that are assigned to it.
Terms
- A SharePoint Role is the permission level linked to a fixed site.
- The assignment of SharePoint permissions to a permission level is called a role definition.
- The assignment of user account or groups to a SharePoint role is called a role assignment.
Child sites can inherit permissions from the sites that the user accounts have on those sites. Every root site of a site collection or every site that has a child site. This permits the following scenarios:
- The child site inherits role definitions and role assignments.
The permission levels and role definitions are valid as well as the role assignments from the parent (inheritance) site. User and groups cannot be explicitly authorized for the site. Only user accounts that have permissions for the parent (inheritance) site have access to the site.
- The child site inherits the role definitions and role assignments.
You cannot define unique permission levels for child site. The SharePoint roles for this site reference the permission levels of the parent (inheritance) site and its role definitions. User accounts and groups can be assigned to the SharePoint roles of the child site based on this. If there are unique permission levels defined for the child site the permissions are overwritten by the inherited permissions.
- The child site does not inherit role definitions or role assignments.
In this case unique permission levels with their role definitions can be added in the same way as the root site. The SharePoint roles based on the definitions are assigned to user accounts and groups.
Figure 2: SharePoint user accounts inheriting SharePoint permissions in One Identity Manager
You can use groups in SharePoint to provide users with the same permissions. Groups that you add for site collections are valid for all sites in that site collection. SharePoint roles that you define for a site are assigned directly to groups. All user accounts that are members of these groups obtain the permissions defined in the SharePoint roles for this site.
You can edit the following group data in the One Identity Manager:
- Object properties like display name, owner, or visibility of memberships
- Assigned SharePoint role and user accounts
- Usage in the IT Shop
- Risk assessment
- Inheritance through roles and inheritance restrictions
To edit group main data
- Select the SharePoint > Groups category.
- Select the group in the result list. Select the Change main data task.
- OR -
Click 
in the result list.
- Enter the required data on the main data form.
- Save the changes.
Detailed information about this topic
Related topics
Table 25: Configuration parameters for setting up SharePoint groups
| QER | CalculateRiskIndex |
Preprocessor relevant configuration parameter controlling system components for calculating an employee's risk index. Changes to the parameter require recompiling the database.
If the parameter is enabled, values for the risk index can be entered and calculated. |
Enter the following main data of a group.
Table 26: SharePoint group main data
| Display name |
Display name of the group. |
| Site collection |
Site collection the group is used in. |
| Owner |
Owner of the group. A SharePoint user account or a SharePoint group can be selected. |
| Service item |
Service item data for requesting the group through the IT Shop. |
| Distribution group alias |
Alias of the distribution group that the group is linked to. |
| Distribution group email |
Email address of the distribution group that the group is linked to. |
| Risk index |
Value for evaluating the risk of assigning the group to user accounts. Set a value in the range 0 to 1. This input field is only visible if the QER | CalculateRiskIndex configuration parameter is activated. |
| Category |
Categories for group inheritance. Groups can be selectively inherited by user accounts. To do this, groups and user accounts are divided into categories. Select one or more categories from the menu. |
| Description |
Text field for additional explanation. |
| Description (HTML) |
Additional information about the group in HTML format. (this is displayed in SharePoint in the description field "About me"). |
| Memberships only visible to members |
Specifies whether only group members can see the list of members. |
| Group members can edit memberships |
Specifies whether all group members can edit the group memberships. |
| Request for membership permitted |
Specifies whether SharePoint users can request or end membership in these groups themselves. |
| Automatic membership on request |
Specifies whether SharePoint users automatically become members in the group once they request membership. The same applies when user end their membership. |
| Email address membership requested |
Email address that the group membership request or closure is sent to. |
|
IT Shop |
Specifies whether the group can be requested through the IT Shop. If this option is set, the group can be requested by the employees through the Web Portal and distributed with a defined approval process. The group can still be assigned directly to hierarchical roles. |
|
Only for use in IT Shop |
Specifies whether the group can only be requested through the IT Shop. If this option is set, the group can be requested by the employees through the Web Portal and distributed with a defined approval process. Direct assignment of the group to hierarchical roles or user accounts is not permitted. |
Detailed information about this topic
