Directory Sync Pro for Active Directory 20.11.1

Profile Security Delegation Organizational Units Mail-Enabled and Non-Mail Enabled Users User Conflicts User SID History Groups Group Conflicts User Groups Devices Device Conflicts Exchange Migration Inter Forest Exchange Migration Email Address Policies Matching Options Attribute Mapping Reset Mappings

Sync Types Profile Actions Nodes Settings

General Settings General Object Settings User Object Settings Group Object Settings Device Object Settings

Advanced Settings

Matching Advanced Settings Mapped Fields Advanced Settings Exceptions Advanced Settings Overrides Advanced Settings

Logs and Reports

Logs Reports

Third Party Components Additional Topics

Command-line Sync Supporting a Mixed Exchange 2003, 2007, 2010, 2013, 2016 Environment Additional Configuration Options Using the User, Group, and Device LDAP filters Using the User and Group LDAP Filters Default Mappings Customizing Overrides Directory Sync Pro for Active Directory Fields with Special Processing AD Built-in Groups Handling How to Process GDPR Requests

Directory Sync Pro for Active Directory Fields with Special Processing

AD Directory Sync Pro for Active Directory Fields with Special Processing

The below tables include AD fields with some kind of special processing in Directory Sync Pro for Active Directory. Fields can have the following characteristics:

Cannot be mapped
Can be mapped and have an override
May be explicitly ignored or changed by Directory Sync Pro for Active Directory if object meets certain conditions, even if mapping and override exists
Actual attribute may be set via config file

Additional notes are available below for field marked with a *.

Writing Users to AD

Attributes that may be set by Directory Sync Pro for Active Directory regardless of mapping:

Field	Cannot be mapped	Can be mapped / have override	May be explicitly ignored	May be set with config file
distinguishedName	•
objectClass	•
userPassword		•
unicodePwd		•
userAccountControl		•
msExchRecipientDisplayType		•	•
msExchRecipientTypeDetails		•	•
msExchResourceDisplay		•
msExchResourceSearchProperties		•
msExchResourceMetaData		•
showInAddressBook*	•		•
msExchMasterAccountSid		•	•
msExchPoliciesExcluded	•		•
msExchPoliciesIncluded		•	•
userAccountControl	•		•
pwdLastSet	•
adminDescription	•			•

Special processing if mapped:

Field	Can be mapped / have override	May be explicitly ignored
mail	•	•
assistant*	•
manager*	•
managedBy*	•
altRecipient*	•
authoring	•
unauthOrig	•
dLMemSubmitPerms	•
dLMemRejectPerms	•
sAMAccountName*	•	•
legacyExchangeDN*	•	•
mailNickname	•	•

Never set:

Field	Cannot be mapped	Can be mapped / have override	May be explicitly ignored	May be set with config file
objectGUID	•
objectSid	•
whenCreated	•
whenChanged	•
uSNChanged	•
name	•
cn	•

Writing Groups to AD

Attributes that may be set by Directory Sync Pro for Active Directory regardless of mapping:

Field	Cannot be mapped	Can be mapped / have override	May be explicitly ignored	May be set with config file
objectClass	•
msExchRecipientDisplayType		•	•
msExchVersion		•
showInAddressBook*	•		•
msExchPoliciesExcluded	•		•
msExchPoliciesIncluded			•
adminDescription	•			•

Special processing if mapped:

Field	Can be mapped / have override	May be explicitly ignored
mail	•	•
assistant*	•
manager*	•
managedBy*	•
altRecipient*	•
authOring	•
unauthOrig	•
dLMemSubmitPerms	•
dLMemRejectPerms	•
sAMAccountName*	•	•
legacyExchangeDN*	•
groupType	•	•
mailNickname	•	•

Never set:

Field	Cannot be mapped	Can be mapped / have override	May be explicitly ignored	May be set with config file
objectGUID	•
objectSid	•
whenCreated	•
whenChanged	•
uSNChanged	•
name	•
cn	•

Special processing by Internal Field Name:

Field	Can be mapped / have override	If this internal field name is mapped and value is empty, actual value comes from different internal field
DisplayName	•	•
PrimaryAlias	•	•
SAMAccountName*	•	•
InternetAddress	•	•
Name	•	•
CommonName	•	•

Additional Notes

TargetDN – this column contains the distinguishedName of the target object to be created or the existing distinguishedName of a matched target object. If the object is created, the following values are used:
1. Non-group objects from AD sources use the DN column (or override value if specified) to compute a target object DN. This preserves the sub-OU hierarchy the object may be in from the source.
2. Groups from AD sources, use the OU column (or override value if specified) to compute a target object DN. This preserves the sub-OU hierarchy the object may be in from the source.
LegacyExchangeDN – the legacyExchangeDN of the target object is computed by constructing a value relative to the target Exchange organization.
ShowInAddressBook – unless hiding from GAL is enabled. No override column is available for this field. To prevent overwriting object values in the target, GAL visibility for the ShowInAddressBook attribute should be set to Hidden.
1. Rooms are added to the All Rooms address book, except for Exchange 2003 which doesn't have rooms or the All Rooms address book.
2. Users are added to the All Users address book.
3. Groups are added to the All Groups address book.
4. All objects are added to the All Global Address Lists (GAL) address book.
Manager – all objects except Groups
1. Uses the Manager column (or override value if specified) for the source object.
2. Locates the referenced Manager in the target.
3. If the referenced Manager is a reference to itself, the Manager on the target object will be set on the next sync.
ManagedBy – group objects only
1. Uses the ManagedBy column (or override value if specified) for the source object.
2. Follows the same process as Manager above.
Assistant – all objects
1. Uses the Assistant column (or override value if specified) for the source object.
2. Follows the same process as Manager above.
AltRecipient – all objects
1. Uses the AltRecipient column (or override value if specified) for the source object.
2. Follows the same process as Manager above.
sAMAccountName – The sAMAccountName may be calculated under special circumstances, such as when a collision occurs. For this reason, during a sync following a reset, repush, or repushpull, the existing sAMAccountName in the target will be assumed to be current and therefore will be used in any mappings involving the sAMAccountName internal field.

AD Built-in Groups Handling

Directory Sync Pro for Active Directory automatically ignores certain AD built-in groups during sync. The definition of which built-in groups to ignore is held in the database table DirSync_GroupsToIgnore_PK. This table is created and populated during the install process of Directory Sync Pro for Active Directory and is not configurable from the product UI. This list of groups can be modified only with direct access and permissions to SQL. When Directory Sync Pro for Active Directory performs a sync, any group encountered that matches with a group named in the DirSync_GroupsToIgnore_PK table is skipped and not entered into the database. This built-in group handling functionality is separate from the blacklisting functionality for groups which can be configured by an operator through the product UI, so when ignored these built-in groups are not considered to be ‘blacklisted’.

How to Process GDPR Requests

What is a GDPR Request?

The General Data Protection Regulations (GDPR) is the new European Union (EU) data protection regulations which go into effect May 25th, 2018. Under the GDPR individuals have certain rights to their personal data. They can make requests to exercise those rights to the data controller, and the controller must respond within 1 month. It is expected that the controller will verify the identity of the requestor.

There are four primary types of GDPR requests:

Export – Request for a copy of all personal data about an individual held by this controller and any related processors. Must be in a commonly accepted portable data format.
Update – Request to rectify inaccurate personal data.
Delete – Request to remove all personal data about an individual from our systems. Can be initiated by an individual or by a revocation of consent process. Includes burden of proof. (Ideally follow a delete with an export to show no remaining data)
Hold – Request to halt processing of personal data but not delete that data.

How to handle GDPR Requests for Directory Sync Pro for Active Directory

When Directory Sync Pro for Active Directory is installed, the data associated with the application is hosted locally within the client’s environment. The client has full control over this data. By default, the user and configuration data is stored in the SQL database called, “DirectorySyncPro_<date>”. It is assumed the operator has the proper administrative SQL Permissions to execute the following methods outlined.

SQL Tables containing User data:

[DirectorySyncPro_<Date>].[dbo].[BT_Person]

Unique Key Look-up Columns:

     [SAMAccountName]

     [TargetSAMAccountName]

     [TargetUserPrincipalName]

     [OriginalSAMAccountName]

     [OriginalUserPrincipalName]

     [UserPrincipalName]

If user data is used for matching (e.g. SAMAccountName, UserPrincipalName, etc.) then those values will also appear in one of the following columns:

     [MatchValue1]

     [MatchValue2]

     [MatchValue3]

     [MatchValue4]

[DirectorySyncPro_<Date>].[dbo].[BT_Groups]

Unique Key Look-up Columns:

     [MatchValue1]

     [MatchValue2]

     [MatchValue3]

     [MatchValue4]

Be aware that data can be mapped to different Internal Fields (table columns) depending on customer specific configuration, so just about any SQL column could theoretically contain user data if so configured. For example, if SAMAccountName has been mapped to Custom001 or to any other Internal Field selectable in the mappings. Therefore this process should be undertaken by someone knowledgeable about the schema and attribute mappings in use. It may also be helpful to work with Support when completing these requests if you are not comfortable with the database.

Where does the Directory Sync Pro for Active Directory get its user data?

All user data within Directory Sync Pro for Active Directory is derived from the source Active Directory Forest configured in the product. Therefore, the authoritative source of any user related data stored in Directory Sync Pro for Active Directory is Active Directory. Any remediation required from a GDPR request should first be remediated in Active Directory or the source feeding Active Directory. Once that user data is updated in the source directory, running a new discovery within the product will update those values as well.

The following sections will provide guidance on fulfilling the 4 primary GDPR request types.

1. Exports – Request for a copy of all personal data about an individual held by this controller and any related processors. Must be in a commonly accepted portable data format.

For the purposes of this document, using PowerShell with the SQLPS Module is the recommended method to refine the results of the output. One may export any SQL Query result to a CSV file. Below is an example script to do so. Replace the variables to conform to your environment.

Import-Module sqlps

$SQLquery='SELECT * FROM [DirectorySyncPro_<Date>].[dbo].[BT_Person]'

$result=invoke-sqlcmd -query $SQLquery -serverinstance <servername> -database <dbname>

$result |export-csv c:\temp\ExportQueryResults.csv -notypeinformation

2. Updates – Request to rectify inaccurate personal data.

As previously stated, all user data within Directory Sync Pro for Active Directory is derived from the source Active Directory Forest configured in the product. Therefore, the authoritative source of user data is Active Directory. Any remediation required from a GDPR request should first be remediated in Active Directory or the source feeding Active Directory.

If editing the user data within SQL is still required, using any SQL editor such as SQL Server Management Studio, run an update command against one or more columns for one or more records. Below are examples to accomplish this. Note however, that any new discovery will update the values based on the source Active Directory.

Update multiple columns for a single record:

UPDATE [DirectorySyncPro_<Date>].[dbo].[BT_Person]

SET <Column1 Name> = <New Value1>, <Column2 Name> = <New Value2>

WHERE userPrincipalName='<Unique ID>'

UPDATE [DirectorySyncPro_<Date>].[dbo].[BT_Person]

SET <Column1 Name> = <New Value1>, <Column2 Name> = <New Value2>

WHERE userPrincipalName='<Unique ID>'

Update multiple columns for multiple records:

UPDATE [DirectorySyncPro_<Date>].[dbo].[CMTEUP_Person]

SET <Column1 Name> = <New Value1>, <Column2 Name> = <New Value2>

WHERE DistinguishedName='<Unique ID>' OR DistinguishedName='<Unique ID>'

UPDATE [DirectorySyncPro_<Date>].[dbo].[CMTEUP_PersonADData]

SET <Column1 Name> = <New Value1>, <Column2 Name> = <New Value2>

WHERE userPrincipalName='<Unique ID>' OR userPrincipalName='<Unique ID>'

Update multiple columns for multiple records using a list:

UPDATE [DirectorySyncPro_<Date>].[dbo].[BT_Person]

SET <Column1 Name> = <New Value1>, <Column2 Name> = <New Value2>

WHERE DistinguishedName IN ('<Unique ID1>', '<Unique ID2>', '<Unique ID3>')

UPDATE [DirectorySyncPro_<Date>].[dbo].[BT_Person]

SET <Column1 Name> = <New Value1>, <Column2 Name> = <New Value2>

WHERE userPrincipalName IN ('<Unique ID1>', '<Unique ID2>', '<Unique ID3>')

3. Deletes – Request to remove all personal data about an individual from our systems. Can be initiated by an individual or by a revocation of consent process. Includes burden of proof. (Ideally follow a delete with an export to show no remaining data.)

Using any SQL editor such as SQL Server Management Studio, run a Delete command against one or more records. Below are examples to accomplish this. However, as previously stated, if the user is not deleted in the source Active Directory during any subsequent new discovery the user will be re-populated into SQL. The only way to truly remove the data is to delete the source user or delete the entire SQL database when it is no longer required.

Delete a single record then verify: