Modifying Scripts for Automatic Employee Assignment
Modifying Scripts for Automatic Employee Assignment
Automatic employee assignments are controlled through scripts. These scripts, in ‘SEARCH’ mode, assign existing employees to user accounts depending on defined search criteria. Furthermore, the scripts, in ‘CREATE’ mode, define properties which are initialized when a new employee is created. These scripts are implemented in a default One Identity Manager installation for each target system type. The name of this script is:
<target system type>_PersonAuto_Mapping_<account type>
where:
<target system type> = short name of the addressed target system type
<account type> = Table containing the user accounts
|
|
TIP: You can customize scripts to extend search criteria for automatic employee assignment or the properties of new employees. The scripts can be overwritten. To do this, create a copy of the existing script and customize the copy. |
When automatic employee assignment is carried out in "CREATE" mode, some of the properties of the user account are passed on to the new employee object. Initializing the employee properties is done using the script "VI_PersonAuto_<targetsystem>". Initializing the properties when an employee is being created for a user account is done by evaluating the entry in the table DialogNotification. In this table the connected properties are mapped as a bidirectional pair through the formatting rules. Evaluation of entries in DialogNotification are exemplified in the following by showing initialization of an employee’s surname:
Example:
The last name of an Active Directory user account is made up of the surname of the employee.
Value template for ADSAccount.Surname:
Value = $FK(UID_Person).Lastname$
If the employee’s surname changes, the last name of the Active Directory user changes, too. The column Person.Lastname is therefore the sender and the column ADSAccount.Surname is the receiver.
Relationship as in the table Dialognotification:
Person.Lastname -- > ADSAccount.Surname
The table DialogNotification can be used to help with the initialization of the properties for a new employee in that the relationships can be removed in reverse. The surname of an employee can be replaced with the surname of the Active Directory user. Thus, certain presets for the employee object can be automatically generated. However, only explicit relationships can be removed.
Example:
The display name of an Active Directory user account should be made up of the surname and the first name of an employee.
Relationships as in the table DialogNotification:
Person.Lastname -- > ADSAccount.Displayname
Person.Firstname -- > ADSAccount.Displayname
The Person.Firstname and Person.Lastname cannot be determined from the ADSAccount.Displayname, since this is a compound value.
In order to make mapping of employee properties to user account properties easier, the script VI_PersonAuto_GetPropMappings can be used. This script evaluates the relationship of the properties as used in the table DialogNotification. The script creates a VB.Net script code and the possible assignments, when it is run by the System Debugger. This code can subsequently be inserted into the script <target system type>_PersonAuto_Mapping_<account type>.
Example Version of a VI_PersonAuto_GetPropMappings Script
' PROPERTY MAPPINGS ADSAccount - Person
' ADSAccount.Initials -- > Person.Initials
' ADSAccount.Department -- > Person.UID_Department
...
Try
Person("Initials").NewValue = Acc.GetValue("Initials").String
Catch ex As Exception
End Try
Try
Person("UID_Department").NewValue = Acc.GetValue("Department").String
Catch ex As Exception
End Try
...
Disabling and Deleting Employees and User Accounts
How employees are handled, particularly in the case of permanent or partial withdrawal of an employee, varies between individual companies. There are companies that never delete employees, and only disable them when they leave the company. Other firms delete the employee, but only after they have ensured that all the user accounts are removed.
How employees are handled when they are disabled or deleted depends on the type of user account management. The following scenarios apply:
- User accounts are linked to employees and managed through account definitions.
- User accounts are linked to employees. No account definition is applied.
The following methods are available in the One Identity Manager standard version:
- Temporarily Deactivating Employees
- Permanently Deactivating Employees
- Deferred Deletion of an Employee
- Disabling and Deleting Account Definitions
Temporarily Deactivating Employees
Temporarily Deactivating Employees
The employee has temporarily left the company and is expected to return at a predefined date. The desired course of action could be to disable the user account and remove all group memberships. Or the user accounts could be deleted and reestablished with the employee’s return, even if it is with a new system identification number (SID).
Temporary disabling of an employee is triggered by:
- The option Temporary disabled
- The start and end date for deactivation (Temporary disabled from and Temporary disabled until)
|
|
NOTE: Configure and enable the schedule "Lock accounts of employees that have left the company" in the Designer. This schedule checks the start date for disabling and sets the option Temporarily disabled when it is reached. |
|
|
NOTE: Configure and enable the schedule "Enable temporarily disabled accounts" in the Designer. This schedule monitors the end date of the disabled period and enables the employee with their user accounts when the date expires. Employee's user accounts that were disabled before the period of temporary absence are also re-enabled once the period has expired. |
Scenario: user accounts are linked to employees and are managed through account definitions.
- Specify in the account definitions, how temporary disabling of an employee affects the user account.
Scenario: user accounts are linked to employees. No account definition is applied.
- Specify which behavior you require with configuration parameter "QER\Person\TemporaryDeactivation". If the configuration parameter is set, the employee’s user accounts are locked if the employee is permanently or temporarily disabled. If the configuration parameter is not set, the employee’s properties do not have any effect on the associated user accounts.
Related Topics
Permanently Deactivating Employees
Permanently Deactivating Employees
Employees can be disabled permanently when, for example, they leave the company. It might be necessary, to remove access to this employee’s entitlements in connected target systems and their company resources.
Effects of permanent disabling of an employee are:
- The employee cannot be assigned to employees as a manager.
- The employee cannot be assigned to roles as a supervisor.
- The employee cannot be assigned to attestation policies as an owner.
- There is no inheritance of company resources through roles, if the additional option No inheritance is set for an employee.
- Employee user accounts are locked or deleted and then removed from group memberships.
Trigger permanent disabling through:
- The task Disable employee permanently
This task ensures that the option Permanently disabled is set and leaving date and the last day of work are set to the current date.
- Leave date reached
NOTE: Configure and enable the schedule "Lock accounts of employees that have left the company" in the Designer. This schedule regularly checks the leaving date and sets the option Permanently disabled on reaching the date. NOTE: The task Re-enable employee ensures that the employee is re-enabled. - Certification status "Denied"
An employee is permanently disabled when their certification status is set to "Denied" either through attestation or manually. If the employee's certification status is changed to "certified", the employee is activated again.
NOTE: This function is only available if the Attestation Module is installed.
Scenario: user accounts are linked to employees and are managed through account definitions.
- Specify in the account definitions, how temporary disabling of an employee affects the user account.
Scenario: user accounts are linked to employees. No account definition is applied.
- Specify which behavior you require with configuration parameter "QER\Person\TemporaryDeactivation". If the configuration parameter is set, the employee’s user accounts are locked if the employee is permanently or temporarily disabled. If the configuration parameter is not set, the employee’s properties do not have any effect on the associated user accounts.