This chapter contains the following topics:
Note:
These sections provide both conceptual and procedural information about configuring the connector. It is recommended that you read the conceptual information before you perform the procedures.
For Oracle Identity Manager hosted on a Microsoft Windows computer, if you have a previously installed connector, then you must extract the connector bundle zip file again before installing a new connector.
Note:
It is recommended that you perform the procedure described in this section to secure communication between the target system and Oracle Identity Manager.
Perform the following steps to configure secure communication between Microsoft SQL Server and Oracle Identity Manager:
This section discusses the JDBC URL and Connection Properties parameters. You apply the information in this section while performing the procedure described in Configuring the IT Resource for the Target System.
The values that you specify for the Database URL and Connection Properties parameters depend on the target system:
Note:
In Microsoft SQL Server documentation, the term "connection URL" is used instead of "JDBC URL."
JDBC URL parameter
Enter the following component of the connection URL as the value of the JDBC URL provider:
jdbc:sqlserver://[SERVER_NAME][:PORT_NUMBER][;database=DATABASE_NAME]
In this format:
SERVER_NAME is the IP address (not the host name) of the target system host computer.
PORT_NUMBER is the port at which the target system database is listening.
DATABASE_NAME is the name of the database we are connecting.
Note:
If you specify database names both in the Database Name parameter and in the JDBC URL parameter, then the connector connects to the database specified in the Database Name parameter.
The following is a sample value for the Database URL parameter:
jdbc:sqlserver://192.168.16.76:1433;database=model
Connection Properties parameter
Enter the following component of the connection URL as the value of the Connection Properties parameter:
[;PROPERTY=VALUE[;PROPERTY=VALUE]] . . .
In this format:
PROPERTY is the name of one or more database connection properties, such as applicationName and disableStatementPooling.
VALUE is the value of each database connection property whose name you specify by using the PROPERTY placeholder.
Note:
Semicolons must be changed to number signs (#) in the value that you specify.
The following is a sample value for the Connection Properties parameter:
databaseName=sales#port=1433
If you enable SSL communication between Microsoft SQL Server and Oracle Identity Manager, then you must include the encrypt and hostNameInCertificate properties in the value that you specify for the Connection Properties parameter. In other words, the following must be part of the string that you enter as the value of the parameter:
encrypt=true#hostNameInCertificate=HOST_NAME
Replace HOST_NAME with the host name given in the certificate that you use.
In addition, you must specify the location of the truststore if you import the certificate into a truststore other than the JVM truststore of Oracle Identity Manager. To specify the location of the truststore, include the following properties in the value that you specify for the Connection Properties parameter:
encrypt=true#hostNameInCertificate=HOST_NAME#trustStore=STORE_LOCATION#trustStorePassword=STORE_PASSWORD
When you specify this value, replace STORE_LOCATION with the full path and name of the truststore, and replace STORE_PASSWORD with the password of the truststore.
This section contains the following information:
Lookup Definitions for Attribute Mappings for MSSQL Login Entity
Lookup Definitions for Attribute Mappings for MSSQL User Entity
Tip:
You must provide Decode values for some of the entries of the lookup definitions listed in this topic. To set a Decode value for an entry in a lookup definition:
On the Design Console, expand Administration, and then double-click Lookup Definition.
Search for and open the lookup definition that you want to modify.
Enter the value in the Decode column for the Code Key that you want to set.
Click the save icon.
During a provisioning operation, you use a lookup field on the process form to specify a single value from a set of values. For example, you use the Role lookup field to select a role to be assigned to the user from the list of available roles. When you deploy the connector, lookup definitions corresponding to the lookup fields on the target system are created in Oracle Identity Manager. Lookup field synchronization involves copying additions or changes made to the target system lookup fields into the lookup definitions in Oracle Identity Manager.
The connector provides predefined SQL queries for fetching values from the target system lookup fields into the lookup definitions in Oracle Identity Manager. These predefined SQL queries are stored in the LoVSearch.queries file with in the connector bundle.
After lookup definition synchronization, data is stored in the following format:
Code Key value: IT_RESOURCE_KEY~LOOKUP_FIELD_ID
In this format:
IT_RESOURCE_KEY is the numeric code assigned to each IT resource in Oracle Identity Manager.
LOOKUP_FIELD_ID is the target system code assigned to each lookup field entry.
Sample value: 1~SYS_ADM
Decode value: IT_RESOURCE_NAME~LOOKUP_FIELD_ID
In this format:
IT_RESOURCE_NAME is the name of the IT resource in Oracle Identity Manager.
LOOKUP_FIELD_ID is the target system code assigned to each lookup field entry.
While performing a provisioning operation in Oracle Identity Self Service, you select the IT resource for the target system on which you want to perform the operation. When you perform this action, the lookup definitions on the page are automatically populated with values corresponding to the IT resource (target system installation) that you select. If your environment has multiple installations of the target system, then values corresponding to all IT resources are displayed.
using-and-extending-connector-mssql.htm#GUID-C9F7EF26-00DD-4699-B410-BB916D1B8DD1__CHDBEBEC lists column names of the tables in Microsoft SQL Server that are synchronized with their corresponding lookup definitions in Oracle Identity Manager.
Table 3-2 Lookup Definitions Synchronized with Microsoft SQL Server
| Lookup Definition | Target Column Name |
|---|---|
|
Lookup.DBUM.MSSQL.AuthType |
authType |
|
Lookup.DBUM.MSSQL.DBNames |
name |
|
Lookup.DBUM.MSSQL.DBRoles |
name |
|
Lookup.DBUM.MSSQL.DefaultLang |
alias |
In Microsoft SQL server, you can create an account (login or user) that uses either Windows authentication or SQL server authentication.
The Lookup.DBUM.MSSQL.AuthType lookup definition holds information about authentication types that you can select for a target system account (login or user) that you create through Oracle Identity Manager.
MSSQL can operate in one of two authentication types:
Windows Authentication
Windows Authentication allows a user to connect through a Microsoft Windows user account. This is the default type of authentication.
SQL Server Authentication
SQL Server authentication relies on the internal user list maintained by the SQL Server computer. This list does not include Windows users, and is specific to the SQL Server computer. Users are created and configured using the SQL Server Enterprise Manager.
The following is the format of the Code Key and Decode values in this lookup definition:
Code Key: Type of authentication
Decode: Description of the type of authentication
using-and-extending-connector-mssql.htm#GUID-C9F7EF26-00DD-4699-B410-BB916D1B8DD1__CHDJADEH lists the default entries in this lookup definition.
Table 3-3 Entries in the Lookup.DBUM.MSSQL.AuthType Lookup Definition
| Code Key | Decode |
|---|---|
|
SQL_SERVER_AUTHENTICATION |
SQL_SERVER_AUTHENTICATION |
|
WINDOWS_AUTHENTICATION |
WINDOWS_AUTHENTICATION |
This section describes the configuration lookup definitions that are created in Oracle Identity Manager when you deploy the connector. These lookup definitions are either prepopulated with values or values must be manually entered in them after the connector is deployed.
This section provides information about the following lookup definitions
The Lookup.DBUM.MSSQL.Configuration lookup definition holds connector configuration entries that are used during target resource reconciliation and provisioning operations.
Note:
You cannot add entries to this lookup definition. However, you can modify the Decode values of the existing entries.
using-and-extending-connector-mssql.htm#GUID-4365441A-0849-4008-BC60-15D027012560__CHDGFGGG lists the default entries in this lookup definition.
Table 3-4 Entries in the Lookup.DBUM.MSSQL.Configuration Lookup Definition
| Code Key | Decode | Description |
|---|---|---|
|
Bundle Name |
org.identityconnectors.dbum |
This entry holds the name of the connector bundle package. Do not modify this entry. |
|
Bundle Version |
1.0.1116 |
This entry holds the version of the connector bundle class. Do not modify this entry. |
|
Connector Name |
org.identityconnectors.dbum.DBUMConnector |
This entry holds the name of the connector class. Do not modify this entry. |
|
disableValuesSet |
"true" |
This entry is used internally. Do not modify this entry. |
|
User Configuration Lookup |
Lookup.DBUM.MSSQL.UM.Configuration |
This entry holds the name of the lookup definition that contains user-specific configuration properties. Do not modify this entry. |
|
USERLOGIN Configuration Lookup |
Lookup.DBUM.MSSQL.Login.Configuration |
This entry holds the name of the lookup definition that contains login-specific configuration properties. Do not modify this entry. |
The Lookup.DBUM.MSSQL.Login.Configuration lookup definition holds configuration entries for Microsoft SQL Server login entity that are used during target resource reconciliation and provisioning operations.
using-and-extending-connector-mssql.htm#GUID-DF563F84-637C-428B-BD4B-A23092A915B3__CHDJJDJH lists the default entries in this lookup definition.
Table 3-5 Entries in Lookup.DBUM.MSSQL.Login.Configuration
| Code Key | Decode Key |
|---|---|
|
Provisioning Attribute Map |
Lookup.DBUM.MSSQL.Login.ProvAttrMap |
|
Provisioning Exclusion List |
Lookup.DBUM.MSSQL.Login.ProvExclusions |
|
Provisioning Validation Lookup |
Lookup.DBUM.MSSQL.Login.ProvValidations |
|
Recon Attribute Defaults |
Lookup.DBUM.MSSQL.Login.ReconDefaults |
|
Recon Attribute Map |
Lookup.DBUM.MSSQL.Login.ReconAttrMap |
|
Recon Exclusion List |
Lookup.DBUM.MSSQL.Login.ReconExclusions |
|
Recon Transformation Lookup |
Lookup.DBUM.MSSQL.Login.ReconTransformation |
|
Recon Validation Lookup |
Lookup.DBUM.MSSQL.Login.ReconValidation |
The Lookup.DBUM.MSSQL.UM.Configuration lookup definition holds connector configuration entries for Microsoft SQL Server user entity that are used during target resource reconciliation and provisioning operations.
using-and-extending-connector-mssql.htm#GUID-128B872E-1985-42B4-B202-3F46D70425F8__CHDGHIBE lists the default entries in this lookup definition.
Table 3-6 Entries in Lookup.DBUM.MSSQL.UM.Configuration
| Code Key | Dcode Key |
|---|---|
|
Provisioning Attribute Map |
Lookup.DBUM.MSSQL.UM.ProvAttrMap |
|
Provisioning Exclusion List |
Lookup.DBUM.MSSQL.UM.ProvExclusions |
|
Provisioning Validation Lookup |
Lookup.DBUM.MSSQL.UM.ProvValidations |
|
Recon Attribute Defaults |
Lookup.DBUM.MSSQL.UM.ReconDefaults |
|
Recon Attribute Map |
Lookup.DBUM.MSSQL.UM.ReconAttrMap |
|
Recon Exclusion List |
Lookup.DBUM.MSSQL.UM.ReconExclusions |
|
Recon Transformation Lookup |
Lookup.DBUM.MSSQL.UM.ReconTransformations |
|
Recon Validation Lookup |
Lookup.DBUM.MSSQL.UM.ReconValidation |
The Lookup.DBUM.MSSQL.Configuration.Trusted lookup definition holds connector configuration entries that are used during reconciliation and provisioning operations in trusted source mode.
Note:
You cannot add entries to this lookup definition. However, you can modify the Decode values of the existing entries.
using-and-extending-connector-mssql.htm#GUID-78185D25-1BFC-4AB0-AC7B-0CEF0FCE69A9__CHDIFFJI lists the default entries in this lookup definition.
Table 3-7 Entries in the Lookup.DBUM.MSSQL.Configuration.Trusted Lookup Definition
| Code Key | Decode | Description |
|---|---|---|
|
Bundle Name |
org.identityconnectors.dbum |
This entry holds the name of the connector bundle package. Do not modify this entry. |
|
Bundle Version |
1.0.1116 |
This entry holds the version of the connector bundle class. Do not modify this entry. |
|
Connector Name |
org.identityconnectors.dbum.DBUMConnector |
This entry holds the name of the connector class. Do not modify this entry. |
|
disableValuesSet |
"true" |
This entry is used internally. Do not modify this entry. |
|
USERLOGIN Configuration Lookup |
Lookup.DBUM.MSSQL.UM.Configuration.Trusted |
This entry holds the name of the lookup definition that contains login-specific configuration properties. Do not modify this entry. |
The Lookup.DBUM.MSSQL.UM.Configuration.Trusted lookup definition holds connector configuration entries for Microsoft SQL Server user entity that are used during reconciliation and provisioning operations in trusted source mode.
using-and-extending-connector-mssql.htm#GUID-0EE43FD4-C632-42D7-A64E-E38ACD1D6B28__CHDHGGJJ lists the default entries in this lookup definition.
Table 3-8 Entries in Lookup.DBUM.MSSQL.UM.Configuration.Trusted
| Code Key | Dcode Key |
|---|---|
|
Recon Attribute Defaults |
Lookup.DBUM.MSSQL.UM.ReconDefaults.Trusted |
|
Recon Attribute Map |
Lookup.DBUM.MSSQL.UM.ReconAttrMap.Trusted |
|
Recon Exclusion List |
Lookup.DBUM.MSSQL.UM.ExclusionList.Trusted |
|
Recon Transformation Lookup |
Lookup.DBUM.MSSQL.UM.ReconTransformations.Trusted |
|
Recon Validation Lookup |
Lookup.DBUM.MSSQL.UM.ReconValidation.Trusted |
This section describes the following lookup definitions:
The Lookup.DBUM.MSSQL.Login.ProvAttrMap lookup definition holds mappings for Microsoft SQL Server login entity between process form fields (Code Key values) and target system attributes (Decode values) used during provisioning operations.
using-and-extending-connector-mssql.htm#GUID-39514F24-D42E-447A-A55B-EC153D71F9D5__CHDEHBGD lists the default entries in this lookup definition.
Table 3-9 Entries in Lookup.DBUM.MSSQL.Login.ProvAttrMap
| Code Key | Decode Key |
|---|---|
|
Authentication Type |
authType |
|
Default DataBase[LOOKUP] |
defaultDatabase |
|
Default Language[LOOKUP] |
defaultLanguage |
|
Login Name |
__NAME__ |
|
Password |
__PASSWORD__ |
|
Reference ID |
__UID__ |
The Lookup.DBUM.MSSQL.Login.ReconAttrMap lookup definition holds mappings for Microsoft SQL Server login entity between process form fields (Code Key values) and target system attributes (Decode values) used during reconciliation operations.
using-and-extending-connector-mssql.htm#GUID-764DB816-835F-4F39-B55A-753E1C073737__CHDCGBIF lists the default entries in this lookup definition.
Table 3-10 Entries in Lookup.DBUM.MSSQL.Login.ReconAttrMap
| Code Key | Decode Key |
|---|---|
|
Authentication Type |
authType |
|
Default Database Name[LOOKUP] |
defaultDatabase |
|
Default Language[LOOKUP] |
defaultLanguage |
|
Login Name |
__UID__ |
|
Reference ID |
__UID__ |
|
Status |
__ENABLE__ |
This section describes the following lookup definitions:
The Lookup.DBUM.MSSQL.UM.ProvAttrMap lookup definition holds mappings between process form fields (Code Key values) and target system attributes (Decode values) used during provisioning operations.
using-and-extending-connector-mssql.htm#GUID-FC98CA85-7E86-4A41-B749-6ED4947AB2FA__CHDBFFEI lists the default entries in this lookup definition.
Table 3-11 Entries in Lookup.DBUM.MSSQL.UM.ProvAttrMap
| Code Key | Decode Key |
|---|---|
|
Database Name[LOOKUP] |
defaultDatabase |
|
Login Name |
loginName |
|
Reference ID |
__UID__ |
|
UD_DB_SQL_R~Role[LOOKUP] |
roles~DBRole~__NAME__ |
|
Username |
__NAME__ |
The Lookup.DBUM.MSSQL.UM.ReconAttrMap lookup definition holds mappings between resource object fields (Code Key values) and target system attributes (Decode values) used during reconciliation operations.
using-and-extending-connector-mssql.htm#GUID-22C51FC8-D705-447F-9219-CB44BCA0081F__CHDGIEAC lists the default entries in this lookup definition.
Table 3-12 Entries in Lookup.DBUM.MSSQL.UM.ReconAttrMap
| Code Key | Decode Key |
|---|---|
|
Database Name |
defaultDatabase |
|
Login Name |
loginName |
|
Reference ID |
__UID__ |
|
Role List~Role[LOOKUP] |
roles~DBRole~__NAME__ |
|
User Name |
__UID__ |
The Lookup.DBUM.MSSQL.UM.ReconDefaults lookup definition holds the following entries:
using-and-extending-connector-mssql.htm#GUID-117AC19B-A6A9-4FFD-A701-424412DEF335__CHDIJHCI lists the default entries in this lookup definition.
Table 3-13 Entries in Lookup.DBUM.MSSQL.UM.ReconDefaults
| Code Key | Decode Key |
|---|---|
|
Login Name |
WITHOUT LOGIN |
The Lookup.DBUM.MSSQL.UM.ReconDefaults.Trusted lookup definition holds the following entries:
using-and-extending-connector-mssql.htm#GUID-B5C620B0-2671-4ACF-883B-38B89A7A310A__CHDHBIHG lists the default entries in this lookup definition.
Table 3-14 Entries in Lookup.DBUM.MSSQL.UM.ReconDefaults.Trusted
| Code Key | Decode Key |
|---|---|
|
Empl Type |
Full-Time |
|
Organization Name |
Xellerate Users |
|
Status |
Active |
|
User Type |
End-User |
The Lookup.DBUM.MSSQL.UM.ReconAttrMap.Trusted lookup definition holds mappings between resource object fields (Code Key values) and target system attributes (Decode values) used during reconciliation operations in trusted source mode.
using-and-extending-connector-mssql.htm#GUID-D23F2A26-1187-42D9-B54F-0667C1E89661__CHDEGACB lists the default entries in this lookup definition.
Table 3-15 Entries in Lookup.DBUM.MSSQL.UM.ReconAttrMap.Trusted
| Code Key | Decode Key |
|---|---|
|
First Name |
__UID__ |
|
Status[TRUSTED] |
__ENABLE__ |
|
User ID |
__UID__ |
This section describes the lookup definitions that hold resources for which you do not want to perform provisioning and reconciliation operations.
You can use one of the following lookups for MSSQL login entity:
For provisioning operations: Lookup.DBUM.MSSQL.Login.ProvExclusions
For reconciliation operations: Lookup.DBUM.MSSQL.Login.ReconExclusions
You can use one of the following lookups for MSSQL user entity:
For provisioning operations: Lookup.DBUM.MSSQL.UM.ProvExclusions
For reconciliation operations: Lookup.DBUM.MSSQL.UM.ReconExclusions
For target system configured as trusted source: Lookup.DBUM.MSSQL.UM.ExclusionList.Trusted
The following is the format of the values stored in these lookups:
| Code Key | Decode | Sample Values |
|---|---|---|
|
Login Name |
User ID of a user |
Code Key: Login Name Decode: User001 |
|
Login Name with the [PATTERN] suffix |
A regular expression supported by the representation in the |
Code Key: Login Name[PATTERN] To exclude users matching any of the user ID 's User001, User002, User088, then: Decode: User001|User002|User088 To exclude users whose user ID 's start with 00012, then: Decode: 00012* See Also: For information about the supported patterns, visit |
Configuring Resource Exclusion Lists for MSSQL describes the procedure to add entries in these lookup definitions.
Depending on how the target system is configured, you can use one of the following lookups to enable transformation of data during reconciliation operations:
For Microsoft SQL Server login entity: Lookup.DBUM.MSSQL.Login.ReconTransformation
Table 3-16 Entries in Lookup.DBUM.MSSQL.Login.ReconTransformation
| Code Key | Decode Key |
|---|---|
|
Authentication Type |
mssql.oimcp.dbum.transformations.AuthTypeTransformationImpl |
For Microsoft SQL Server user entity: Lookup.DBUM.MSSQL.UM.ReconTransformations
For Microsoft SQL Server user entity in trusted source mode: Lookup.DBUM.MSSQL.UM.ReconTransformations.Trusted
Configuring Transformation of Data During User Reconciliation for MSSQL describes the procedure to add entries in these lookup definitions.
Depending on how the target system is configured, you can use one of the following lookups to enable validation of data:
For Microsoft SQL Server login entity during provisioning: Lookup.DBUM.MSSQL.Login.ProvValidations
For Microsoft SQL Server login entity during reconciliation: Lookup.DBUM.MSSQL.Login.ReconValidation
For Microsoft SQL Server user entity during provisioning: Lookup.DBUM.MSSQL.UM.ProvValidations
For Microsoft SQL Server user entity during reconciliation: Lookup.DBUM.MSSQL.UM.ReconValidation
Configuring Validation of Data During Reconciliation and Provisioning for MSSQL describes the procedure to add entries in this lookup definition.
When you run the Connector Installer or import the connector XML file, the scheduled jobs are automatically created in Oracle Identity Manager.
This section describes the following topics:
Lookup field synchronization involves copying additions or changes made to the target system lookup fields into the lookup definitions in Oracle Identity Manager.
The following scheduled jobs are used for lookup field synchronization:
DBUM MSSQL DB Names Lookup Reconciliation
DBUM MSSQL Languages Lookup Reconciliation
DBUM MSSQL Roles Lookup Reconciliation
You must specify values for the attributes of these scheduled jobs. using-and-extending-connector-mssql.htm#GUID-2CDBA52A-9E83-4F9F-AB61-639F9966D999__CHDHEFDC describes the attributes of these scheduled jobs. The procedure to configure scheduled jobs is described later in the guide.
Table 3-17 Attributes of the Scheduled Jobs for Lookup Field Synchronization for MSSQL
| Attribute | Description |
|---|---|
|
Code Key Attribute |
Enter the name of the connector or target system attribute that is used to populate the Code Key column of the lookup definition (specified as the value of the Lookup Name attribute). Sample value: Note: Do not change the value of this attribute. |
|
Decode Attribute |
Enter the name of the connector or target system attribute that is used to populate the Decode column of the lookup definition (specified as the value of the Lookup Name attribute). Sample value: |
|
IT Resource Name |
Enter the name of the IT resource for the target system installation from which you want to reconcile user records. Default value: |
|
Lookup Name |
This attribute holds the name of the lookup definition that maps each lookup definition with the data source from which values must be fetched. Depending on the scheduled job you are using, the default values are as follows:
|
|
Object Type |
Enter the type of object whose values must be synchronized. Depending on the scheduled job you are using, the default values are as follows:
Note: Do not change the value of this attribute. |
|
Resource Object Name |
Enter the name of the resource object that is used for reconciliation. Default value: |
The following scheduled jobs are used to reconcile user data in the target resource (account management) mode of the connector:
For MSSQL user entity: DBUM MSSQL User Target Reconciliation
For MSSQL login entity: DBUM MSSQL User Login Target Reconciliation
The following scheduled job is used to reconcile user data in the trusted source (identity management) mode of the connector:
DBUM MSSQL Trusted Reconciliation
using-and-extending-connector-mssql.htm#GUID-2CE4BEB5-86C2-4A7C-B429-755C30E2F9A2__CHDFHDJE describes the attributes of the scheduled jobs for user operations.
Table 3-18 Attributes of the Scheduled Jobs for Reconciliation for MSSQL User and Login Entities
| Attribute | Description |
|---|---|
|
Filter |
Expression for filtering records that must be reconciled by the scheduled job By default, the value of this attribute is empty. Sample value: See Performing Limited Reconciliation from MSSQL for the syntax of this expression. |
|
Incremental Recon Attribute |
Time stamp at which the last reconciliation run started Sample value: Note: Do not enter a value for this attribute. The reconciliation engine automatically enters a value for this attribute. |
|
IT Resource Name |
Name of the IT resource for the target system installation from which you want to reconcile user records Default value: |
|
Latest Token |
This attribute is used for internal purposes. By default, this value is empty. |
|
Object Type |
Type of object you want to reconcile For trusted mode and login entity scheduled jobs: Default value: |
|
Resource Object Name |
Name of the resource object that is used for reconciliation For login entity scheduled jobs: For trusted mode scheduled jobs: For all other scheduled jobs: |
|
Scheduled Task Name |
Name of the scheduled job Note: For the scheduled job included with this connector, you must not change the value of this attribute. However, if you create a copy of the task, then you can enter the unique name for that scheduled job as the value of this attribute. |
The following scheduled jobs are used to reconcile deleted user data in the target resource (account management) mode of the connector.
For MSSQL user entity: DBUM MSSQL Delete User Target Reconciliation
For MSSQL login entity: DBUM MSSQL Delete User Login Target Reconciliation
The following scheduled job is used to reconcile deleted user data in the trusted source (identity management) mode of the connector:
DBUM MSSQL Delete Trusted Reconciliation
using-and-extending-connector-mssql.htm#GUID-1ABDEC70-D210-4C65-81F4-E469EA777D50__CHDFBBEG describes the attributes of the scheduled jobs for delete operations.
Table 3-19 Attributes of the Scheduled Jobs for Delete Operations
| Attribute | Description |
|---|---|
|
IT Resource Name |
Name of the IT resource for the target system installation from which you want to reconcile user records For DBUM MSSQL Delete Trusted Reconciliation, enter the name of the IT resource created for trusted source mode. For DBUM MSSQL Delete User Login Target Reconciliation: For DBUM MSSQL Delete User Target Reconciliation: |
|
Object Type |
Type of object you want to reconcile For DBUM MSSQL Delete Trusted Reconciliation: For DBUM MSSQL Delete User Login Target Reconciliation: For DBUM MSSQL Delete User Target Reconciliation: |
|
Resource Object Name |
Name of the resource object that is used for reconciliation For DBUM MSSQL Delete Trusted Reconciliation: For DBUM MSSQL Delete User Login Target Reconciliation: For DBUM MSSQL Delete User Target Reconciliation: |
You can apply this procedure to configure the scheduled jobs for lookup fields synchronization and reconciliation.
See Scheduled Jobs for Lookup Field Synchronization for MSSQL and Attributes of the Scheduled Jobs for MSSQL Delete Operations for the scheduled jobs that are part of the connector and for information about their attributes.
To configure a scheduled job:
If you are using Oracle Identity Manager release 11.1.1.x:
Log in to the Administrative and User Console.
On the Welcome to Oracle Identity Manager Self Service page, click Advanced in the upper-right corner of the page.
On the Welcome to Oracle Identity Manager Advanced Administration page, in the System Management region, click Search Scheduled Jobs.
If you are using Oracle Identity Manager release 11.1.2.x or later:
Log in to Oracle Identity System Administration.
In the left pane, under System Management, click Scheduler.
Search for and open the scheduled job as follows:
On the left pane, in the Search field, enter the name of the scheduled job as the search criterion. Alternatively, you can click Advanced Search and specify the search criterion.
In the search results table on the left pane, click the scheduled job in the Job Name column.
On the Job Details tab, you can modify the following parameters:
Retries: Enter an integer value in this field. This number represents the number of times the scheduler tries to start the job before assigning the Stopped status to the job.
Schedule Type: Depending on the frequency at which you want the job to run, select the appropriate schedule type.
Note:
See Creating Jobs in Oracle Fusion Middleware Administering Oracle Identity Manager for detailed information about schedule types.
In addition to modifying the job details, you can enable or disable a job.
On the Job Details tab, in the Parameters region, specify values for the attributes of the scheduled job.
Note:
Attribute values are predefined in the connector XML file that you import. Specify values only for those attributes that you want to change.
Attributes of the scheduled job are discussed in Attributes of the Scheduled Jobs for MSSQL Delete Operations.
After specifying the attributes, click Apply to save the changes.
Reconciliation involves duplicating in Oracle Identity Manager the creation of and modifications to user accounts on the target system. This section discusses the following topics related to configuring reconciliation:
Note:
Batched reconciliation is not supported in MSSQL target system.
The following are guidelines that you must apply while configuring reconciliation:
Before a target resource reconciliation run is performed, lookup definitions must be synchronized with the lookup fields of the target system. In other words, the scheduled job for lookup field synchronization must be run before user reconciliation runs.
The scheduled job for user or login reconciliation must be run before the scheduled job for reconciliation of deleted user or login data.
This connector can be configured to perform either trusted source reconciliation or target resource reconciliation.
When you configure the target system as a target resource, the connector enables you to create and manage database accounts for OIM Users through provisioning. In addition, data related to newly created and modified target system accounts can be reconciled and linked with existing OIM Users and provisioned resources.
When you configure the target system as a trusted source, the connector fetches into Oracle Identity Manager, data about newly created or modified target system accounts. This data is used to create or update OIM Users. See Configuring the Target System As a Trusted Source for more information.
See Also:
Reconciliation Based on the Object Being Reconciled in Oracle Fusion Middleware Administering Oracle Identity Manager for conceptual information about target resource reconciliation and trusted source reconciliation.
The following is an overview of the steps involved in reconciliation:
Depending on the target system that you are using, a SQL query or stored procedure is used to fetch target system records during reconciliation.
The scheduled job communicates to connector bundle and runs search operations over it, maps the task attributes to parameters of the reconciliation query or stored procedure, and then runs the query or stored procedure on the target system.
Target system records that meet the query or stored procedure criteria are fetched into Oracle Identity Manager.
If you have configured your target system as a trusted source, then each user record fetched from the target system is compared with existing OIM Users. The reconciliation rule is applied during the comparison process.
The next step of the process depends on the outcome of the matching operation:
If a match is found between the target system record and the OIM User, then the OIM User attributes are updated with changes made to the target system record.
If no match is found, then the target system record is used to create an OIM User.
If you have configured your target system as a target resource, then each user record fetched from the target system is compared with existing target system resources assigned to OIM Users. The reconciliation rule is applied during the comparison process.
The next step of the process depends on the outcome of the matching operation:
If a match is found between the target system record and a resource provisioned to an OIM User, then the database user resource is updated with changes made to the target system record.
If no match is found, then the target system user record is compared with existing OIM Users. The next step depends on the outcome of the matching operation:
If a match is found, then the target system record is used to provision a resource for the OIM User.
If no match is found, then the status of the reconciliation event is set to No Match Found.
Note:
Reconciliation Rules for MSSQL for information about the reconciliation rule
As mentioned earlier in this chapter, a SQL query or a stored procedure is used to fetch target system records during reconciliation. All predefined SQL queries and stored procedures are stored in a JAR file in the bundle directory of the connector installation media.
For example, to locate the reconciliation query file, you can extract the bundle/org.identityconnectors.dbum-1.0.1116.jar file and open scripts/mssql/Search.queries.
Note:
Depending on your requirements, you can modify existing queries or add your own query in the query file. Alternatively, you can create and use your own query file. Modifying Predefined Queries or Creating New Queries for MSSQL provides more information.
Some of the predefined queries for MSSQL are used in conjunction with the Incremental Recon Attribute scheduled job attribute. This attribute stores the time stamp at which the last reconciliation run started. When the next reconciliation run begins, only target system records for which the lastModified column value is greater than the value of the Incremental Recon Attribute are fetched into Oracle Identity Manager. In other words, only records that were added or modified after the last reconciliation run started are considered for the current reconciliation run.
The following are the predefined queries for MSSQL:
SEARCH_USER
This query is used to fetch user records and their lastModified time-stamps using the sp_helpuser() function.
SEARCH_USERLOGIN
This query is used to fetch user records from the sys.syslogins table.
LOGIN_DATA_QUERY
This stored procedure is used to fetch user data using the sp_helplogins() function.
LOGIN_STATUS_AUTH_QUERY
This query is used to fetch user authentication data from the sys.server_principals table.
USER_DATA_QUERY
This stored procedure is used to fetch user records using the sp_helpuser() function.
As mentioned earlier in this guide, this connector can be configured to perform either target resource reconciliation or trusted source reconciliation. This section discusses the following topics:
For Microsoft SQL Server login entity
The Lookup.DBUM.MSSQL.Login.ReconAttrMap lookup definition holds attribute mappings for login data reconciliation. See Lookup Definitions for Attribute Mappings for MSSQL Login Entity for more information about this lookup definition.
For Microsoft SQL Server user entity
The Lookup.DBUM.MSSQL.UM.ReconAttrMap and Lookup.DBUM.MSSQL.UM.ReconAttrMap.Trusted lookup definitions hold the attribute mappings for user data reconciliation. See Lookup Definitions for Attribute Mappings for MSSQL User Entity for more information about this lookup definition.
Note:
Skip this section if you do not want to designate the target system as a trusted source for reconciliation.
To configure trusted source reconciliation:
If you are using Oracle Identity Manager release 11.1.1.x:
Log in to the Administrative and User Console.
On the Welcome page, click Advanced in the upper-right corner of the page.
On the Welcome to Oracle Identity Manager Advanced Administration page, in the Configuration region, click Create IT Resource.
If you are using Oracle Identity Manager release 11.1.2.x or later:
Log in to Oracle Identity System Administration.
In the left pane, under Configuration, click IT Resource.
In the Manage IT Resource page, click Create IT Resource.
On the Step 1: Provide IT Resource Information page, enter the following information:
IT Resource Name: Enter a name for the IT resource. For example, MSSQL DB Trusted.
IT Resource Type: Select the MSSQL DB IT resource type for the IT resource.
Click Continue.
On the Step 2: Specify IT Resource Parameter Values page, specify values for the parameters of the IT resource.
Configuration Lookup: Name of the lookup definition in which you store the connector configuration information for the target system.
Sample Value: Lookup.DBUM.MSSQL.Configuration.Trusted
Provide values for the other IT resource parameters.
Click Continue.
In the following steps, provide permissions on the IT resource that you are creating as per your requirements.
You can use this IT resource for trusted source reconciliation operations.
See Also:
Reconciliation Metadata in Oracle Fusion Middleware Developing and Customizing Applications for Oracle Identity Manager for generic information about reconciliation rules and reconciliation action rules
The following reconciliation rules are used by the reconciliation engine for this connector:
Rule name for user entity in target resource mode: DBUM MSSQL User Target Recon
Rule element: User Login Equals User Name
In this rule:
User Login is the field on the OIM User form.
User Name is the target system field.
Rule name for login entity in target resource mode: DBUM MSSQL Login Target Recon
Rule element: User Login Equals Login Name
In this rule element:
User Login is the field on the OIM User form.
Login Name is the target system field.
Rule name for trusted source mode: MSSQL UserLogin Trusted
Rule element: User Login Equals User ID
In this rule element:
User Login is the field on the OIM User form.
User ID is the target system field.
After you deploy the connector, you can view the reconciliation rule for reconciliation by performing the following steps:
Note:
Perform the following procedure only after the connector is deployed.
Reconciliation action rules define that actions the connector must perform based on the reconciliation rules defined for Users.
using-and-extending-connector-mssql.htm#GUID-C9F31C54-E4D7-42D6-BB7C-CE0CB35FC0F0__CHDDGAHA lists the action rules for target resource reconciliation.
Table 3-20 Action Rules for Target Resource Reconciliation for MSSQL
| Rule Condition | Action |
|---|---|
|
No Matches Found |
Assign to Administrator With Least Load |
|
One Entity Match Found |
Establish Link |
|
One Process Match Found |
Establish Link |
using-and-extending-connector-mssql.htm#GUID-C9F31C54-E4D7-42D6-BB7C-CE0CB35FC0F0__CHDGABFB lists the action rules for trusted source reconciliation.
Table 3-21 Action Rules for Trusted Source Reconciliation for MSSQL
| Rule Condition | Action |
|---|---|
|
No Matches Found |
Create User |
|
One Entity Match Found |
Establish Link |
After you deploy the connector, you can view the reconciliation action rules for target resource reconciliation by performing the following steps:
Full reconciliation involves reconciling all existing user records from the target system into Oracle Identity Manager. After you deploy the connector, you must first perform full reconciliation.
To perform a full reconciliation run, remove (delete) any value currently assigned to the Filter attribute and run one of the following scheduled jobs:
For MSSQL user entity in target resource mode: DBUM MSSQL User Target Reconciliation
For MSSQL login entity in target resource mode: DBUM MSSQL User Login Target Reconciliation
For MSSQL as a trusted source: DBUM MSSQL Trusted Reconciliation
See Attributes of the Scheduled Jobs for MSSQL Delete Operations for information about this scheduled job.
By default, all target system records that are added or modified after the last reconciliation run are reconciled during the current reconciliation run. You can customize this process by specifying the subset of added or modified target system records that must be reconciled. You do this by creating filters for the reconciliation module.
You can perform limited reconciliation by creating filters for the reconciliation module. This connector provides a Filter attribute (a scheduled task attribute) that allows you to use any of the DBUM resource attributes to filter the target system records. You can apply filters to the parent parameters in the reconciliation query file stored in a JAR file in the bundle directory of the connector installation media. For example, to locate the reconciliation query file, you can extract the bundle/org.identityconnectors.dbum-1.0.1116.jar file and open scripts/mssql/Search.queries.
The parent parameters that can be used with the Filter attribute of the scheduled jobs are __UID__ and __NAME__.
For detailed information about ICF Filters, see ICF Filter Syntax in Oracle Fusion Middleware Developing and Customizing Applications for Oracle Identity Manager.
While deploying the connector, follow the instructions in Configuring Scheduled Jobs for MSSQL to specify attribute values.
During an incremental reconciliation run, the scheduled job fetches only target system records that are added or modified after the time-stamp stored in the Latest Token attribute of the scheduled job. The connector requires a query to calculate the time-stamp value. This time-stamp value is used by the query that is used to perform reconciliation.
There is no configuration required for the connector to perform incremental reconciliation. After you run full reconciliation, the latest time-stamp of all the retrieved records is updated in the scheduled job and is used for next reconciliation runs.
Provisioning involves creating or modifying user account on the target system through Oracle Identity Manager.
This section contains the following topics about provisioning:
The following are guidelines that you must apply while performing provisioning operations:
Before you perform provisioning operations, lookup definitions must be synchronized with the lookup fields of the target system. In other words, run the scheduled jobs for lookup field synchronization before provisioning operations.
The character length of target system fields must be taken into account when specifying values for the corresponding Oracle Identity Manager fields.
During an update password provisioning operation, ensure that you clear the existing text in the Password field, and then enter the new password.
Before you provision a Microsoft SQL Server account that uses Windows Authentication, you must ensure that the account you want to provision exists in the account database of the operation system.
If you are creating users accounts, then you must specify a value for the Database Name parameter of the IT resource.
If you are provisioning a Microsoft SQL Server login account that uses Windows Authentication, then you must specify values for the following fields:
Default Database: Select the name of the default database that the user must connect to.
Default Language: Select the default language for the login.
Login Name: Enter the login name in the following format:
[DOMAIN_NAME\LOGIN_NAME]
In this format:
DOMAIN_NAME is the name of the domain to which the login account must belong.
LOGIN_NAME is the name of the login that you are creating in the target system.
The following is a sample value that you can enter in the Login Name field:
[MyDomain\jdoe]
If you are provisioning a Microsoft SQL Server login account that uses SQL Server Authentication, then you must specify values for the following mandatory fields:
Login Name: Enter the name of the login account.
Password: Enter the password for the login account.
Note:
Microsoft SQL Server has a strict password policy. However, the connector does not validate this password which may result in some failed operations.
You can add custom validation to ensure the default password policy of the target system is followed. If you do so, you must configure the validation for the password field in the Lookup.DBUM.MSSQL.Login.ProvValidations lookup definition.
Provisioning involves creating and managing user accounts. When you allocate (or provision) a database resource to an OIM User, the operation results in the creation of an account on the target database for that user. Similarly, when you update the resource on Oracle Identity Manager, the same update is made to the account on the target system.
When you install the connector on Oracle Identity Manager, the direct provisioning feature is automatically enabled. This means that the process form is enabled when you install the connector.
This following are types of provisioning operations:
Direct provisioning
Request-based provisioning
Provisioning triggered by policy changes
If you configure the connector for request-based provisioning, then the process form is suppressed and the object form is displayed. In other words, direct provisioning is disabled when you configure the connector for request-based provisioning. If you want to revert to direct provisioning, then see Switching Between Request-Based Provisioning and Direct Provisioning for MSSQL.
The following is an overview of the Create User provisioning process in MSSQL that is started through direct provisioning:
On the Create User page of the Administrative and User Console, the administrator enters the data required for an OIM User account creation.
Suppose the administrator enters the following values for the fields on the Create User page:
First Name: John
Last Name: Doe
User ID: jdoe
An OIM User account is created for John Doe.
The administrator selects the resource to be provisioned to the OIM User account that has been created.
Before provisioning a MSSQL User resource, you must first provision a MSSQL Userlogin resource on the same target system. During this provisioning, you have to provide login ID for the user.
In this example, the administrator selects the MSSQL DB User Login resource first and then selects the MSSQL DB User resource.
The administrator enters the data required for provisioning the MSSQL DB User resource. Suppose the administrator wants to create a local user that requires a password to log in to the database. Therefore, the administrator enters the following values on the resource provisioning process form:
IT Resource: MSSQL DB User
Login Name: JDoe
Authentication Type: SQL_SERVER_AUTHENTICATION
Password: my_pa55word
Default DataBase: sqldb1
Default Language: example
In addition, the administrator also enters the following value on the process form for granting roles:
Role: 3~db_datareader
You can grant roles for only a user entity and not for a login entity.
From the information available in the IT resource for the target system, the configuration (Lookup.DBUM.MSSQL.Configuration) lookup definition is identified. This lookup definition stores configuration information that is used during connector operations.
The connector bundle contains the script (Provisioning.queries) required for provisioning operations.
The identifiers in the SQL statement are replaced with the input parameters fetched from the query. Then, the SQL statement with actual values is formed.
The connector runs the SQL statement on MSSQL and creates the jdoe account on the target system.
If the administrator did not enter any values for granting roles, then the provisioning process ends here. Otherwise, the process continues to the next step.
While performing Step 3, the administrator had entered the required data for granting roles to the jdoe account. Therefore, the corresponding query as mentioned in Step 6 is fetched.
The complete SQL statement that must be run to perform the Add role provisioning operation is formed.
The input parameters required to run the SQL statement are fetched from the query file.
The identifiers in the SQL statement (formed in Step 9) are replaced with the input parameters fetched from the query. Then, the SQL statement with actual values is formed.
The query runs the SQL statement on the target system (MSSQL) and grants the role to the jdoe target system account.
In direct provisioning, the Oracle Identity Manager administrator uses the Administrative and User Console to create a target system account for a user.
To provision a resource by using the direct provisioning approach:
Log in to the Administrative and User Console.
If you want to first create an OIM User and then provision a database account to the user, then:
On the Welcome to Identity Administration page, in the Users region, click Create User.
On the Create User page, enter values for the OIM User fields, and then click the save icon.
If you want to provision a database account to an existing OIM User, then:
On the Welcome to Identity Administration page, search for the user by selecting Users from the Search list on the left pane.
Alternatively, in the Users region, click Advanced Search - User, provide a search criterion, and then click Search.
From the list of users displayed in the search results, select the OIM User.
The user details page is displayed.
From the Action menu, select Add Resource. Alternatively, you can click the add resource icon with the plus (+) sign. The Provision Resource to User page is displayed in a new window.
On the Step 1: Select a Resource page, select MSSQL DB User Login or MSSQL DB User as the resource from the list, and then click Continue.
You must first provision the MSSQL DB User Login resource to a user before provisioning the MSSQL DB User resource.
On the Step 2: Verify Resource Selection page, click Continue.
On the Step 5: Provide Process Data page, enter the details of the account that you want to create on the target system and then click Continue.
If you want to provide child data, then on the Step 5: Provide Process Data page for child data, search for and select the child data for the user on the target system and then click Continue. Repeat the same step if you have more than one child data and you want to provision them.
On the Step 6: Verify Process Data page, verify the data that you have provided and then click Continue.
The "Provisioning has been initiated" message is displayed. Perform the following step:
Close the window displaying the "Provisioning has been initiated" message.
On the Resources tab, click Refresh to view the newly provisioned resource.
If the resource status is Provisioned, then provisioning was successful. If the status is Provisioning, then there may be an error. To verify if there was an error, you can check the resource history.
The following sections discuss the steps to be performed to enable request-based provisioning:
In request-based provisioning, an end user creates a request for a resource by using the Administrative and User Console. Administrators or other users can also create requests for a particular user. Requests for a particular resource on the resource can be viewed and approved by approvers designated in Oracle Identity Manager.
The following are features of request-based provisioning:
A user can be provisioned only one resource (account) on the target system.
Note:
Direct provisioning allows the provisioning of multiple database accounts on the target system.
Direct provisioning cannot be used if you enable request-based provisioning.
The following sections provide information about the procedures you must perform to enable request-based provisioning:
Note:
The procedure described in this section is applicable only if you are using Oracle Identity Manager release 11.1.1.x.
The following are steps performed by the approver in a request-based provisioning operation:
A request dataset is an XML file that specifies the information to be submitted by the requester during a provisioning operation. These request datasets specify information about the default set of attributes for which the requester must submit information during a request-based provisioning operation.
To import a request dataset XML file by using the Deployment Manager:
The following steps are performed by the end user in a request-based provisioning operation:
To enable the Auto Save Form feature:
Run the PurgeCache utility to clear content belonging to the Metadata category from the server cache.
See Clearing Content Related to the Connector Resource Bundles from the Server Cache for instructions.
The procedure to enable enabling request-based provisioning ends with this step.
If you have configured the connector for request-based provisioning, you can always switch to direct provisioning. Similarly, you can always switch back to request-based provisioning any time. This section discusses the following topics:
Note:
It is assumed that you have performed the procedure described in Configuring Request-Based Provisioning for MSSQL.
If you want to switch from request-based provisioning to direct provisioning, then:
Log in to the Design Console.
Disable the Auto Save Form feature as follows:
Expand Process Management, and then double-click Process Definition.
Search for and open the MSSQL DB process definition.
Deselect the Auto Save Form check box.
Click the save icon.
If the Self Request Allowed feature is enabled, then:
Expand Resource Management, and then double-click Resource Objects.
If you have configured the target system as a trusted source, then search for and open the MSSQL UserLogin Trusted resource object.
If you have configured the target system as a target resource, then search for and open the MSSQL DB User (user entity) or MSSQL DB User Login (login entity) resource object.
Deselect the Self Request Allowed check box.
Click the save icon.
If you want to switch from direct provisioning back to request-based provisioning, then:
Log in to the Design Console.
Enable the Auto Save Form feature as follows:
Expand Process Management, and then double-click Process Definition.
Search for and open the MSSQL DB process definition.
Select the Auto Save Form check box.
Click the save icon.
If you want to enable end users to raise requests for themselves, then:
Expand Resource Management, and then double-click Resource Objects.
If you have configured the target system as a trusted source, then search for and open the MSSQL UserLogin Trusted resource object.
If you have configured the target system as a target resource, then search for and open the MSSQL DB User (user entity) or MSSQL DB User Login (login entity) resource object.
Select the Self Request Allowed check box.
Click the save icon.
To perform provisioning operations in Oracle Identity Manager release 11.1.2.x:
Log in to Identity Self Service.
If you want to first create an OIM User and then provision a target system account, then:
Note:
See Creating Users in Oracle Fusion Middleware Performing Self Service Tasks with Oracle Identity Manager for more information about creating a user.
In the left pane, under Administration, click Users.
The Search Users page is displayed.
From the Actions menu, select Create. Alternatively, you can click Create on the toolbar.
On the Create User page, enter values for the OIM User fields, and then click Submit. A message is displayed stating that the user is created successfully.
If you want to provision a target system account to an existing OIM User, then:
Note:
See Searching Users in Oracle Fusion Middleware Performing Self Service Tasks with Oracle Identity Manager for more information about searching a user.
In the left pane, under Administration, click Users.
The Search Users page is displayed.
Specify a search criteria to search for the OIM User, and then click Search.
From the list of users displayed in the search results, select the OIM User. The user details page is displayed on the right pane.
On the Account tab, click Request Accounts.
In the Catalog page, search for and add to cart the application instance (in other words, the account to be provisioned), and then click Checkout.
Specify value for fields in the application form and then click Ready to Submit.
Click Submit.
If you want to provision entitlements, then:
On the Entitlements tab, click Request Entitlements.
In the Catalog page, search for and add to cart the entitlement, and then click Checkout.
Click Submit.
The following sections describe procedures that you can perform to extend the functionality of the connector for addressing your specific business requirements:
Note:
From Oracle Identity Manager Release 11.1.2 onward, lookup queries are not supported. See Managing Lookups in Oracle Fusion Middleware Administering Oracle Identity Manager for information about managing lookups by using the Form Designer in Oracle Identity System Administration.
Modifying Predefined Queries or Creating New Queries for MSSQL
Configuring Queries to Add Support for Custom Parameters and Lookup Fields for MSSQL
About Configuring the Connector for Multiple Installations of MSSQL
About Configuring the Connector for Multiple Trusted Source Reconciliation from MSSQL
Configuring Validation of Data During Reconciliation and Provisioning for MSSQL
Configuring Transformation of Data During User Reconciliation for MSSQL
The following sections discuss syntax and guidelines that you must apply while modifying the predefined queries or creating new queries:
Predefined queries are provided to reconcile target system user records, synchronize lookup field values with Oracle Identity Manager, and for provisioning operations. You can modify the predefined queries or add your own queries.
The query files are included in a JAR file in the bundle directory of the connector installation media. For example, bundle/org.identityconnectors.dbum-1.0.1116.jar.
The connector includes the following types of queries:
Provisioning Queries
They are used for create, update, and delete operations. The query file is scripts/mssql/Provisioning.queries.
List of Values Search Queries
They are used for reconciliation of lookup definitions. A list of value query operates on a set of values for fields such as database names, roles, and languages. The query file is scripts/mssql/LoVSearch.queries.
Account Search Queries
They are used for full, incremental, and delete reconciliation operations. An account search query operates on account and group searches with various conditions. The query file is scripts/mssql/Search.queries.
Note:
The stored procedure OUT parameters cannot be configured for write-back on the process form. The returned values cannot be used for any connector operations.
The following is the syntax of the queries used for provisioning operations:
QUERYID {
Query="QUERY"
QueryType="QUERYTYPE"
Parameters=["PARAM1":"PARAMDEFN1", "PARAM2":"PARAMDEFN2"...]
ExtensionJoin="EXTENSIONJOIN"
ExtensionSeparator="EXTENSIONSEPARATOR"
QueryExtensions=["EXTENSION1","EXTENSION2"...]
}
For example:
CREATE_SQL_SERVER_AUTHENTICATION_USERLOGIN {
Query="CREATE LOGIN {__NAME__} WITH PASSWORD={__PASSWORD__}"
QueryType="SQL"
Parameters=["__NAME__":"Type:String", "__PASSWORD__":"Type:GuardedString, Tags:QUOTES"]
ExtensionJoin=","
ExtensionSeparator=", "
QueryExtensions=["DEFAULT_DATABASE", "DEFAULT_LANGUAGE"]
}
In this syntax:
QUERYID refers to the unique name of the query.
For example: CREATE_SQL_SERVER_AUTHENTICATION_USERLOGIN
For CREATE provisioning queries, the format of QUERYID is CREATE_AUTHENTICATIONTYPE_ENTITY. The format for other provisioning queries can be OPERATIONTYPE_ENTITY (such as DELETE_USERLOGIN), ENTITY_OPERATIONTYPE_ATTRIBUTE (such as USERLOGIN_UPDATE_DEFAULTDATABASE) or OPERATIONTYPE_OPERATION (such as UPDATE_ADD_ROLES).
QUERY refers to the main query.
For example: Query="CREATE LOGIN {__NAME__} WITH PASSWORD={__PASSWORD__}"
QueryType refers to the type of the main query, either an SQL query, a stored procedure, or a query extension. The value of QUERYTYPE can be SQL, StoredProc, or QUERYEXTENSION.
For example: QueryType="SQL"
Parameters refers to the list of comma separated parameters and parameter definitions used with the main query, represented by "PARAM1":"PARAMDEFN1", "PARAM2":"PARAMDEFN2", and so on.
For example:
Parameters=["__NAME__":"Type:String", "__PASSWORD__":"Type:GuardedString, Tags:QUOTES"]
A parameter can have the following attributes:
Type is the type of the parameter.
Direction is the flow of data from the query to or from the parameter. It can have a value of IN, OUT, or INOUT.
TAGS is the enclosure characters that are applied to the parameter before the query is processed. It can have a value of DOUBLEQUOTES, QUOTES, UPPERCASE, or LOWERCASE. You can use multiple tags in double quotes and separated by commas. However, you must not use DOUBLEQUOTES with QUOTES or UPPERCASE with LOWERCASE in the same query.
ExtensionJoin (optional) refers to the operator, represented by EXTENSIONJOIN, used to join the main query with query extensions.
For example: ExtensionJoin=","
ExtensionSeparator (optional) refers to the delimiter between query extensions, represented by EXTENSIONSEPARATOR.
For example: ExtensionSeparator=", "
QueryExtensions (optional) refers to the extensions that must be appended to the main query, represented by EXTENSION1, EXTENSION2, and so on.
For example:
QueryExtensions=["DEFAULT_DATABASE", "DEFAULT_LANGUAGE"]
During an operation, the connector combines all these components to the following query:
QUERY PARAM1, PARAM2... [EXTENSIONJOIN [EXTENSION1 EXTENSIONSEPARATOR EXTENSION2 EXTENSIONSEPARATOR...]]
For example:
CREATE LOGIN {__NAME__} WITH PASSWORD={__PASSWORD__}, DEFAULT_DATABASE={defaultDatabase}, DEFAULT_LANGUAGE={defaultLanguage}
using-and-extending-connector-mssql.htm#GUID-1E9471F3-C96E-4472-A378-0B4F67A82941__CHDFFIFG lists the script selection logic of the provisioning queries:
Table 3-22 Script Section Logic for MSSQL Provisioning Queries
| Operation | Selection Logic | Query IDs |
|---|---|---|
|
CREATE |
CREATE_AUTHTYPE_OBJECTYPE CREATE_OBJECTTYPE |
CREATE_SQL_SERVER_AUTHENTICATION_USERLOGIN CREATE_WINDOWS_AUTHENTICATION_USERLOGIN CREATE_USER |
|
DELETE |
DELETE_OBJECTTTYPE |
DELETE_USERLOGIN DELETE_USER |
|
ENABLE |
ENABLE_OBJECTTYPE |
ENABLE_USERLOGIN |
|
DISABLE |
DISABLE_OBJECTTYPE |
DISABLE_USERLOGIN |
|
RESET PASSWORD |
OBJECTTYPE_SET_PASSWORD |
USERLOGIN_SET_PASSWORD |
|
UPDATE |
OBJECTTYPE_UPDATE_ATTRIBUTE |
USERLOGIN_UPDATE_DEFAULTDATABASE USERLOGIN_UPDATE_DEFAULTLANGUAGE USERLOGIN_UPDATE_LOGINNAME |
|
ADD CHILD VALUES |
UPDATE_ADD_ATTRIBUTE |
UPDATE_ADD_ROLES |
|
REMOVE CHILD VALUES |
UPDATE_REVOKE_ATTRIBUTE |
UPDATE_REVOKE_ROLES |
The following is the syntax of the search queries used during reconciliation operations:
QUERYID {
Query="QUERY"
QueryType="QUERYTYPE"
Parameters=["PARAM1":"PARAMDEFN1", "PARAM2":"PARAMDEFN2"...]
ExtensionJoin="EXTENSIONJOIN"
ExtensionSeparator="EXTENSIONSEPARATOR"
QueryExtensions=["EXTENSION1","EXTENSION2"...]
}
For example:
SEARCH_USER {
Query="select {__UID__}, {lastModified} from (select * from sys.sysusers where issqlrole=0) OUTERQUERY {filter}"
QueryType="SQL"
Parameters=["__UID__":"Type:String,Direction:OUT,ColName:name",
"lastModified":"Type:long,Direction:OUT,ColName:TS, ColQuery:\"cast((cast(updatedate as float)*100000) as bigint)\""]
QueryExtensions=["USER_DATA_QUERY"]
}
In this syntax:
QUERYID refers to the unique name of the query.
For example: SEARCH_USER
QUERYID can be one of the following values:
SEARCH_USER
SEARCH_USERLOGIN
Query refers to the main query, represented by QUERY.
For example: Query="select {__UID__}, {lastModified} from (select * from sys.sysusers where issqlrole=0) OUTERQUERY {filter}"
QueryType refers to the type of the main query, either an SQL query, a stored procedure, or a query extension. The value of QUERYTYPE can be SQL, StoredProc, or QUERYEXTENSION.
For example: QueryType="SQL"
Parameters refers to the list of comma separated parameters and parameter definitions used with the main query, represented by "PARAM1":"PARAMDEFN1", "PARAM2":"PARAMDEFN2", and so on.
For example:
Parameters=["__UID__":"Type:String,Direction:OUT,ColName:name", "lastModified":"Type:long,Direction:OUT,ColName:TS, ColQuery:\"cast((cast(updatedate as float)*100000) as bigint)\""]
A parameter can have the following attributes:
Type is the type of the parameter.
Direction is the flow of data from the query to or from the parameter. It can have a value of IN, OUT, or INOUT.
ColName is the column name in the target system corresponding to the parameter in the query.
ColQuery is the query used to fetch values for the corresponding query parameter.
ExtensionJoin (optional) refers to the operator, represented by EXTENSIONJOIN, used to join the main query with query extensions.
For example: ExtensionJoin=","
ExtensionSeparator (optional) refers to the delimiter between query extensions, represented by EXTENSIONSEPARATOR.
For example: ExtensionSeparator=", "
QueryExtensions (optional) refers to the extensions that must be appended to the main query, represented by EXTENSION1, EXTENSION2, and so on.
For example: QueryExtensions=["USER_DATA_QUERY"]
QueryExtensions can be one of the following:
LOGIN_DATA_QUERY
LOGIN_STATUS_AUTH_QUERY
USER_DATA_QUERY
During a reconciliation operation, the connector combines all these components to the following query:
QUERY PARAM1, PARAM2... [EXTENSIONJOIN [EXTENSION1 EXTENSIONSEPARATOR EXTENSION2 EXTENSIONSEPARATOR...]]
For example:
SELECT {__UID__}, {lastModified} FROM sys.sysusers, USER_DATA_QUERY
If a search query is performed on entities, such as user entity or login entity, then the query is considered as a reconciliation query. If a search query is performed on any other object, then the query is considered as a list of values query.
The following is the syntax of the list of values queries used for lookup field synchronization:
OBJECTTYPE = "QUERY"
For example:
__DBNAMES__="SELECT name FROM sys.sysdatabases"
In this syntax:
OBJECTTYPE refers to the attribute provided by objectType scheduled job parameter.
For example: __DBNAMES__
QUERY refers to the query used for fetching a lookup field attribute.
For example: SELECT name FROM sys.sysdatabases
The list of values queries return only one value, used as a lookup field value. By default, the connector includes a dedicated scheduled job for each lookup definition. To use a custom lookup definition, you must add custom fields in the query file.
The following are guidelines that you must apply while modifying or creating queries for reconciliation:
By adding or removing a column from the SELECT clause of a reconciliation query, you add or remove an attribute from the list of target system attributes for reconciliation. To enable the connector to process a change (addition or removal) in the list of reconciled attributes, you must make corresponding changes in the provisioning part of the connector.
In the query properties file, you must not change the names of the predefined queries.
Some of the predefined queries use inner queries. If you add or remove a column from the outer query, you must make corresponding changes in the inner queries.
You must not remove columns corresponding to the Login Name and User Name resource object attributes.
You must ensure that the following condition included in the Parameters list is not removed:
"lastModified":"Type:long,Direction:IN,ColQuery:\"cast((cast(updatedate as float)*100000) as bigint)\""]
This condition is used to determine if a target system record was added or updated after the time-stamp stored in the Incremental Recon Attribute scheduled job attribute.
When you add or remove columns from the SELECT clause of the queries in the properties file, then you must update the attribute mapping lookup definition that holds mappings between child attributes and the target system column names. In addition, you must update other OIM objects.
Before you modify or add a query in the Search.queries file, you must run the query by using any standard database client to ensure that the query produces the required results when it is run against the target system database.
The connector uses preconfigured queries for connector operations such as create, delete, and search. You can add custom parameters and lookup definition fields as per your requirements.
The procedure to add a parameter or a lookup definition field to a query file is discussed in the following sections:
To update a query file:
If the connector is already installed, run the Oracle Identity Manager Download JARs utility to download the connector bundle JAR file from the Oracle Identity Manager database. This utility is copied into the following location when you install Oracle Identity Manager:
Note:
Before you use this utility, verify that the WL_HOME environment variable is set to the directory in which Oracle WebLogic Server is installed.
For Microsoft Windows:
OIM_HOME/server/bin/DownloadJars.bat
For UNIX:
OIM_HOME/server/bin/DownloadJars.sh
When you run the utility, you are prompted to enter the login credentials of the Oracle Identity Manager administrator, URL of the Oracle Identity Manager host computer, context factory value, type of JAR file being downloaded, and the location from which the JAR file is to be downloaded. Select ICFBundle as the JAR type.
Copy the bundle JAR file in a temporary directory.
Sample JAR file: bundle/org.identityconnectors.dbum-1.0.1116.jar
Sample temporary directory: c:\temp
Run the following command to extract the manifest file, META-INF/MANIFEST.MF, from the JAR file:
jar -xvf org.identityconnectors.dbum-1.0.1116.jar
Note:
You can also run the WinZip or WinRAR utility to extract the contents from the JAR file.
Delete the bundle JAR file in the temporary directory.
Update the value of ConnectorBundle-Version in the manifest file to a new value.
For example:
ConnectorBundle-Version: 1.0.1117
Depending on your requirement, update the query file with new parameters as per the query syntax described in Modifying Predefined Queries or Creating New Queries for MSSQL.
For example, if you want to add a new parameter, defaultLanguage, to the CREATE_SQL_SERVER_AUTHENTICATION_USERLOGIN provisioning query:
Open the query file in a text editor.
Sample query file: c:\temp\bundle\org.identityconnectors.dbum-1.0.1116\scripts\mssql\Provisioning.queries
Add the parameter, defaultLanguage, to the CREATE_SQL_SERVER_AUTHENTICATION_USERLOGIN query.
Sample updated query:
CREATE_SQL_SERVER_AUTHENTICATION_USERLOGIN {
Query="CREATE LOGIN {__NAME__}, DEFAULT_LANGUAGE={defaultLanguage} WITH PASSWORD={__PASSWORD__}"
QueryType="SQL"
Parameters=["__NAME__":"Type:String", "defaultLanguage":"Type:String", "__PASSWORD__":"Type:GuardedString, Tags:QUOTES"]
ExtensionJoin=","
ExtensionSeparator=", "
QueryExtensions=["DEFAULT_DATABASE", "DEFAULT_LANGUAGE"]
}
Save and close the query file.
Create a new bundle JAR file that contains the updated manifest file and the query files as follows:
Open the command prompt and navigate to the temporary directory:
c:\temp
If there are any driver JAR files, copy them to the lib directory under the bundle directory.
Run the following command:
jar -cvfm org.identityconnectors.dbum-1.0.1117.jar META-INF/MANIFEST.MF *
The new connector bundle JAR name contains the new bundle version.
In the case of a remote connector server, copy the new bundle JAR file in the bundles directory of the remote connector server, instead of posting the JAR file to the Oracle Identity Manager database. Skip to Step 9.
Run the Oracle Identity Manager Update JARs utility to post the JAR file created in Step 7 to the Oracle Identity Manager database. This utility is copied into the following location when you install Oracle Identity Manager:
Note:
Before you use this utility, verify that the WL_HOME environment variable is set to the directory in which Oracle WebLogic Server is installed.
For Microsoft Windows:
OIM_HOME/server/bin/UpdateJars.bat
For UNIX:
OIM_HOME/server/bin/UpdateJars.sh
When you run the utility, you are prompted to enter the login credentials of the Oracle Identity Manager administrator, URL of the Oracle Identity Manager host computer, context factory value, type of JAR file being updated, and the location from which the JAR file is to be updated. Select ICFBundle as the JAR type.
Update the configuration lookup with the new bundle version.
For example, you can update the Lookup.DBUM.MSSQL.Configuration lookup definition.
You can skip this procedure if the parameter you added already exists as a default form field in Oracle Identity Manager.
To configure Oracle Identity Manager for adding a parameter:
Log into Oracle Identity Manager Design Console.
Create a new version of the process form:
Expand Development Tools.
Double-click Form Designer.
Search for and open the UD_DB_SQL_U process form.
Click Create New Version.
On the Create a new version dialog box, enter a new version in the Label field, and then click the save icon.
Add the new field on the process form.
Click Add.
A field is added to the list. Enter the details of the field.
For example, if you are adding the CustomAttribute1 field, enter UD_DB_SQL_U_CUSTOM1 in the Name field and then enter the rest of the details of this field.
Click the save icon and then click Make Version Active.
If you are using Oracle Identity Manager release 11.1.2.x or later, then all changes made to the Form Designer of the Design Console must be done in a new UI form as follows:
Log in to Oracle Identity System Administration.
Create and active a sandbox.
Create a new UI form to view the newly added field along with the rest of the fields. See Creating Forms By Using the Form Designer in Oracle Fusion Middleware Administering Oracle Identity Manager.
Associate the newly created UI form with the application instance of your target system. To do so, open the existing application instance for your resource, from the Form field, select the form (created in Step 4.c), and then save the application instance.
Publish the sandbox as described in Publishing a Sandbox of Oracle Fusion Middleware Developing and Customizing Applications for Oracle Identity Manager.
Create an entry for the field in the lookup definition for provisioning as follows:
Expand Administration.
Double-click Lookup Definition.
Search for and open the Lookup.DBUM.MSSQL.UM.ProvAttrMap lookup definition.
Click Add and enter the Code Key and Decode values for the field.
The Code Key value must be the form field name. The Decode value must be the attribute name on the target system.
For example, enter Custom Attribute 1 in the Code Key field and then enter CustomAttribute1 in the Decode field.
Click the save icon.
Create a process task to update the new field Custom Attribute 1 as follows:
Expand Process Management.
Double-click Process Definition and open the MSSQL DB User process definition.
Click Add and enter the task name, for example, Custom Attribute 1 Updated, and the task description.
In the Task Properties section, select the Conditional and Allow Multiple Instances checkboxes and click the save icon.
On the Integration tab, click Add, and then click Adapter.
Select the adpMSSQLUPDATEUSER adapter, click the save icon, and then click OK in the message that is displayed.
To map the adapter variables listed in this table, select the adapter, click Map, and then specify the data given in the following table:
| Variable Name | Data Type | Map To | Qualifier | Literal Value |
|---|---|---|---|---|
|
Adapter return value |
Object |
Response code |
NA |
NA |
|
attributeName |
String |
Literal |
String |
Custom Attribute 1 |
|
itRes |
String |
Literal |
String |
UD_DB_SQL_U_ITRES |
|
objectType |
String |
Literal |
String |
User |
|
processInstanceKey |
Long |
Process Data |
Process Instance |
NA |
On the Responses tab, click Add to add the following response codes:
| Code Name | Description | Status |
|---|---|---|
|
ERROR |
Error occurred |
R |
|
UNKNOWN |
An unknown response was received |
R |
|
SUCCESS |
Operation completed |
C |
Click the save icon and then close the dialog box.
You might want to configure the connector for multiple installations of the target system. The following example illustrates this requirement:
The London and New York offices of Example Multinational Inc. have their own installations of the target system. The company has recently installed Oracle Identity Manager, and they want to configure Oracle Identity Manager to link all the installations of the target system.
To meet the requirement posed by such a scenario, you can create copies of connector objects, such as the IT resource and resource object.
The decision to create a copy of a connector object might be based on a requirement. For example, an IT resource can hold connection information for one target system installation. Therefore, it is mandatory to create a copy of the IT resource for each target system installation.
With some other connector objects, you do not need to create copies at all. For example, a single attribute-mapping lookup definition can be used for all installations of the target system.
All connector objects are linked. For example, a scheduled job holds the name of the IT resource. Similarly, the IT resource for a target system holds the name of the configuration lookup definition, Lookup.DBUM.MSSQL.Configuration. If you create a copy of an object, then you must specify the name of the copy in associated connector objects.
Note:
To reconcile data from a particular target system installation, specify the name of the IT resource for that target system installation as the value of the scheduled job attribute that holds the IT resource name. For example, you enter the name of the IT resource as the value of the IT resource attribute of the scheduled job that you run.
When you use Identity Self Service to perform provisioning, you can specify the IT resource corresponding to the target system installation to which you want to provision the user.
using-and-extending-connector-mssql.htm#GUID-8FF58BC5-86B9-4372-B82F-FB2C8352BD80__CHDHBEFG lists associations between connector objects whose copies can be created and the other objects that reference these objects. When you create a copy of a connector object, use this information to change the associations of that object with other objects.
Note:
On a particular Oracle Identity Manager installation, if you create a copy of a connector object, then you must set a unique name for it.
If you are using Oracle Identity Manager release 11.1.2.x or later, then in addition to the procedure described in this section, you must create an application instance for each IT resource. See Configuring Oracle Identity Manager Release 11.1.2 or Later for information on creating an application instance.
Table 3-23 Connector Objects and Their Associations
| Connector Object | Name | Referenced By | Comments on Creating a Copy |
|---|---|---|---|
|
IT resource |
MSSQL DB |
Process forms:
Scheduled Jobs |
You need to create a copy of IT resource with a different name. |
|
Resource object |
|
All connector operations |
It is optional to create a copy of the resource object. If you are reconciling the same set of attributes from all installations of the target system, then you need not create a copy of the resource object. Note: Create copies of the resource object only if there are differences in attributes between the various installations of the target system. |
|
Scheduled Jobs |
There are many scheduled jobs for different purposes. |
NA |
You can use the scheduled jobs with the same names. However, you must update the values of the parameters depending on the target system you want to use. |
|
Process definition |
|
NA |
It is optional to create a copy of the process definition. If you are reconciling or provisioning the same set of attributes from all installations of the target system, then you need not create a copy of the process definition. Note: Create copies of the process form only if there are differences in attributes between the various installations of the target system. |
|
Process form |
|
Process definitions:
|
It is optional to create a copy of the process form. If you are provisioning the same set of attributes from all installations of the target system, then you need not create a copy of the process definition. Note: Create copies of the process form only if there are differences in attributes between the various installations of the target system. |
|
Child process form |
UD_DB_SQL_R |
|
It is optional to create a copy of the child process form. If you are provisioning a new set of child data, then you need to create a copy of the child and parent process form. Then, assign the newly created child process form to the newly created parent process form. |
|
Configuration lookup definition for a target system configured as a target resource |
Lookup.DBUM.MSSQL.Configuration |
MSSQL DB (IT resource) |
It is optional to create a copy of the configuration lookup definition. If you are provisioning and reconciling the same set of attributes in all installations of the target system (configured as a target resource), then you need not create a copy of the configuration lookup definition. Note: Create copies of the configuration lookup definition only if there are differences in attributes between the various installations of the target system and you have created a new process form. |
|
Configuration lookup definition for a target system configured as a trusted source |
Lookup.DBUM.MSSQL.Configuration.Trusted |
MSSQL DB (IT resource) |
It is optional to create a copy of the configuration lookup definition. If you are reconciling the same set of attributes in all installations of the target system (configured as a trusted source), then you need not create a copy of the configuration lookup definition. Note: Create copies of the configuration lookup definition for trusted source only if there are differences in attributes between the various installations of the target system and you have created a new process form. |
|
Resource object attributes mapping lookup definition (for trusted source) |
Lookup.DBUM.MSSQL.UM.ReconAttrMap.Trusted |
It is optional to create a copy of resource object attribute mapping lookup. If you are reconciling the same set of attributes in all installations of the target system (configured as a trusted source), then you need not to create a copy of resource object attribute mapping lookup. Note: Create copies of this lookup definition only if there are differences in attributes between the two installations of the target system. |
Note:
This connector supports multiple trusted source reconciliation.
This section describes an optional procedure. Perform this procedure only if you want to configure the connector for multiple trusted source reconciliation.
The following are examples of scenarios in which there is more than one trusted source for user data in an organization:
One of the target systems is a trusted source for data about users. The second target system is a trusted source for data about contractors. The third target system is a trusted source for data about interns.
One target system holds the data of some of the identity fields that constitute an OIM User. Two other systems hold data for the remaining identity fields. In other words, to create an OIM User, data from all three systems would need to be reconciled.
If the operating environment of your organization is similar to that described in either one of these scenarios, then this connector enables you to use the target system as one of the trusted sources of person data in your organization.
The following are the guidelines for configuring multiple trusted source reconciliation:
By default, trusted source reconciliation is performed for MSSQL login entities.
To configure trusted source reconciliation to be performed for user entities, modify the Resource Object Name parameter of the reconciliation scheduled jobs to MSSQL DB User and Object Type from USERLOGIN to User.
To enable reconciliation for each new trusted source, create a new IT Resource and update the IT Resource Name parameter of the scheduled jobs with the name of the new IT Resource.
You can configure validation of reconciled and provisioned single-valued data according to your requirements. For example, you can validate data fetched from the First Name attribute to ensure that it does not contain the number sign (#). In addition, you can validate data entered in the First Name field on the process form so that the number sign (#) is not sent to the target system during provisioning operations.
To configure validation of data:
You can configure transformation of reconciled single-valued user data according to your requirements. For example, you can use First Name and Last Name values to create a value for the Full Name field in Oracle Identity Manager.
To configure transformation of single-valued user data fetched during reconciliation:
You can specify a list of accounts that must be excluded from reconciliation and provisioning operations. Accounts whose user IDs you specify in the exclusion list are not affected by reconciliation and provisioning operations.
In one of the lookup definitions for exclusion lists, enter the user IDs of target system accounts for which you do not want to perform provisioning and reconciliation operations. See Lookup Definitions for Exclusion Lists for MSSQL for information about the lookup definitions and the format of the entries in these lookups.
To add entries in the lookup for exclusions during provisioning operations for Oracle Database:
Note:
To specify user IDs to be excluded during reconciliation operations, add entries in the Lookup.DBUM.MSSQL.UM.ReconExclusions lookup definition.
Learn about action scripts and how to configure them to run before or after the create, update, or delete an account provisioning operations.
This section provides information about the following topics:
Actions are scripts that you can configure to run before or after the create, update, or delete an account provisioning operations. For example, you could configure a script to run before every user creation. In another scenario, suppose you have a table called AUDIT_USERLOG where you want to log user creation activities performed only by the connector. Then, you could create and use after create script for adding data to this table after create operation.
Note:
To configure a before or after action, your connector must support running scripts. An exception is Groovy (with target set to Connector), which the Identity Connector Framework (ICF) supports by default for all converged connectors.
Every connector should specify which scripting language and which target it supports. This connector supports the following script:
CMD: windows batch script and target: Connector
The target refers to the location where the script is executed. In this case, the script is executed on the same computer (JVM or .NET Runtime) where the connector is deployed. For example, if you deploy the connector on the connector server, the script will be executed on that computer.
That is, if you are using a local framework, the script runs in your JVM. If you are connected to a remote framework, the script runs in the remote JVM or .NET Runtime.