Using the Maintenance Workflows

Use the Identity Manager to copy the workflow to your scenario (Connectivity → Global View).

Select your scenario (if not yet present, use the target system wizard from the Provisioning view group to create the scenario).

Click the workflow line between the Identity Stores and select New from the context menu.

Select the ProcessTicketsInternal workflow template and then click Next.

Define the Name and Description fields and set the Is Active flag.

Click Next and then Finish to complete the copy operation.

Perform Load IdS-J Configuration to load the workflow into the Java-based Server.

During each run, it checks the status (state and application state) of all request workflows that are associated to tickets.

It sets the state of the ticket accordingly. This means that:

Workflow State=RUNNING: ticket state is not changed

Workflow State=SUCCEEDED and Application State=ACCEPTED: ticket State=Approval.Completed

Workflow State=SUCCEEDED and Application State=REJECTED: ticket State=Approval.Rejected

Workflow State=FAILED.*: ticket State=Approval.Error

It reads all tickets where the due date is reached.

It processes the ticket:

For ticket State=Approval.Completed it actualizes the order data from the workflow instance and then it processes the ticket.

For ticket State=Input.Completed it processes the ticket.

Processing the ticket means that the ticket data is applied to the subject; for example, the service changes some attributes at a user entry or some privilege assignments are assigned to a user.

If necessary, the subject is further processed; for example, a privilege resolution is performed for a user entry to calculate any changes coming from changed attributes or privilege assignments. Other processes might be triggered via JMS messages; for example, real-time provisioning to connected systems.

After successful processing, it sets the ticket State=ApplyChange.Completed. and the DeleteDate=today+TicketLifeTime where Ticket Life Time is the defined value at the domain object.

If an error occurs during processing, it does not change the status.

Use the Identity Manager to copy the workflow to your scenario (Connectivity → Global View).

Select Connectivity → Expert View and then select the copied workflow object.

Select the join activity and then select the Controller tab. Adjust the settings in this tab as follows:

Set the search base to the desired value.

Do not change the scope and filter.

Set the correct Domain (default: My-Company).

Set the parameter Days before Expiration (default: 1 day).

Set the parameter Keep Password History at the Account to true if you want to keep a password history at the account. The history is then used to check if the new password has not been used in the past x times where x is defined by the policy. This history keeping is performed by default for privileged accounts but not otherwise.

Do not change the topic prefix for the "to be built" request that triggers the setPassword workflows.

If you want to use own attributes sent to the setPassword workflow, which uses them for resolving placeholders in it’s Notify activity, right click the join activity and choose Edit Content. Go to the controller section of the PwdAccountExpireController and add the multi-value property accountAttrs with the desired attribute list outside the operation section.

Set the Active flag of the workflow.

Right-click the workflow object and select Load IdS-J Configuration to load the workflow into the Java-based Server.

dxrPwdMaxAge at the password policy, which defines the maximum allowed age of the password.

Days before expire at the join activity, which specifies the time when to reset the account passwords before they expire. If the specified number of days before expiration is reached or passed for an account password, the workflow resets that password.

dxrPwdChangedTime at the account, which specifies the last time the password was changed.

Use the Identity Manager to copy the workflow to your scenario (Connectivity → Global View).

Select Connectivity → Expert View and then select the copied workflow object.

Select the join activity and then select the Controller tab. Adjust the following settings in this tab:

Set the search base to the desired value.

Set the filter accordingly. By default, the workflow selects all objects of type dxrTargetSystemAccount with dxrType=Privileged. Set dxrType=Personal if you intend to handle personal accounts.

Set the correct Domain (default: My-Company).

If you want to use own attributes sent to the setPassword workflow, which uses them for resolving placeholders in its Notify activity, right click the join activity and choose Edit Content. Go to the controller section of the PwdAccountResetController and add the multi value property accountAttrs with the desired attribute list outside the operation section.

Set the Active flag of the workflow.

Right-click the workflow object and then select Load IdS-J Configuration to load the workflow into the Java-based Server.

For a personal account, it reads the password from the user. The password reset flag is set accordingly to the user’s password reset flag.

For a privileged account, it generates a new password and sets it at the account. The password reset flag is set to true.

Use the Identity Manager to copy the workflow to your scenario (Connectivity → Global View).

Select the Reset Password If Displayed workflow

Set the workflow name (Name field).

Set the Is Active flag.

Adapt the workflow timeout (Timeout field).

Assign the resource family, if necessary (Resource family field).

Adapt the Error Handling parameters, if necessary (Timeout, Retry Limit, Wait before Retry fields).

Adapt the parameters for retrieving the privileged accounts (Search Base, Scope, Filter).

Adapt the Hours before Reset parameter.

Set the workflow name, if not yet done in the General Info step (Name field).

If the account has set the attribute dxrPwdPolicyLink, then that policy is used.

Otherwise it looks for the target system’s password policy; that is, the password policy assigned in the target system’s attribute dxrPwdPolicyLink.

If the target system has no password policy assigned and the account has an associated user, it takes the password policy referenced from the user.

If it does not find any password policy, it takes the default password policy of the domain.

If there is no default policy, it generates an error.

Use the Identity Manager to copy the workflow to your scenario (Connectivity → Global View).

Select Connectivity → Expert View and then select the copied workflow object.

Select the join activity and then adjust the settings in the following tabs:

Select the notify part of the join activity and then adjust the settings in the following tabs:

In the General tab of the workflow:

Set the Active flag of the workflow.

Right-click the workflow object and then select Load IdS-J Configuration to load the workflow into the Java-based Server.

Use the Identity Manager to copy the workflow to your scenario (Connectivity → Global View).

Select Connectivity → Expert View and then select the copied workflow object.

Select the join activity and then select the Controller tab. Adjust the settings in this tab as follows:

Set the Number of Notifications to the desired value.

Do not change the selected Join Engine controller PwdUserExpireController unless you have changed the component description PwdUserExpireController.xml of that controller under Expert View → Configuration → GUI → system → componentDescriptions to adjust for example the initial content for the controller’s properties. Those changes would become active then for every newly created workflow.

Right-click the join activity and then select Edit Content if you want to adjust the following properties of the PwdUserExpireController’s controller section:

searchBase - set to *cn=Users,cn=*domain by default, where domain automatically resolves to the domain to which your workflow was copied. Must not be changed usually.

domain - set by default to the domain to which your workflow was copied. It is used for searching the password policies and should not be changed.

userAttrs - the multi value property contains the list of all attributes either the PwdUserExpireController needs to calculate the password expiration date, which are dxrPwdChangedTime and dxrPwdExpiryNotified, or those to be used in ${IDATTR(<attr_name>)} expressions in the mail parameters of the notify port, for example, in the mail body or mail subject. The attributes configured by default are sn, givenName, mail.
If you want to use more attributes, you can extend this multi-value property.

There are two pseudo attributes (not in LDAP) that the PwdUserExpireController automatically adds to the userAttrs list which can also be used in the IDATTR expressions of the mail parameters:
daysToExpire - the number of days after which the user’s password will expire.
expirationDate - the expiration date of the user’s password.

Beneath the join activity, select the notify port, then select the Notification tab and adjust the mail parameters to your needs. The ${IDATTR(<attr_name>)} expressions can be used for any attributes, that are contained in userAttrs.

Set the Active flag of the workflow.

Right-click the workflow object and select Load IdS-J Configuration to load the workflow into the Java-based Server.

dxrPwdMaxAge (Maximum age) - at the password policy. It defines the maximum allowed age of the password.

dxrPwdExpireWarning (Expiration Warning Time) - at the password policy. It defines the time at which to warn about a pending password expiration.

dxrPwdChangedTime (Password Changed Time) - at the user entry. It defines the last time the password was changed.

Use the Identity Manager to copy the workflow to your scenario (Connectivity → Global View).

Make sure your scenario includes an existing ConfDB connected directory from where you want to export. Your scenario should have two instances of this connected directory with an intermediate workflow line between them. Right-click the workflow line and then select New to copy the workflow Export Connectivity Collections.

The first tab asks for a new workflow name. Enter your desired name.

In the General Workflow Info tab, check the Timeout parameter if appropriate and activate the workflow.

In the Connection tab:

Open Bind profile and check the bind profile parameters.

Open Connected directory and follow the link to Service. Check for correct parameters.

In the Export Definitions tab

Define either a search in the Filter area to retrieve a set of Connectivity collections to export (you need not define the object class dxmIDMWorkflow, define only additional criteria) or select a list of Connectivity collections in the Collections area. Note that you can only use one of these options.

Determine whether to create standard LDIF format with Base64 content or use the default readable format. Because readable format works best for configuration management systems and data that must be changed during import transport workflows, we recommend that you keep the default (no standard LDIF format).

If you want to generate data for a configuration management system, restrict the generated line length. Check the configuration management documentation. For ClearCase, we recommend a line length of 2000.

Click Finish to store your new workflow.

Use the Identity Manager to copy the workflow to your scenario (Connectivity → Global View).

Make sure your scenario includes an existing ConfDB connected directory from where you want to export. Your scenario should have two instances of this connected directory with an intermediate workflow line between them. Right-click the workflow line and then select New to copy the workflow Import Connectivity Collections.

The first tab asks for a new workflow name. Enter your desired name.

In the General Workflow Info tab, check the Timeout parameter if appropriate and activate the workflow.

In the Connection tab:

Open Bind profile and check the bind profile parameters for your target connected directory.

Open Connected directory and follow the link to Service. Check for correct parameters.

In the Deletion tab:

Enable the Is Active flag if you intend to delete a set of entries before the import operation.

In the Collection area, list all collection definitions (its DNs) that are to be used to delete the entries.

In the Import Definitions tab:

In the Import area, select all files you want to import.

By default, the files are type LDIF. In the SPML area, you can select SPML format and you can select that the SPML file is to be validated before the import.

Set the required options in the LDIF area; for example, an input filter that retrieves only specific object types from your files.

You can use the dryrun option of the Simulation Mode for a dry run. Use the log file to check the effects.

Click Finish to store your new workflow.

Click the Expert view and locate your workflow in your workflow folder.

Open this entry and then open the perform activity.

All mappings are located under this entry. Either change one of the existing mappings or create or delete mappings.

The sample workflow sets all imported workflows to active and changes the cluster and resource values (as an example).

Use the Identity Manager to copy the workflow to your scenario (Connectivity → Global View).

Make sure your scenario includes an existing Identity Store connected directory from where you want to export. Your scenario should have two instances of this connected directory with an intermediate workflow line between them. Right-click the workflow line and then select New to copy the workflow Export Provisioning Collections.

The first tab asks for a new workflow name. Enter your desired name.

In the General Workflow Info tab, check the Timeout parameter if appropriate and activate the workflow.

In the Connection tab:

Open Bind profile and check the bind profile parameters.

Open Connected directory and follow the link to Service. Check for correct parameters.

In the Export Definitions tab:

Define either a search in the Filter area to retrieve a set of Connectivity collections to export (you need not define the object class dxmIDMWorkflow, define only additional criteria) or select a list of Connectivity collections in the Collections area. Note that you can only use one of these options. To get the DNs of the collection objects, right-click the object in the Provisioning view and then select Goto DataView to retrieve the DN of the object.

Determine whether to create standard LDIF format with Base64 content or use the default readable format. Because readable format works best for configuration management systems and data that needs to be adapted during import transport workflows, we recommend that you keep the default (no standard LDIF format).

If you want to generate data for a configuration management system, restrict the generated line length. Check the configuration management documentation. For ClearCase, we recommend a line length of 2000.

Click Finish to store your new workflow.

Now you can execute the workflow either manually or via a schedule.

Use the Identity Manager to copy the workflow to your scenario (Connectivity → Global View).

Make sure your scenario includes an existing Identity Store connected directory from where you want to export. Your scenario should have two instances of this connected directory with an intermediate workflow line between them. Right-click the workflow line and then select New to copy the workflow Import Provisioning Collections.

The first tab asks for a new workflow name. Enter your desired name.

In the General Workflow Info tab, check the Timeout parameter if appropriate and activate the workflow.

In the Connection tab:

Open Bind profile and check the bind profile parameters for your target connected directory.

Open Connected directory and follow the link to Service. Check for correct parameters.

In the Deletion tab:

Enable the Is Active flag if you intend to delete a set of entries before the import operation.

List in the Collection area all collection definitions (it’s DNs) that shall be used to delete the entries.

In the Import Definitions tab:

In the Import area, select all files you want to import.

By default, the files are type LDIF. In the SPML area, you can select SPML format and you can select that the SPML file is to be validated before the import.

Set the required options in the LDIF area; for example, an input filter that retrieves only specific object types from your files.

You can use the dryrun option of the Simulation Mode for a dry run. Use the log file to check the effects.

Set the correct Domain Mappings. The default workflow changes all occurrences from "My-Company" to "Customer Domain". If you have data from different domains, you can define multiple mappings to your target domain.

Click Finish to store your new workflow.

Click the Expert view and locate your workflow in your workflow folder.

Open this entry and then open the perform activity.

All mappings are located under this entry. Either change one of the existing mappings or create or delete mappings.

The sample workflow deletes all dxrGroupMember attribute values (we use the wildcard dxrGroupMember* here). Only the structure is imported, not the specific group members because these are different in your target domain.

Activate the backup in the Java-based server. (See the section "Java-based Server - Repository" in the appendix "Context Sensitive Help" in the DirX Identity Connectivity Administration Guide for details.)

Administer the LDAP servers: Enter the DNs of the Connectivity Domain Administrator used by IdS-J (cn=DomainAdmin,cn=*your_domain,dxmC=Users,dxmC=DirXmetahub*) and, if necessary, of the Provisioning Domain Administrator used by the IdS-J *(cn=DomainAdmin, cn=*your_domain) in the multi-value attribute ldapExtOpAdmins of the ldapConfiguration subentry of the appropriate DirX LDAP Server.

In the Controller tab of the perform activity, ensure that the fully-qualified pathname of the controller is correct: com.siemens.idm.jobs.Backup.

In the Backup Parameters tab of the perform activity you must set the folders where to store the backups and indicate whether this folder is located on a Windows system. Ignore the settings for the message server and leave them empty.
Note: The location of the Java-based Server’s backup file is configured with the server’s configuration.

In the field Connectivity Configuration / Backup Path, specify the fully-qualified pathname of an existing folder for the backup location of the DirX Server that hosts the Connectivity data store.
Note that the pathname must not be a part of the installation tree of the DirX Server. This is a mandatory field.
Check On Windows System if the DirX Server runs on Windows.

If the Provisioning part is hosted on a different LDAP server, specify the fully-qualified pathname of an existing folder for the backup location in the field Provisioning Configuration / Backup Path. See also the notes above.
Check On Windows System if the DirX Server runs on Windows.

Create a schedule for the workflow. (See the section "Schedule" in the appendix "Context Sensitive Help" in the DirX Identity Connectivity Administration Guide for details.)

In the field Target Backup System Path of the Post Operation tab, specify the fully-qualified pathname of an existing folder for the transfer location. On Windows, you can use a shared network drive, but then the IdS-J service must run under a different account from the system account and you must use the UNC syntax for the transfer folder.

Check On Windows System if the transfer location is hosted on Windows.

In Userhook Class Name, specify the name of your own class.
Note: This method is not currently supported. Contact technical support for more information.

Set the Active flag of the workflow and perform Load IdS-J Configuration from the context menu of the workflow object to load the workflow into the Java-based Server.

The Java-based workflow is a combination of a policy execution workflow handling consistency policies and the Tcl consistencyCheck workflow.

The workflow performs no user resolution.

You can select to run only part of the checks this workflow performs.

You can select to run the checks on a subset of objects.

Applies provisioning rules to users.

Enables or removes user-privilege assignments where start or end dates are reached.

Finds users where the state must be changed because one of the corresponding start or end dates has been changed.

Triggers user-privilege resolution for all matching users by sending a message to the Resolution Adapter per user.

In the Rule Search Parameters tab, you can change the cleanup rules to be executed. By default, the workflow uses three standard rules whose names start with "cleanup".

In the User Search Parameters tab, you can set several parameters to optimize runs. See the section "Policy Agent Optimization" in the DirX Identity Provisioning Administration Guide.

In the Tracing tab, set the tracing parameters. By default, the workflow reports errors and warnings.

In the Consistency Check Parameters tab, set the Subject Filter. This setting allows you to define the number of users the service agent is to check. The default filter checks all users that are flagged with the dxrTBA flag (this flag indicates that the entry is "to be analyzed").

In the Consistency Check Limits tab, you can set several parameters that you can use to optimize runs. See the section "Service Agent Configuration File" for a detailed explanation.

In the Tracing tab, set the tracing parameters. By default, only errors are reported.

Searches for roles, permissions, and groups in state TBDEL

For each privilege in state TBDEL it

Removes the incoming assignments to users and / or senior privileges and sets the TBA (to-be-analyzed) flag for the affected objects.

Deletes roles / permissions or sets its state to DELETED if history is configured.

Sets the state of groups to DELETED.

Searches the whole user and privilege database.

Sets the TBA (to-be-analyzed) flag for all users that have a privilege assigned that is itself flagged with TBA. Considers direct and indirect relationships (indirect relationships go via a role or permission).

Searches all privilege assignments with relevant start or end dates. The exact filter is:
(&(|(objectClass=dxrUserToRole)(objectClass=dxrUserToGroup)(objectClass=dxrUserToPermission))
(|(dxrEndDate=)(dxrStartDate=)))

Deletes out-dated start dates, removes assignments with out-dated end dates, and marks this user for privilege resolution.

Deletes users in state TBDEL with expired DeleteDate.

Sets the DeleteDate for users in state TBDEL that do not yet have a DeleteDate set.

Sets as StartDate the current date for users in state NEW that do not yet have a StartDate set.

Checks whether the various date fields of the user are consistent with the user state. If not, the user is flagged with TBA for a succeeding privilege resolution.

Checks whether the various date fields of the user are consistent, which means the sequence of the date fields must be StartDate, DisableStartDate, DisableEndDate, EndDate, DeleteDate.

Checks for broken references of privilege assignments.

Checks for correct user state and migrates the old state DELETED to TBDEL.

Flags users with TBA if the ErrorExpirationDate is reached. During the next privilege resolution, it stores the assigned groups even if the user is in error.

Works on all roles within the database (filter: (objectClass=dxrRole)).

Checks whether the role is valid, that means it must have a permission or junior role assigned.

Checks for broken references to junior roles and assigned permissions.

Works on all permissions within the database (filter: (objectClass=dxrPermission)).

Checks whether the permission is valid, that means it must have a group assigned.

Checks for broken references to assigned groups.

Checks whether the permission is assigned to users if it is not flagged for user assignment.

Checks for correct permission parameters.

Checks whether the Local Admin link of a target system is broken.

Works on all target system accounts within the database (filter: (objectClass=dxrTargetSystemAccount)).

Deletes all accounts that are marked with Managed in Target System Only that are in state Deleted in the target system.

Checks whether the target system of this account is of correct type and exists.

Checks for multiple primary accounts for a user.

Checks whether the User Link of the account is broken.

Checks for correct account states.

Deletes accounts that are in state DELETED and whose EndDate is expired.

Checks that the account is either marked for Managed in Target System Only and has no user link assigned or that it is not marked Managed in Target System Only and has a user link assigned.

Works on all target system groups within the database (filter: (objectClass=dxrTargetSystemGroup)).

Deletes all groups that are marked for Managed in Target System Only that are in state Deleted in the target system.

Checks whether all permission parameter values (dxrRPValues) are consistent with the permission parameter definition at the domain root object.

Checks for broken obligation links.

Checks for broken group members.

Checks whether the groups state has a correct value.

Deletes groups in state DELETED or DISABLED with expired EndDate.

Updates the distribution list of a virtual group.

Sends a resolve message to the Resolution Adapter for all users that match the expert filter of this consistency run.

Increasing the LDAP page size reduces the number of LDAP searches.

The reduction of searches reduces the client-server communication overhead and thus improves performance.

Increasing the LDAP page size leads to increased heap space.

Furthermore, the time from one paged search to the next increases, since more users must be resolved until the next page is requested. Thus, it is more likely that a paging policy timeout at the LDAP server can occur. This timeout results in a fatal error in the ServiceAgent and processing is stopped.

Check the service agent runtime with LDAP page size of 50, 100, 150, 200, 250, 300.

Run the tests with full logging and check the time between subsequent paged user searches.

Ensure that the paging policy timeout does not abort the agent run. You may increase the paging policy timeout configured at the server or reduce the LDAP page size if the paging policy timeout is hit.

Periodically run the ServiceAgent with full logging and check for that message. This task must be done from time to time since additional privileges / target systems may require a change in this setting.

In case the garbage collector message often occurs, increase the Object Cache MRU Size (cache.mru.size) to a higher value, until the message disappears.

An increase of the Object Cache MRU Size may require an increase of the maximum heap space of the Service Agent, since more objects are held in the cache that are not removed by the garbage collector.

In the Export Properties tab, you can define the base objects at which to start the search, the subset and the filter. Modify the base object if you want to run several Extract Audit Trail workflows in parallel on different parts of the Identity Store.

In the Import Properties tab, you can define the file path at which to write the extracted information.*
Note*: It makes sense to place the audit trail database on a separate disk to prevent all other processes from stopping when this disk is full.

In the Tracing tab, you can define the tracing parameters.

Select the job object of your Extract Audit Trail workflow.

Select the Specific Attributes tab.

Click Edit and set the parameter name to transformToPre80CSP0 and the value to false.

Click Save.

In the Rule Search Parameters tab, you can change the rule to be executed. By default, the standard FullSoDCheck rule is used.

In the User Search Parameters tab, you can set several parameters to optimize runs. See the section "Policy Agent Optimization" in the DirX Identity Provisioning Administration Guide.

In the Tracing tab, set the tracing parameters. By default, the workflow reports errors and warnings.

In the Rule Search Parameters tab, you can change the rule to be executed. By default, the standard InitializeReapproval rule is used.

In the User Search Parameters tab, you can set several parameters to optimize runs. See the section "Policy Agent Optimization" in the DirX Identity Provisioning Administration Guide.

In the Tracing tab, set the tracing parameters. By default, the workflow reports errors and warnings.

Double-click the connected directory icon Mail Server.

In the wizard window, click the icon to the right of the Service field.

Change the IP Address and Port fields to define the mail server.

Click OK.

In the wizard window, click Bind Profiles.

In Bind Profiles, click Admin, and then click the button on the right to open the property window for this entry.

Set the User and Password fields if your mail server requires authentication.

Click OK and then click Finish.

Right-click the workflow line between the connected directory icons Identity Store and Mail Server.

In the pop-up menu, select the workflow PwExpirationNotification and then click Configure.

Click MailConfiguration and/or MailContent.

Adjust the values as required.

Click Finish to close the wizard and save your changes.

dxrPwdMaxAge (Maximum age) - at the password policy. It defines the maximum allowed age of the password.

dxrPwdExpireWarning (Expiration Warning Time) - at the password policy. The time to warn before the password expires.

dxrPwdChangedTime (Password Changed Time) - at the user entry. The last time the password was changed.

In the Policy Agent Parameters tab, you can define whether the workflow runs in simulation mode (Simulate rules) or in real mode (Process rules). In simulation mode it only logs information and makes no changes in the Identity Store.

Additionally you can define if, after an assignment, the user should be immediately resolved (Assign Privilege and Resolve). You should use this feature only when your Provisioning domain uses simple privilege structures and has a small Identity Store. The service assigns a privilege to a user and then resolves the user. Assignment of several privileges to the same user results in multiple resolutions of this user, which can result in low performance. To optimize performance, you can build a nested workflow that consists of a policy execution step and a privilege resolution step.

In the Rule Search Parameters tab, you can select the set of rules to be executed.

In the User Search Parameters tab, you can set several parameters to optimize runs. See the section "Policy Agent Optimization" in the DirX Identity Provisioning Administration Guide.

In the Tracing tab, set the tracing parameters. By default, the workflow reports errors and warnings.

In the Privilege Resolution Parameters tab, set the Subject Filter. This setting allows you to define the number of users the service agent is to check. The default filter checks all users that are flagged with the dxrTBA flag (this flag indicates that the entry is "to be analyzed").

In the Provisioning Resolution Limits tab, you can set several parameters that you can use to optimize runs. See the section "Service Agent Configuration File" for a detailed explanation.

In the Tracing tab, set the tracing parameters. By default, only errors are reported.

Executes a privilege resolution on all users that match the expert filter of this run.

Searches for roles, permissions, and groups in state TBDEL.

For each privilege in state TBDEL it

Removes the incoming assignments to users and / or senior privileges and sets the TBA (to-be-analyzed) flag for the affected objects.

Deletes roles / permissions or sets it state to DELETED if history is configured.

Sets the state of groups to DELETED.

Searches the whole user and privilege database.

Sets the TBA (to-be-analyzed) flag for all users that have a privilege assigned that is itself flagged with TBA. Considers direct and indirect relationships (indirect relationships go via an assignment object).

Searches all privilege assignments with relevant start or end dates. The exact filter is:

(&(|(objectClass=dxrUserToRole)(objectClass=dxrUserToGroup)(objectClass=dxrUserToPermission))(|(dxrEndDate<=today)(dxrStartDate<=today)))

Deletes the start date or privilege assignment and marks this user for privilege resolution.

Is searches for all users with inconsistent state and dates and flags these users with TBA. The exact filter is:

(&(objectClass=dxrUser)(|(&(dxrEndDate<=today)(|(dxrState=ENABLED)(dxrState=DISABLED)))(&(dxrStartDate<=today)(dxrState=NEW))(&(dxrDisableEndDate<=today)(dxrState=DISABLED))(&(dxrDisableStartDate<=today)(dxrState=ENABLED))(dxrDeleteDate<=today)(&(dxrState=TBDEL)(!(dxrEndDate<=today)))))

Deletes accounts that are in state DELETED and whose EndDate is expired.

Deletes groups in state DELETED or DISABLED with expired EndDate.

Executes a privilege resolution on all users that match the expert filter of this run.

WorkflowName - defines the path of the workflow definition. For example, "Default/Source Scheduled/LDIFfile/LDIFfile2Ident" starts the LDIFfile2Ident workflow.

Instantiator - defines the name of the foreign domain (or any other meaningful name) that is later visible in the status entry.

MessageServer - selects your type of message server.

In the Rule Search Parameters tab, you can change the rule to be executed. By default, the standard StartWorkflowsForReapproval rule is used.

In the User Search Parameters tab, you can set several parameters to optimize runs. See the section "Policy Agent Optimization" in the DirX Identity Provisioning Administration Guide.

In the Tracing tab, set the tracing parameters. By default, the workflow reports errors and warnings.

In the Report Parameters tab, you can set the report definition path, the output format and the size limit. See the section "Service Agent Configuration File" for a detailed explanation.

In the Report Output File Properties tab, set the file name to which the report is to be written.

In the Tracing tab, set the tracing parameters. By default, only errors are reported.

In the Report Properties tab, you can set the search base, the report name and the output format.

In the Tracing tab, set the tracing parameters. By default, no trace is performed.