지금 지원 담당자와 채팅
지원 담당자와 채팅

Active Roles 7.6.3 - Synchronization Service Administration Guide

Synchronization Service Overview Deploying Synchronization Service Getting started Connections to external data systems
External data systems supported with built-in connectors
Working with Active Directory Working with an AD LDS (ADAM) instance Working with Skype for Business Server Working with Oracle Working with Exchange Server Working with Active Roles Working with One Identity Manager Working with a delimited text file Working with Microsoft SQL Server Working with Micro Focus NetIQ Directory Working with Salesforce Working with ServiceNow Working with Oracle Unified Directory Working with an LDAP directory service Working with IBM DB2 Working with IBM AS/400 Working with an OpenLDAP directory service Working with IBM RACF connector Working with MySQL database Working with an OLE DB-compliant relational database Working with SharePoint Working with Microsoft 365 Working with Microsoft Azure Active Directory Configuring data synchronization with the SCIM Connector Configuring data synchronization with the Generic SCIM Connector
Using connectors installed remotely Creating a connection Renaming a connection Deleting a connection Modifying synchronization scope for a connection Using connection handlers Specifying password synchronization settings for a connection
Synchronizing identity data Mapping objects Automated password synchronization Synchronization history Scenarios of use
About scenarios Scenario 1: Create users from a .csv file to an Active Directory domain Scenario 2: Use a .csv file to update user accounts in an Active Directory domain Scenario 3: Synchronizing data between One Identity Manager Custom Target Systems and an Active Directory domain Scenario 4: Deprovisioning between One Identity Manager Custom Target Systems and an Active Directory domain Scenario 5: Provisioning of Groups between One Identity Manager Custom Target Systems and an Active Directory domain Scenario 6: Enabling Delta Sync mode between One Identity Manager Custom Target Systems and an Active Directory domain Example of using the Generic SCIM Connector for data synchronization
Appendix A: Developing PowerShell scripts for attribute synchronization rules Appendix B: Using a PowerShell script to transform passwords

Synchronizing complex multi-value objects from a SCIM source system

Data synchronization workflows that import data with a connection based on the Generic SCIM Connector can import all three types of SCIM 2.0-based data entries:

  • Simple attributes, that is, data entries with a single simple value. For example, a user ID specified in a single string is a simple attribute.

  • Complex single-value attributes, that is, data entries specified with several sub-attributes. For example, the following name attribute is a complex single-value attribute, specifying the name of an employee with three simple sub-attributes:

    "name": {
    	"givenName": "Sam",
    	"familyName": "Smith",
    	"formatted": "Sam Smith"
    	 },

    The value of complex single-value attributes is the sum of the sub-attribute values.

  • Complex multi-value attributes, that is, data entries with multiple complex values, each of them specified with several simple sub-attributes. For example, the following addresses attribute is a complex multi-value attribute, specifying several addresses, each of them being a complex value containing several simple sub-attributes:

    "addresses": [
    	{
    		"type": "work",
    		"streetAddress": "22 Example Street",
    		"region": "Springfield",
    		"postalCode": "51487",
    		"country": "United States",
    		"primary": true
    	},
    	{
    		"type": "home",
    		"streetAddress": "12 Rue Exemple",
    		"region": "Montreal",
    		"postalCode": "46179",
    		"country": "Canada"
    	}
    ],

However, even though synchronization workflows using connections set with the Generic SCIM Connector can import all three of these value types, Active Roles Synchronization Service does not recognize complex single-value attributes and complex multi-value attributes, as they contain more values than what Active Roles Synchronization Service can identify for a single data entry by default.

To import complex single-value and multi-value attributes successfully, you can use the following methods:

  • For complex single-value attributes, you can map each individual sub-attribute of the complex single-value attribute to separate attributes in the target system. For example, in case of the name complex single-value attribute, you can map the givenName, familyName and formatted sub-attributes to separate name.givenName, name.familyName, and name.formatted attributes in the target system, respectively.

  • For complex multi-value attributes, you can use two methods:

    • When importing complex multi-value attributes, Active Roles Synchronization Service can take a single value (and its sub-attributes), map the sub-attributes to a set of target values (similarly to complex single-value attributes), then discard the rest of the complex values of the attribute.

      By default, Active Roles Synchronization Service takes the primary value of the complex multi-value attribute (marked with a specific primary sub-attribute). If no primary value is specified within the complex multi-value attribute, Active Roles Synchronization Service imports the first value (and its sub-attributes) only.

      NOTE: This method imports only the primary value (or the first value, if no primary value is specified). Active Roles Synchronization Service will discard all other values (and their sub-attributes).

    • If you map a complex multi-value attribute (such as the addresses attribute shown in the above example) when configuring a mapping rule for a workflow, you can configure an Active Roles Synchronization Service workflow to process and extract every value (and their sub-attributes) of the complex multi-value attribute with script-based attribute mapping.

      The following procedure will provide an example on how to apply such a PowerShell script to properly process the addresses complex multi-value attribute shown in this chapter.

To configure a custom PowerShell script for a workflow to import complex multi-value attributes

  1. In the Active Roles Synchronization Service, click Sync Workflow, then click the synchronization workflow that imports data from a SCIM-based source system (for example, the SuccessFactors HR to SQL Server workflow used in Creating a synchronization workflow for synchronizing data from a SCIM-based Starling Connect connector).

  2. Click the first step of the workflow (in the example SuccessFactors HR to SQL Server workflow, this is named Step 1 (Creation from SCIM Connection to SuccessFactors HR to SQL Connection).

  3. Under Creation Rules, to open the initial population rules, click Forward Sync Rule.

  4. In the Forward Sync Rule window, at the Source item setting, open the Attribute drop-down, and click PowerShell Script.

  5. In the PowerShell Script Editor, paste the following script example, and click OK:

    $addressesJsonArray = $srcObj["addresses"] | ConvertFrom-Json
    
    if ($addressesJsonArray) {
      for ($i = 0; $i -lt $addressesJsonArray.Length; $i++) {
        if ($addressesJsonArray[$i].type -eq "work") {
          return $addressesJsonArray[$i].streetAddress + ", " + $addressesJsonArray[$i].region + ", " + $addressesJsonArray[$i].locality
    	}
      }
    }

    The example script contains the following key parts:

    • $srcObj refers to the source object that the script will act on.

    • $srcObj["addresses"] extracts the raw value of the addresses attribute. In this example, this attribute is a complex multi-value SCIM attribute, so the attribute value will be a JSON array.

    • $addressesJsonArray is a .NET array object containing the values of the complex multi-value attribute.

    The rest of the script performs the following steps:

    1. It checks that the array is valid.

    2. It traverses the elements of the array, and looks for the first element with a type sub-attribute with a work value.

    3. Once it finds an element with a work value type, it constructs a formatted string from the streetAddress, region and locality sub-attributes.

    4. It returns the results.

  6. Use the output to parse and extract the data into other target values in the target system.

Appendix A: Developing PowerShell scripts for attribute synchronization rules

You can configure synchronization rules for such steps as creating, deprovisioning, or update. Synchronization Service provides a user interface (Synchronization Service Administration Console) that allows you to set up a direct or rules-based synchronization rule without any coding.

However, to set up a script-based synchronization rule, you must develop a Windows PowerShell script that will build values of the target object attributes using values of the source object attributes.

This section provides some reference materials on using the Windows PowerShell Script Host feature and provides the sample script.

Accessing source and target objects using built-in hash tables

Synchronization Service synchronizes data between the source and target objects using the pre-configured synchronization rules.

In the PowerShell scripts used to set up the script-based synchronization rules, you can employ the $srcObj and $dstObj built-in associative arrays (hash tables) that allow the scripts to access the current values of attributes of the source and target objects, respectively. The array keys names are names of the object attributes.

For more information about the use of the associative arrays, refer to Windows PowerShell documentation.

In addition to $srcObj and $dstObj, Synchronization Service defines the $Request built-in hash table. The $Request key names are also names of the object attributes. The $Request hash table contains new values of the target object attributes to which the target object attributes must be set after completing the synchronization process.

To clarify the use of built-in hash tables, let us consider the following scenario: you synchronize between the "mail" attributes of user objects in an LDAP directory (source connected system) and Active Roles (target connected system) using the following synchronization rule: the value of the "mail" attribute in the target connected system must be equal to that in the source connected system concatenated with current date.

For example, before the synchronization process started, the source object had the "mail" attribute: JDoe@mail1.mycompany.com, the target object had the "mail" attribute: JDoe@mail2009.mycompany.com. After the synchronization process completes, the target user will have the following mail: JDoe@mail1.mycompany.com (5 December, 2012) (if you performed the synchronization process on 5 December, 2012.

The following code snippet illustrates the use of built-in hash tables:

#Returns "JDoe@mail1.mycompany.com

$strSourceMail=$srcObj["mail"]

#Returns JDoe@mail2009.mycompany.com

$strTargetMail=$DstObj["mail"]

#Returns JDoe@mail1.mycompany.com (5 January, 2010)

$strNewMail=$Request["mail"]

Example script

The following script illustrates the use of $srcObj.

A creating task (creating step of a sync workflow as applied to Synchronization Service) causes Synchronization Service to create user identity information from a delimited text file to Active Directory using the following creating rule: the "co" attribute in all created users must be set to the name of country where the user lives. The script-based creating rule calculates the "co" attribute value basing on the user's city (the "City" attribute in the connected data source).

The following script implements the described scenario:

# --- Retrieve the City attribute of the user object in connected data source.

$userCity = $srcObj["City"]

# --- Determine the user's country

switch ($UserCity)

{

"New York" {$country = "United States"; break}

"Paris" {$country = "France"; break}

"Tokyo" {$country = "Japan"; break}

default {$country = "Unknown"}

}

# --- Return the user country. The script-based creating rule

# --- assigns this value to the "co" attribute in the created user object.

$country

# End of the script

관련 문서

The document was helpful.

평가 결과 선택

I easily found the information I needed.

평가 결과 선택