Windows Connector

• Windows Connector
• HOWTO SSL access to Active Directory
• Invoker interface for Active Directory
• Active Directory back channel configuration
• AD Integration flows - Update user
• AD Integration flows - Update account

Windows Connector

Introduction

Description

This connector implements the LDAPS protocol and it is used to connect the Sync-Server with every server that allows this communication protocol.

Managed System

This connector has been performed to connect to the Active Directory system, it's a fork of our LDAP Connector with custom features.

For more information to check if your system may be synchronized with this connector you do not hesitate to contact us through our Contact form

Prerequisites

To enable LDAPS in your Active Directory, please read the following guide: SSL access to Active Directory.

It is needed an Active Directory user with full administrator access.

Download and Install

This addon is located in the Connectors section and its name is Windows (including Active Directory).

For more information about the installation process you can visit the Addons Getting started page.

Agent Configuration

Basic

Generic parameters

After the installation of the addon, you may create and configure agent instances.

This addon has 5 available agents:

• Active Directory
• Active Directory Only Passwords
• Simple Windows Agent
  

For more information about how you may configure the generic parameters of the agent, see the following link: Agents configuration

Custom parameters

Below there are the specific parameters for this agent implementation, "Active Directory"

• Host name of the domain controller.
• Active Directory distingished name in X500 format. e.g.: dc=soffid,dc=local
• Administrator principal name in X500 format, relative to A.D name. e.g.: cn=Administrator,cn=Users
• Administrator password

Attribute mapping

Active Directory connector could manage Users and Groups by using LDAPS protocol.

Properties

Some agents require to configure some custom attributes, you will use the properties section to do that.

To enable it, add the following properties to each object mapping:

For instance:

Attributes

You can customize attribute mappings, you only need to select system objects and the Soffid objects related, manage their attributes, and make either inbound or outbound attribute mappings.

Using a windows connector you can map users, groups, and role objects. Active Directory membership is automatically managed based on user and group mappings.

Any object mapping must have the following system attributes:

There is a bunch of AD special attributes that need some special treatment:

if ( attributes {"expirationDate"} == null)
   return 9223372036854775807L;
else
   return attributes{"expirationDate"}.getTime() * 10000L + 116445528000000000L;

if ( lastLogon == null || lastLogon == void) return null;
Long v = Long.decode(lastLogon);
v = v / 10000000L;
v-=11644473600L;
return new Date(v*1000);
=>
lastLogin

For more information about how you may configure attribute mapping, see the following link: Soffid Attribute Mapping Reference

For instance:

Triggers

You can define BeanShell scripts that will be triggered when data is loaded into the target system (outgoing triggers). The trigger result will be a boolean value, true to continue or false to stop.

Triggers can be used to validate or perform a specific action just before performing an operation or just after performing an operation on target objects. 

To view some examples, visit the Outgoing triggers examples page.

Avoid incremental load authoritative

The Customizable Active Directory connector has an incremental load authoritative process. 

When this process is executed, it requests the changes to Active Directory after the uSNChanged. 

The value of this field is saved in Soffid in the parameter soffid.sync.authoritative.change.NAME_OF_THE_AGENT

If you want to launch a complete load authoritative process, remove this parameter first. At the end of the process, the parameter will be generated automatically.

For more information, go to the Soffid Parameters page.

HOWTO SSL access to Active Directory

Table of Contents

• Introduction.
• Installing the Certificate Services.
• Configuring Automatic Certificate Request for Domain Controllers.
• Check for Issued Certificate.
• Import certificate.

Introduction

This howto will show you how to install the Certificate Services in Windows Acive Directory Servers.

Before beginning, make sure the Internet Information Server (IIS) is installed in your server.

Installing the Certificate Services

1. Click Start, select Control Panel and click Add or Remove Programs.

2. In the Add or Remove Programs window, click Add/Remove Windows Components, check the Certificate Services and click Next.

3. Click Next in the CA Type page.

4. Fill up the Common name for this CA and click Next.

5. Click Next in the Certificate Database Settings page.

6. The Certificate Services will now be installed.

7. Click Finish and restart your server.

Configuring Automatic Certificate Request for Domain Controllers

1. Click Start, select Administrative Tools and click Domain Controller Security Policy.

2. In the Default Domain Controller Security Settings window, click the Public Key Policies folder.

3. Right click Automatic Certificate Request Settings, select New and click Automatic Certificate Request.

4. Click Next in the Automatic Certificate Request Setup Wizard

5. Select Domain Controller in the Certificate Template page and click Next

6. Click Finish and reboot your server.

Check for Issued Certificate

1. Click Start, select Administrative Tools and click Certification Authority. This will launch the Certification Authority application.

2. In Certification Authority, click the + sign and check the Issued Certificates folder if your server has been issued a certificate.

Import certificate

1. Select the certificate and open it. Select the "Certification Path" tab and select the root certificate.

2. Click on "View Certificate" button and navigate to "Details" tab.

3. Click on "Copy to File..." button and follow the export steps to obtain the certificate.

4. Open cmd and go to the soffid-iam-sync instalation directory and execute:

jre\bin\keytool -import -file “file” -keystore conf\cacerts -alias AD_CERT

Afterwards, the console will ask you for a password. Type the default password: changeit and press enter.

Invoker interface for Active Directory

Any agent, trigger or mapping can use the invoker method for the ActiveDirectory agent. The invoker method is available in the dispatcherService class.

The invoker method is not specific of the Active Directory agent. Many other connectors support this method. The expected arguments are:

• Action
• Object name
• Parameters

Here you have an example of a post-update trigger to create the home server for a user:

map = new HashMap();
String server = "//"+source{"homeServer"}+"/"+source{"accountName"};
// Create folder
f = dispatcherService.invoke("smb:mkdir", server, map);
   
// Add administrator ACL
map.put("user", "soffid_admin");
map.put("permission", "GENERIC_ALL");
map.put("flags", "CONTAINER_INHERIT_ACE OBJECT_INHERIT_ACE");
f = dispatcherService.invoke("smb:addacl", path, map);
 
// Add user ACL
map.put("user", source{"accountName"});
f = dispatcherService.invoke("smb:addacl", path, map);
// Change folder ownership using a domain admin account
map.put("_auth_user", "user1");
map.put("_auth_domain", "domain1");
map.put("_auth_password", "SuperSecret");
f = dispatcherService.invoke("smb:setOwner", path, map);

The example above uses the smb:mkdir action to create the folder, the smb:addacl to add a new access control list entry. Other commands allow the query and modification of Active Directory objects like users and groups.

The list of allowed commands are:

By default, actions are performed by the account used to configure the AD connector, but sometimes, another account must be used, mainly when dealing with NAS servers. In order to user custom credentials SMB commands accept three special parameters: _auth_user, _auth_password and _auth_domain. If this parameters are null, the agent user and password is used.

Active Directory back channel configuration

Introduction

Active Directory Back Channel refers to a mechanism that allows Soffid to synchronize user information with an external Active Directory (AD) server in real-time or near real-time (Password synchronizer). This synchronization ensures that both Soffid and AD maintain consistent and up-to-date data.

How it works?

1. The AD sends the password to Soffid to verify that it complies with Soffid policy.
2. If it complies, the password is updated in the AD.
3. The password is sent to Soffid and the PropagatePassword task is created.
4. If the AD agent confirms that the new password has been saved, Soffid synchronizes it with the other systems.

How to install Active Directory back channel?

Download

In order to configure the Active Directory back-channel, you must use the eris command line tool. To do this, please, download the Password Synchronizer from our download portal:

Install

First of all, you must install the Windows package "Password synchronizer-3.0.x.msi"

Once installed Password Synchronizer on your system, please change to eris or eris64 directory (\ProgramFiles\Soffid\eris64) and execute:

eris-ad-service install

Configure

Finally, you must configute the Password Synchronizer executing the following command:

eris-ad-service CONFIGURE url-syncserver agent-name

• url-syncserver is the master sync server url (http://master.dom.dom:port)
• agent-name is the agent code name configured on Soffid console.

To see more information when configuring use | more. 

Example

eris-ad-service CONFIGURE https://sync-server.netcompose:1760/ "AD soffid.pat" | more

Test configuration

In order to test configuration, you must use the eris command line tool.

eris-ad-service TEST user pass

Where user and pass can be dummy. If you use a real one it will be propagated to the system.

To see more information during test use | more.

Example

eris-ad-service TEST aretha password | more

AD Integration flows - Update user

Update

Introduction

Soffid provides a workflow to modify and/or delete a user in the final system. In it, we can see each of the steps of which this process is composed. 

Diagram

Step by Step

In this document, we will explain the process that Soffid performs to modify a user for the AD connector.

1. Initial step

First of all, Soffid checks if the user exists in Soffid and then checks the operation to perform, update or delete. 

1.1. If the user does not exist in Soffid, then Soffid asks to delete the user in the target System. 

❓ Warning message

1.1.1. Yes: If the answer is Yes, the process follows through the Yes branch, [3. Delete branch].

1.1.2. No:  If the answer is Yes, the process finishes [10. End]. 

1.2. If the user exists in Soffid, the process continues through [2. User to remove?]. to check if the 

2. User to remove?

2.1. If the user is marked for Deletion, Soffid will ask for user consent to continue with the process or to cancel it. If the answer is Yes, the process follows through the Yes branch, [3. Delete branch].

❓ Warning message

2.2. If the user is marked for Update, it continues with the flow following through the No branch, [4. Insert or Update branch].

3. Delete branch

3.1. When the operation to perform is to delete a user, first of all, Soffid has to check if the user exists in the target system. 

3.1.1. If the user does not exist, there are no actions to perform in the target system, so the process finishes [10. End].

3.1.2. If the user exists, the flow continues executing the pre-delete triggers if there is anyone configured. More than one script can be configured. These scripts are executed just before the main action, user delete, and the result (true or false) determines if the main action will be performed or not.

3.1.2.1. False: if the result is false for one or more of these triggers, the process finishes [10. End].

3.1.2.2.True: if the result is true for all of these triggers, Soffid continues to the next step.

3.1.3. Soffid removes the AD user in the Active directory.

3.1.3.  Then Soffid executes the post-delete triggers if any. These triggers can be used to perform a specific action just after performing the remove user operation on the target object.

3.1.3.  Then the process finishes [10. End].

4. Insert or Update branch

4.1. When the operation to perform is to update a user, first of all, Soffid generates the AD user.  That is, Soffid calculates the values of the AD user object from the original values of Soffid.

4.2.Then Soffid asks if the user exists in the target system to decide the action to execute, this action can be an update or an insert. 

4.2.1. If the user does not exist in the target system, the process continues through [5. Insert user branch]. 

4.2.2. If the user exists in the target system, the process continues through [6. Update user branch].

5. Insert user branch

5.1. Soffid executes the pre-insert triggers if there is anyone configured. More than one script can be configured. These scripts are executed just before the main action, user creates, and the result (true or false) determines if the main action will be performed or not.

5.1.1. False: if the response is false for one or more of these triggers, the process finishes [10. End] and the user is not created in the target system.

5.1.2. True: if the response is true for all of these triggers, Soffid continues to the next step.

5.2. Soffid creates AD user in the Active directory

5.3. Then Soffid executes post-insert triggers if any. These triggers can be used to perform a specific action just after performing the create user operation on the target object.

5.4. Then the process continues through [7. Groups].

6. Update user branch

6.1. Soffid checks if there are any change between the generated object and the values of the object in the target system.

6.1.1. False: if there are no changes,  the process finishes [10. End].

6.1.2. True: if there are changes to update, Soffid continues to the next step.

6.2. Soffid executes the pre-update triggers if there is anyone configured. More than one script can be configured. These scripts are executed just before the main action, user update, and the result (true or false) determines if the main action will be performed or not.

6.2.1. False: if the response is false for one or more of these triggers, the process finishes [10. End] and the user is not updated in the target system

6.2.2. True: if the response is true for all of these triggers, Soffid continues to the next step.

6.3. Soffid updates the AD user in the Active directory

6.4. Then Soffid executes the post-update triggers if any. These triggers can be used to perform a specific action just after performing the update user operation on the target object.

6.6. Then the process continues through [7. Grants].

7. Grants

At this point, Soffid runs the actions relative to the grants. The operations can be to add the user to one or more groups or to remove the user from existing groups.

8. Group to remove

This is a loop while there are groups to remove.

8.1. If there are No groups to remove, the process goes to [9. Group to add].

8.2. Yes, there are groups to remove:

8.2.1. Soffid executes the pre-delete triggers if there is anyone configured. More than one script can be configured. These scripts are executed just before the main action, a Remove user to group, and the result (true or false) determines if the main action will be performed or not.

8.2.1.1. False: if the response is false for one or more of these triggers, the process goes to [8. Group to remove] and the grant is not created.

8.2.1.2. True: if the response is true for all of these triggers, Soffid continues to the next step.

8.2.3. If the result of the triggers is true, then Soffid adds the user to a group. 

8.2.4. Then Soffid executes the post-insert triggers if any. These triggers can be used to perform a specific action just after performing the create grant operation on the target object.

8.2.5.  Then the process continues through  [8. Grant to add].

9. Group to add

This is a loop while there are grants to remove. This grants list comes from the previous step [7. Grants].

9.1 No: If there are No grants to add, the process goes to [10. End].

9.2. Yes,  there are grants to remove:

9.2.1. Soffid executes the pre-insert triggers if there is anyone configured. More than one script can be configured. These scripts are executed just before the main action, Add user to group, and the result (true or false) determines if the main action will be performed or not.

9.2.1.1. False: if the response is false for one or more of these triggers, the process finishes [10. End] and the grant is not deleted.

9.2.1.2. True: if the response is true for all of these triggers, Soffid continues to the next step.

9.2.2. If the result of the triggers is true, then Soffid adds the user to the group. This operation can return a true or false result.

9.2.2.1. False: the add action could not be performed and the process check for another grant [9. Group to add].

9.2.2.2. True: the add action could be performed properly. Soffid continues to the next step.

9.2.3. Then Soffid executes the post-insert triggers if any. These triggers can be used to perform a specific action just after performing the add grant operation on the target object.

9.2.4. Then the process continues through [9. Group to add].

10. End

The process finishes and the log is displayed, and you can download it by clicking the Download button.

AD Integration flows - Update account

Update

Introduction

Soffid provides a workflow to modify and/or delete an account in the final system. In it, we can see each of the steps of which this process is composed. 

Diagram

Step by Step

In this document, we will explain the process that Soffid performs to modify an account for the AD connector.

1. Initial step

First of all, Soffid checks if the account exists in Soffid and then checks the operation to perform, update or delete. 

1.1. If the user does not exist in Soffid, then Soffid asks to delete the user in the target System. 

❓ Warning message

1.1.1. Yes: If the answer is Yes, the process follows through the Yes branch, [3. Delete branch].

1.1.2. No:  If the answer is Yes, the process finishes [10. End]. 

1.2. If the user exists in Soffid, the process continues through [2. User to remove?]. to check if the 

2. Account to remove?

2.1. If the account is marked for Deletion, Soffid will ask for user consent to continue with the process or to cancel it. If the answer is Yes, the process follows through the Yes branch, [3. Delete branch].

❓ Warning message

2.2. If the account is marked for Update, it continues with the flow following through the No branch, [4. Insert or Update branch].

3. Delete branch

3.1. When the operation to perform is to delete an account, first of all, Soffid has to check if the account exists in the target system. 

3.1.1. If the account does not exist, there are no actions to perform in the target system, so the process finishes [10. End].

3.1.2. If the account exists, the flow continues executing the pre-delete triggers if there is anyone configured. More than one script can be configured. These scripts are executed just before the main action, account delete, and the result (true or false) determines if the main action will be performed or not.

3.1.2.1. False: if the result is false for one or more of these triggers, the process finishes [10. End].

3.1.2.2.True: if the result is true for all of these triggers, Soffid continues to the next step.

3.1.3. Soffid removes the AD user in the Active directory.

3.1.3.  Then Soffid executes the post-delete triggers if any. These triggers can be used to perform a specific action just after performing the remove user operation on the target object.

3.1.3.  Then the process finishes [10. End].

4. Insert or Update branch

4.1. When the operation to perform is to update a user, first of all, Soffid generates the AD user.  That is, Soffid calculates the values of the AD user object from the original values of Soffid.

4.2.Then Soffid asks if the user exists in the target system to decide the action to execute, this action can be an update or an insert. 

4.2.1. If the user does not exist in the target system, the process continues through [5. Insert user branch]. 

4.2.2. If the user exists in the target system, the process continues through [6. Update user branch].

5. Insert user branch

5.1. Soffid executes the pre-insert triggers if there is anyone configured. More than one script can be configured. These scripts are executed just before the main action, user creates, and the result (true or false) determines if the main action will be performed or not.

5.1.1. False: if the response is false for one or more of these triggers, the process finishes [10. End] and the user is not created in the target system.

5.1.2. True: if the response is true for all of these triggers, Soffid continues to the next step.

5.2. Soffid creates AD user in the Active directory

5.3. Then Soffid executes post-insert triggers if any. These triggers can be used to perform a specific action just after performing the create user operation on the target object.

5.4. Then the process continues through [7. Groups].

6. Update user branch

6.1. Soffid checks if there are any change between the generated object and the values of the object in the target system.

6.1.1. False: if there are no changes,  the process finishes [10. End].

6.1.2. True: if there are changes to update, Soffid continues to the next step.

6.2. Soffid executes the pre-update triggers if there is anyone configured. More than one script can be configured. These scripts are executed just before the main action, user update, and the result (true or false) determines if the main action will be performed or not.

6.2.1. False: if the response is false for one or more of these triggers, the process finishes [10. End] and the user is not updated in the target system

6.2.2. True: if the response is true for all of these triggers, Soffid continues to the next step.

6.3. Soffid updates the AD user in the Active directory

6.4. Then Soffid executes the post-update triggers if any. These triggers can be used to perform a specific action just after performing the update user operation on the target object.

6.6. Then the process continues through [7. Grants].

7. Grants

At this point, Soffid runs the actions relative to the grants. The operations can be to add the user to one or more groups or to remove the user from existing groups.

8. Group to remove

This is a loop while there are groups to remove.

8.1. If there are No groups to remove, the process goes to [9. Group to add].

8.2. Yes, there are groups to remove:

8.2.1. Soffid executes the pre-delete triggers if there is anyone configured. More than one script can be configured. These scripts are executed just before the main action, a Remove user to group, and the result (true or false) determines if the main action will be performed or not.

8.2.1.1. False: if the response is false for one or more of these triggers, the process goes to [8. Group to remove] and the grant is not created.

8.2.1.2. True: if the response is true for all of these triggers, Soffid continues to the next step.

8.2.3. If the result of the triggers is true, then Soffid adds the user to a group. 

8.2.4. Then Soffid executes the post-insert triggers if any. These triggers can be used to perform a specific action just after performing the create grant operation on the target object.

8.2.5.  Then the process continues through  [8. Grant to add].

9. Group to add

This is a loop while there are grants to remove. This grants list comes from the previous step [7. Grants].

9.1 No: If there are No grants to add, the process goes to [10. End].

9.2. Yes,  there are grants to remove:

9.2.1. Soffid executes the pre-insert triggers if there is anyone configured. More than one script can be configured. These scripts are executed just before the main action, Add user to group, and the result (true or false) determines if the main action will be performed or not.

9.2.1.1. False: if the response is false for one or more of these triggers, the process finishes [10. End] and the grant is not deleted.

9.2.1.2. True: if the response is true for all of these triggers, Soffid continues to the next step.

9.2.2. If the result of the triggers is true, then Soffid adds the user to the group. This operation can return a true or false result.

9.2.2.1. False: the add action could not be performed and the process check for another grant [9. Group to add].

9.2.2.2. True: the add action could be performed properly. Soffid continues to the next step.

9.2.3. Then Soffid executes the post-insert triggers if any. These triggers can be used to perform a specific action just after performing the add grant operation on the target object.

9.2.4. Then the process continues through [9. Group to add].

10. End

The process finishes and the log is displayed, and you can download it by clicking the Download button.