Tutorial #1 - Merge Users From Multiple Directories

Click here to download this tutorial as a PDF file.

1 Overview

There can be many reasons why an organization would need to take users from many systems and present them as a single tree. In many large enterprises, some users may exist in one database or directory while another group of users exists on a separate system. For example, a lot of HR systems will contain employee records only. These systems frequently exclude contractors and temporary employees. However, there are applications, such as address books, that require information about users contained in all of the systems in an organization. Most of these applications are designed to only read from a single source repository. The Virtual Directory Server (VDS) solves this problem by presenting users from multiple systems on a single virtual tree accessible from one system. In this tutorial, the users from multiple directories are going to appear to exist in a single directory branch accessible from the Virtual Directory Server.

2 Assumptions

Virtual Directory Server is installed and configured properly; VDS is currently running.
Directory 1 & 2 are both installed and accessible from the computer on which Virtual Directory Server is installed.
Both of your directories are populated with users.
None of the users in Directory 1 exist in Directory 2 and vice versa.
Directory 1 & 2 are both accessible on port 389 (default ldap port)
You have a good understanding of the DIT structure of your directories.
Port 3890 is available on the computer in which Virtual Directory Server is installed.

3 Create a New Configuration

Click File on the menu bar, then click New.
Click the OK button to select the option to create a Local configuration.
Enter MergeTreesTutorial for the filename when prompted, then click the Save button and the following will appear:

Fig-1: Create a new configuration

4 Server Group Configuration

Server Groups are the directories and / or databases where your user information is stored. Examples include Active Directory, Sun Directory Server and Oracle database. For this tutorial we will be creating two Server Groups, one for Directory 1 and another for Directory 2.

4.1 Add Directory 1

Click on the Output button on the left-hand side of the application and the following will appear:

Fig-2: Click on the Output node to Add a Server Group
Click on the New Server Group button near the bottom of the screen.
Enter Directory 1 for your new Server Group and leave the Server Group Type as Automatic and then click the Okay button.
Click on the Directory 1 node in the navigator tree on the left-hand side of the screen and the following will appear:

Fig-3: Configure the first Server Group
Verify that the Protocol is set to ldap.
Under the Servers tab, enter the Hostname / IP Address and the Port of Directory 1.
Click on the Connection Pooling tab and check the Use Connection Pooling checkbox. The following will appear:

Fig-4: Configure Connection Pooling for the first Server Group
Click on the Use Fixed Credentials radio button then enter the Bind DN and Password for the user that has appropriate access to Directory 1.
Change the number of Pool Connections from 10 to 2.
Click the OK button near the top of the application to save the Directory 1 Server Group Configuration.

4.2 Add Directory 2

Click on the Output button on the left-hand side of the application and the following will appear:

Fig-5: Click on the Output button to Add a second Server Group
Click on the New Server Group button near the bottom of the screen.
Enter Directory 2 for your new Server Group and leave the Server Group Type as Automatic and then click the Okay button.
Click on the Directory 2 node in the navigator tree on the left-hand side of the screen and the following will appear:

Fig-6: Configure the second Server Group
Verify that the Protocol is set to ldap.
Under the Servers tab, enter the Hostname / IP Address and the Port of Directory 2.
Click on the Connection Pooling tab and check the Use Connection Pooling checkbox. The following will appear:

Fig-7: Configure the Connection Pooling for the second Server Group
Click on the Use Fixed Credentials radio button then enter the Bind DN and Password for the user that has appropriate access to Directory 2.
Change the number of Pool Connections from 10 to 2.
Click the OK button near the top of the application to save the Directory 2, Server Group Configuration.

5 Processing Configuration

At this point, we are ready to configure the Virtual Directory Server instance to provide the functionality that we want. In order to do this, we will set up a "Processing Stage" where all packets moving through Virtual Directory Server can be analysed to see whether particular functionality should be applied. In any single VDS deployment, you can have multiple Processing Stages that implement different functionality depending on the PDUs that pass through the system. In this tutorial, however, we will be implementing a single Stage. This stage is going to utilize a default plugin that will merge users from two directories into one virtual directory. This plugin is called the Merge Trees plugin and is provided by the Virtual Directory Server to allow you to quickly and easily implement the functionality that you're looking for.

Click on the Processing button on the left-hand side of the application and the following will appear:

Fig-8: Click on the Processing node
Click on the New Stage button near the bottom of the screen.
Enter Merge Users as the name of the new stage and leave the stage type as Automatic and then click the Okay button.
Click on the "stage=Merge Users" node on the left-hand side of the screen.
Click on the Add Plugin button and the following will appear:

Fig-9: Add the Merge Trees plugin
Scroll to the bottom of the list, click on Merge Trees and click the OK button.
Click the Merge Trees node in the navigator on the left-hand side of the screen and the following will appear:

Fig-10: Configure the Merge Trees plugin
Under the Merge Tree Configuration section, double-click the blank box under Server Group and select Directory 1 from the drop-down menu.
Under the Merge Tree Configuration section, double-click the blank box under DN of Tree to merge and enter the DN(s) of the tree(s) in Directory 1 that you'd like to have merged into the VDS (e.g. cn=AllUsers,dc=company,dc=com).
Repeat steps 8 & 9 for Directory 2.
Under the Merge Tree Configuration section, enter the DN for your new VDS in the Joined Tree DN text box. This will be the DN that contains all of your users from both Directory 1 and 2 that you have decided to merge in steps 8-10 above. This will also be the Base DN you specify when configuring a LDAP browser or application to connect to the VDS.
Under the Condition section, enter the DN for your new VDS in the BaseDN text box. Note that this DN should be identical to the Joined Tree DN specified in the step above.
Click the OK button near the top of the application to save the Processing Configuration.

6 Listener Configuration

Click on the Input button on the left-hand side of the application and the following will appear:

Fig-11: Click on the Input node to add a Listener
Click on the New Listener button near the bottom of the screen.
Enter Merge Users for the new input / listener and then click the Okay button.
Click on the Merge Users node under the Input part of the configuration on the left-hand side of the screen and the following will appear:

Fig-12: Configure the new Listener
Under the Main Listener Properties tab, make sure the Protocol is set to ldap.
Under the Main Listener Properties tab, set the port to 3890.
Under the Main Listener Properties tab, select Directory 1 from the dropdown box to the right of Default Server Group.
Click on the Attached Stages tab and the following will appear:

Fig-13: Attach the Processing Stages to the Listener
Double-click where it shows to do so and click on "stage=Merge Users" in the dropdown box.
Click the OK button near the top of the screen to save the Listener configuration.

7 Save Configuration

When you created the new configuration you were prompted to enter a filename for your configuration. The file type for this file is ldif. The configuration must be saved before the VDS can be launched for the first time. Also, the configuration must be saved and the VDS re-launched before changes to the configuration will take effect.

Click on the File button on the menu bar.
Click Save and your configuration will then be ready to launch.

8 Launch and Test Configuration

Click the Process button on the menu bar.
Click Run on the drop-down menu. At this point the VDS is running and is ready to accept LDAP requests.
Click the Extras button on the menu bar.
Click LDAP Browser on the drop-down menu and the following will appear:

Fig-14: Use the LDAP Browser to connect to your running Virtual Directory Server instance
In the Name textbox, enter Merge Users.
In the Hostname textbox, enter the IP Address of the computer that VDS is installed on.
In the Port textbox, enter 3890.
In the Root Suffix textbox, enter the Joined Tree DN you specified during the Processing Configuration section of this tutorial.
In the Bind DN textbox, enter the DN of the user that has appropriate access Root Suffix / Joined Tree DN in the step above.
Enter the Password twice for the user specified in the step above.
Click the Test button to verify that you can properly bind to the Joined Tree DN.
Assuming you entered the correct information, a Test Successful! message will appear. Click the OK button.
Click the OK button on the next page and you will be asked if you would like to save Merge Users. Click the Yes button and the Joined Tree DN you specified will appear.
You can now browse the newly created branch and verify that users from both Directory 1 and 2 are included in the branch.

Fig-15: You can see the Virtual DN displays users from both servers

TOP

Tutorial #2 - Fragmented Identities

Click here to download this tutorial as a PDF file.

1 Overview

Many organizations have multiple Identity Stores (including LDAP directories, relational databases and other repositories), each of which contain fragments of identity data. This distribution of data is problematic for applications that need to access identity information for authorization, verification or other reasons.

Virtual Directory Server can solve this issue by providing a unified view of the fragmented identities, effectively collecting all the pieces from the different Identity Stores and presenting them as a single identity to multiple applications. This is done using the "Join" module that comes with Virtual Directory Server (see the Processing Configuration section below).

In our tutorial, we will assume that our organization has two separate directories containing different information about our users. In Directory 1 is information required to authenticate users, while in Directory 2 there is contact information about the users. Our new intranet application requires a single datastore against which it can authenticate users, but against which it is also able to query contact information for users within the organization. We will set up a Virtual Directory Server instance that will join the information from the separate data repositories, so that the intranet application can access all of this information in a single place.

2 Assumptions

Virtual Directory Server is installed and configured properly; VDS is currently running.
Directory 1 and 2 are installed and accessible from the computer on which VDS is installed.
Multiple users exist in both directories and share a common attribute value.
Both directories are accessible on port 389 (default ldap port)
You have a good understanding of the DIT structure of your directories.
Port 3890 is available on the computer in which Virtual Directory Server is installed.

3 Create a New Configuration

Click File on the menu bar, then click New.
Click the OK button when asked which server you want to create the new configuration in (the default server is Local.
Enter JoinTutorial for the filename when prompted, then click the Save button and the following will appear:

Fig-1: Create a new configuration

4 Server Group Configuration

Server Groups are the directories and / or databases where your user information is stored. Examples include Active Directory, Sun Directory Server and Oracle database. For this tutorial we will be creating two Server Groups, one for Directory 1 and another for Directory 2.

4.1 Add Directory 1

Click on the Output node in the navigator tree on the left-hand side of the application.
Click on the New Server Group button near the bottom of the screen.
Enter Directory 1 for your new Server Group and leave the Server Group Type as Automatic and then click the Okay button.
Click on the Directory 1 node in the navigator tree on the left-hand side of the screen and the following will appear:

Fig-2: Configure the first Server Group
Verify that the Protocol is set to ldap.
Under the Servers tab, enter the Hostname / IP Address and the Port of Directory 1.
Click on the Connection Pooling tab and check the Use Connection Pooling checkbox. The following will appear:

Fig-3: Configure the Connection Pooling for the first Server Group
Click on the Use Fixed Credentials radio button then enter the Bind DN and Password for the user that has appropriate access to Directory 1.
Change the number of Pool Connections from 10 to 2.
Click the OK button near the top of the application to save the Directory 1 Server Group Configuration.

4.2 Add Directory 2

Click on the Output node in the navigator tree on the left-hand side of the application and the following will appear:

Fig-4: Click on the Output node
Click on the New Server Group button near the bottom of the screen.
Enter Directory 2 for your new Server Group and leave the Server Group Type as Automatic and then click the Okay button.
Click on the Directory 2 node in the navigator tree on the left-hand side of the screen and the following will appear:

Fig-5: Configure the second Server Group
Verify that the Protocol is set to ldap.
Under the Servers tab, enter the Hostname / IP Address and the Port of Directory 2.
Click on the Connection Pooling tab and check the Use Connection Pooling checkbox. The following will appear:

Fig-6: Configure the Connection Pooling for the second Server Group
Click on the Use Fixed Credentials radio button then enter the Bind DN and Password for the user that has appropriate access to Directory 2.
Change the number of Pool Connections from 10 to 2.
Click the OK button near the top of the application to save the Directory 2, Server Group Configuration.

5 Processing Configuration

In this tutorial we will be implementing a single Stage. This stage is going to utilize a default plugin that will merge users from two directories into one virtual directory. This plugin is called the Join Trees default plugin and is provided by the VDS to allow you to quickly and easily implement the functionality that you're looking for.

The Join module uses one attribute as the "join key" in order to match entries across different Identity Stores. This join key is an attribute that is used as the common link between several identities from multiple Identity Stores. The join key attribute values must be unique in every repository to ensure that the joins occur successfully.

Click on the Processing node in the navigator tree on the left-hand side of the application and the following will appear:

Fig-7: Click on the Processing node
Click on the New Stage button near the bottom of the screen.
Enter Join Users as the name of the new stage and leave the stage type as Automatic and then click the Okay button.
Click on the Join Users node in the navigator tree on the left-hand side of the screen.
Click on the Add Plugin button and the following will appear:

Fig-8: Add the Join Entries plugin
Scroll to the bottom of the list, click on Join Entries and click the OK button.
Click the JoinEntries node in the navigator tree on the left-hand side of the screen and the following will appear:

Fig-9: Configure the Join Entries plugin
Under the Condition section, enter the DN for your new VDS in the Base DN text box. This will be the DN that contains all of the attributes for your users that exist in Directory 1 and 2. This will also be the Base DN you specify when configuring a LDAP browser or application to connect to the VDS.
Under the Join Entries Main Configuration section, enter an attribute in the Primary Join Attribute textbox. In our example, we know that the uid attribute is commonly used in both Directories. This means that we can use this attribute to join our two datastores.
Under the Join Entries Main Configuration section, uncheck the checkbox if the attribute is not part of the RDN otherwise leave it checked (default).
Click the OK button near the top of the screen to save the Main Entry configuration.
Click on the New Foreign Data Group button and enter Directory 2 for the name of the new foreign data group then click the OK button.
Click on Directory 2 on the left-hand side of the screen and the following will appear:

Fig-10: Configure the Foreign Data Group
Enter the appropriate attribute in the Primary Key Attribute: section. In our case, we are joining the data based on the uid which we know is common in both Directories.
Uncheck the checkbox if the Primary Key Attribute is not part of the RDN otherwise leave it checked (default).
Click on Directory 2 in the dropdown box when asked which Server Group the information should be fetched from.
Enter the Base DN where information should be fetched from.
Click the OK button near the top of the screen to save the Foreign Data Group configuration.

6 Listener Configuration

Click on the Input node in the navigator tree on the left-hand side of the application and the following will appear:

Fig-11: Click on the Input node
Click on the New Listener button near the bottom of the screen.
Enter Join Users for the new input / listener and then click the Okay button.
Click on the Join Users node in the navigator tree on the left-hand side of the screen and the following will appear:

Fig-12: Configure the Listener
Under the Main Listener Properties tab, make sure the Protocol is set to ldap.
Under the Main Listener Properties tab, set the port to 3890.
Under the Main Listener Properties tab, set the Default Server Group to Directory 1 by selecting it from the dropdown box.
Click on the Attached Stages tab.
Double-click where it shows to do so and click on Join Users in the dropdown box.

Fig-13: Attach the Processing Stage to the Listener
Click the OK button near the top of the screen to save the Listener configuration.

7 Save Configuration

When you created the new configuration you were prompted to enter a filename for your configuration. The file type for this file is ldif. The configuration must be saved before the VDS can be launched for the first time. Also, the configuration must be saved and the VDS re-launched before changes to the configuration will take effect.

Click on the File button on the menu bar.
Click Save and your configuration will then be ready to launch.

8 Launch and Test Configuration

Click the Process button on the menu bar.
Click Run on the drop-down menu. At this point the VDS is running and is ready to accept LDAP requests.
Click the Extras button on the menu bar.
Click LDAP Browser on the drop-down menu and the following will appear:

Fig-14: Use the LDAP Browser to test the running VDS instance
In the Name textbox, enter Join Users.
In the Hostname textbox, enter the IP Address of the computer that VDS is installed on.
In the Port textbox, enter 3890.
In the Root Suffix textbox, enter the Base DN from the Condition section of the Main Entry Configuration you specified during the Processing Configuration section of this tutorial.
In the Bind DN textbox, enter the DN of the user that has appropriate access to the Root Suffix / Bind DN in the step above.
Enter the Password twice for the user specified in the step above.
Click the Test button to verify that you can properly bind to the Bind DN.
Assuming you entered the correct information, a Test Successful! message will appear. Click the OK button.
Click the OK button on the next page and you will be asked if you would like to save Join Users. Click the Yes button and the Bind DN you specified will appear.
You can now browse the newly created branch and verify that attributes of users from both Directory 1 and 2 are included in the branch.

In our example, Directory 2 contained contact information including Address and Email data, while Directory 1 was used primarily as an authentication database. In the image below, you can see that the VDS instance is displaying Address information from Directory 2, along with the data stored in Directory 1. Most significantly, you will notice two mail addresses listed. This is because a mail entry existed in both repositories. The Directory 1 entry has precedence.

Fig-15: Data from the two Directories has been merged into a single entry using VDS

TOP

Tutorial #3 - Integrating RDBMS into an LDAP Environment

Tutorial #3 - Integrating RDBMS into an LDAP Environment

Click here to download this tutorial as a PDF file.

1 Overview

In the previous tutorial, we noted that organizations may store user data in multiple repositories. Up until now, we have assumed that these repositories are of the same type, using the same protocol and nomenclature. However, things become a little more complicated when data is stored in different repository types. For instance, imagine a situation where a web application stores data in a relational database, while the rest of your applications query an LDAP directory like Active Directory. It is not implausible that you would like applications that query your Active Directory to also be able to access information in a relational database.

In this tutorial, we will assume that our organization has a single LDAP directory containing some information about our users, while a MySQL database is used to contain further information about users that is accessible via a web interface. For now, we will simply work toward providing a means for LDAP-ready applications to access data within the MySQL database used by our web application. This is easily achieved using Virtual Directory Server.

2 Assumptions

Virtual Directory Server is installed and configured properly; VDS is currently running.
An LDAP directory such as Active Directory is already installed and accessible from the computer on which Virtual Directory Server is installed.
A MySQL database server is already installed and accessible from the computer on which VDS is installed.
A MySQL database called "test" has been created, and contains a table called "users" with a schema that contains the following items:
`uid` varchar(25) NOT NULL, `password` varchar(40) NOT NULL, `Title` varchar(255) default '', `FirstName` varchar(255) default '', `LastName` varchar(255) default '', `Company` varchar(255) default '', `EmailDisplayName` varchar(255) default '', `EmailAddress` varchar(255) default ''
The MySQL table called "users" is populated with at least one entry.Select the table and a naming attribute
The LDAP directory is accessible on port 389 (default ldap port) and the MySQL server is accessible on port 3306 (default mysql port).
Port 3890 is available on the computer in which Virtual Directory Server is installed.

3 Create a New Configuration

Click File on the menu bar, then click New.
Click the OK button to create a Local configuration.
Enter RDBMSTutorial for the filename when prompted, then click the Save button and the following will appear:

Fig-1: Create a new configuration

4 Server Group Configuration

Server Groups are the directories and / or databases where your user information is stored. For this tutorial we will be creating two Server Groups, one for our LDAP Directory (Directory 1) and another for our MySQL database (RDBMS).

4.1 Add Directory 1

Click on the Output node in the navigator tree on the left-hand side of the application.
Click on the New Server Group button near the bottom of the screen.
Enter Directory 1 for your new Server Group and leave the Server Group Type as Automatic and then click the OK button.
Click on the Directory 1 node in the navigator tree on the left-hand side of the screen and the following will appear:

Fig-2: Configure the first Server Group
Verify that the Protocol is set to ldap.
Under the Servers tab, enter the Hostname / IP Address and the Port of Directory 1.
Click the OK button near the top of the application to save the Directory 1 Server Group Configuration.

4.2 Add the RDBMS Server Group

Click on the Output node in the navigator tree on the left-hand side of the application and the following will appear:

Fig-3: Click on the Output node
Click on the "New database connection" button near the bottom of the screen to open the Database Wizard.
Select the appropriate driver for your database. In this example we will be using the MySQL driver. Note, that in order to use the wizard, you will need to copy the driver files into the appropriate directory for your installation, as explained in the user guide.

Fig-4: Select the appropriate database driver
Enter the connection details to access the backend database. Note that the options that appear here will differ depending on the driver that you are using.

Fig-5: Enter connection details
Provide a mount point DN that will be used to access the data from the database table within the LDAP tree. Usually, the DN that you enter here will appear as a node within the tree presented by your default ServerGroup, or Virtual Tree.

Fig-6: Enter a mount point DN for the table data
Select the table that you wish to append to the LDAP tree, and choose a field to be used as the naming attribute within the branch. You also have the option to choose a password attribute here if you wish to perform LDAP authentication against data held within the database table.

Fig-7: Select the table and a naming attribute
Finally, provide an RDN for the table. Usually the default tablename as an organizational unit should be sufficient. And click Next to view the final configuration, where you will be able to exit out of the wizard.

Fig-8: Choose an RDN for the table
When you have completed the wizard, you will find that a new servergroup has been added to your configuration and that it looks something like this:

Fig-9: RDBMS Servergroup configuration screen
Click the OK button near the top of the application to save the RDBMS Server Group Configuration.

5 Processing Configuration

In this tutorial we will be implementing a single Stage. This stage is going to utilize a default plugin that will make it possible to see the virtual RDBMS tree mapping in an LDAP browser. This plugin is called the Add Entries plugin.

Click on the Processing node in the navigator tree on the left-hand side of the application and the following will appear:

Fig-10: Click on the Processing node
Click on the New Stage button near the bottom of the screen.
Enter Add Entry as the name of the new stage and leave the stage type as Automatic and then click the Okay button.
Click on the stage=Add Entry node in the navigator tree on the left-hand side of the screen.
Click on the Add Plugin button and the following will appear:

Fig-11: Select the Add Entries plugin
Scroll to the bottom of the list, click on Add Entries and click the OK button.
Click the AddEntries node in the navigator tree on the left-hand side of the screen.
Click the New Virtual Entry button near the bottom of the screen, and enter "db" in the dialog that pops up.
Click on the "db" node in the navigator tree on the left of the screen.
In the Entry DN field, enter the DN that you have used to attach your RDBM data, in the Destination Tree field earlier.

Fig-12: Configure the db Entry in the Add Entries plugin
You will now need to provide some attributes for the virtual DN that you are creating. In the Attribute Type column of the table, create an attribute type called "objectclass". In the Attribute Values column, enter a value of "top" and a second value of "organizationalunit".
Create a second Attribute type called "ou" and assign it the value "db".

6 Listener Configuration

Click on the Input node in the navigator tree on the left-hand side of the application and the following will appear:

Fig-13: Click on the Input node
Click on the New Listener button near the bottom of the screen.
Enter RDBMS Listener for the new input / listener and then click the OK button.
Click on the listener=RDBMS Listener node in the navigator tree on the left-hand side of the screen and the following will appear:

Fig-14: Configure the Listener
Under the Main Listener Properties tab, make sure the Protocol is set to ldap.
Under the Main Listener Properties tab, set the port to 3890.
Under the Main Listener Properties tab, set the Default Server Group to Directory 1 by selecting it from the dropdown box.
Click on the Attached Stages tab.
Double-click where it shows to do so and click on stage=Add Entry in the dropdown box.

Fig-15: Attach the Processing Stage to the Listener
Click the OK button near the top of the screen to save the Listener configuration.

7 Save Configuration

When you created the new configuration you were prompted to enter a filename for your configuration. The file type for this file is ldif. The configuration must be saved before the VDS can be launched for the first time. Also, the configuration must be saved and the VDS re-launched before changes to the configuration will take effect.

Click on the File button on the menu bar.
Click Save and your configuration will then be ready to launch.

8 Launch and Test Configuration

Click the Process button on the menu bar.
Click Run on the drop-down menu. At this point the Virtual Directory Server is running and is ready to accept LDAP requests.
Click the Extras button on the menu bar.
Click LDAP Browser on the drop-down menu and the following will appear:

Fig-16: Use the LDAP Browser to test the running Virtual Directory Server instance
In the Name textbox, enter RDBMS Tutorial.
In the Hostname textbox, enter the IP Address of the computer that VDS is installed on.
In the Port textbox, enter 3890.
In the Root Suffix textbox, enter the Base DN of your LDAP Directory.
In the Bind DN textbox, enter the DN of the user that has appropriate access to the Root Suffix / Bind DN in the step above.
Enter the Password twice for the user specified in the step above.
Click the Test button to verify that you can properly bind to the Bind DN.
Assuming you entered the correct information, a Test Successful! message will appear. Click the OK button.
Click the OK button on the next page and you will be asked if you would like to save RDBMS Tutorial. Click the Yes button and the Bind DN you specified will appear.
You can now browse the your LDAP Directory as usual, however you will notice a new tree with the RDN "ou=db" attached to your Directory. This is visible thanks to the Add Entries plugin.

Browsing down the ou=db tree, you will discover that you are able to view data within your MySQL database inside of the LDAP tree.

Fig-17: Data from the MySQL database is visible in the LDAP tree using VDS

A final note about using Relational Databases within VDS as backend repositories. Unlike most directory servers, Relational Databases do not often follow standardized schemas. This means that LDAP applications that are very schema-specific may have trouble relating to the attribute types returned by VDS on behalf of a relational database. This is not so much a problem with the implementation of VDS as the data is returned accurately, but is more of a problem with the non-standard way that browsers and some other LDAP applications relate to schemas. Ideally, a browser should not perform any schema checking, as this not only slows down the browser but also results in limitations of the browser itself. However, we do not live in a perfect world, if you find that your LDAP applications are not working properly with your relational database, you may find that you need to redefine your table schema to conform to an LDAP schema or that you need to perform some complex attribute mapping.

TOP

Tutorial #4 - Integrating an RDBMs Into an LDAP Tree

Tutorial #4 - Integrating an RDBMS Into an LDAP Tree

Click here to download this tutorial as a PDF file.

1 Overview

Building on the previous Virtual Directory Server tutorials, we will now try to build a complex solution based on a fairly difficult use-case scenario. We will begin by assuming that our organization has user data stored within an RDBMS and that the organization also stores user data within an LDAP directory. To make matters more complicated, a certain amount of the data stored in the RDBMS overlaps with the data stored in the LDAP directory. Finally, the data is stored in the RDBMS in a way in which the field names (or attribute types) do not correlate with the schema used within the LDAP directory. When users change their details using Directory tools, the changes should also be reflected in the RDBMS, so that the organization's web-based intranet application continues to function properly. Furthermore, when the RDBMS is updated via the web application, you want these changes to be reflected in the Directory. Not surprisingly, this is a common problem for many organizations. By using the information provided in the previous tutorials, we should be able to create a solution using Virtual Directory Server to merge all of this data so that it works in a relatively seamless way.

In our tutorial, we will assume that our organization has a single LDAP directory containing some information about our users, while a MySQL database is used to contain information about users that is accessible via a web interface. Using the configuration from the previous tutorial, we will now use the Join Entries plugin and the Map Attributes plugin to make the data in the MySQL database visible to applications that are currently accessing a particular tree in the LDAP server. In this way, LDAP applications will be able to update data within the RDBMS, and will be able to present changes to the RDBMS as if these changes had been made within the LDAP directory.

2 Assumptions

Virtual Directory Server is installed and configured properly; VDS is currently running.
An LDAP Directory is installed and accessible from the computer on which Virtual Directory Server is installed.
A MySQL database is installed, configured, and accessible from the computer on which Virtual Directory Server is installed.
The configuration from Tutorial 3 (Integrating RDBMS into an LDAP Environment) has been completed and is available for modification.
Port 3890 is available on the computer in which Virtual Directory Server is installed.

3 Open the Existing Configuration from Tutorial 3

Click File on the menu bar, then click Open, and then click on Open Local Config.
Click on RDBMSTutorial in the local configuration menu, and then click on the Open Config button
The configuration from the previous tutorial should be loaded and you will be able to begin editing the configuration.

Fig-1: Open the RDBMSTutorial configuration

4 Add Processing Stages

At this point, our configuration is already capable of integrating an RDBMS and LDAP directory into a single environment presented as an LDAP server accessible on port 3890 of the local server. In the previous tutorial, we created a Processing Stage to host the Add Entries plugin, so that data from the RDBMS would be visible to LDAP browsers. Now, we will add two further Processing Stages that will host the Join Entries plugin and the Map Attributes plugin, so that we can present the data within a single tree that follows the schema already being used by the LDAP server. In this way, LDAP applications will be able to access and update information stored in the RDBMS as if it was part of the expected LDAP environment.

4.1 Add Join Entries stage

The Join Entries module uses one attribute as the "join key" in order to match entries across different Identity Stores. This join key is an attribute that is used as the common link between several identities from multiple Identity Stores. The join key attribute values must be unique in every repository to ensure that the joins occur successfully.

Click on the Processing node in the navigator tree on the left-hand side of the application and the following will appear:

Fig-2: Click on the Processing node
Click on the New Stage button near the bottom of the screen.
Enter Join Entries as the name of the new stage and leave the stage type as Automatic and then click the Okay button.
Click on the stage=Join Entries node in the navigator tree on the left-hand side of the screen.
Click on the Add Plugin button and the following will appear:

Fig-3: Add the Join Entries plugin
Scroll to the bottom of the list, click on Join Entries and click the OK button.
Click the JoinEntries node in the navigator tree on the left-hand side of the screen and the following will appear:

Fig-4: Configure the Join Entries plugin
Under the Condition section, enter the DN that is used to store user data, in your LDAP Directory, in the Base DN text box. We will join data from the MySQL database into this DN, so that although the data presented will be a combination from both repositories, your LDAP applications will relate to the data as if it has come only from the LDAP repository. The Join will only be applied when any application makes a request for this DN.
Under the Join Entries Main Configuration section, enter an attribute in the Primary Join Attribute textbox. In our example, we know that the uid attribute is commonly used in both Directories. This means that we can use this attribute to join our two datastores. You are able to use two differently named attributes to perform the join on, in this field, you would enter the attribute name for the attribute in the LDAP directory that we are joining MySQL data to.
Under the Join Entries Main Configuration section, uncheck the checkbox if the attribute is not part of the RDN otherwise leave it checked (default).
In the Aggregated Attributes list, enter the 'mail' attribute on one line, so that it is possible to have multiple email addresses stored either in LDAP or in the MySQL database.
Click the OK button near the top of the screen to save the Main Entry configuration.
Click on the New Foreign Data Group button and enter RDBMS for the name of the new foreign data group then click the OK button.
Click on RDBMS on the left-hand side of the screen and the following will appear:

Fig-5: Configure the Foreign Data Group
Enter the appropriate attribute in the Primary Key Attribute: section. In our case, we are joining the data based on the uid which we know is common in both Directories. If the attribute is named differently, you would enter the name of the attribute in the MySQL database that we will use to perform the join against.
Uncheck the checkbox if the Primary Key Attribute is not part of the RDN otherwise leave it checked (default). Note that in order to be able to perform ADD writes to the joined server groups, the Primary Key Attribute must also be used for the RDN.
Click on RDBMS in the dropdown box when asked which Server Group the information should be fetched from.
Enter the Base DN where information should be fetched from. In our example, this would be from: ou=users,ou=MYSQL,dc=my_organization,dc=com.
Because we are writing data across two different environments, it is worthwhile specifying which attributes should be written to the database. Click on the WRITE Operation Paramaters tab.
Ensure that all of the different WRITE operations are enabled, and select the option to include only the following attributes for all WRITE operations. In the list, we will specify the attributes that we wish to use within the database. Because we intend to use attribute mapping to resolve the differences in schemas, we can choose to use the attributes from our LDAP schema, that we intend to map onto the database schema.

Fig-6: Configure the WRITE options

In our example, the attributes that we wish to copy into the database are as follows:

uid

mail

userpassword

company

displayname

givenname

sn

Click the OK button near the top of the screen to save the Foreign Data Group configuration.

4.2 Add Map Attributes Stage

The Map Attributes module is able to map attributes from one identity store onto attribute types for another identity store. Effectively, you are able to define alias attributes on the fly, so that column/field names from your MySQL database appear to follow the schema used by your LDAP server.

Click on the Processing node in the navigator tree on the left-hand side of the application and the following will appear:

Fig-7: Click on the Processing node
Click on the New Stage button near the bottom of the screen.
Enter Map Attributes as the name of the new stage and leave the stage type as Automatic and then click the OK button.
Click on the stage=Map Attributes node in the navigator tree on the left-hand side of the screen.
Click on the Add Plugin button and the following will appear:

Fig-8: Add the Map Attributes plugin
Scroll through the list in the plugin dialog, click on Map Attributes and click the OK button.
Click the MapAttributes node in the navigator tree on the left-hand side of the screen and the following will appear:

Fig-9: Configure the Map Attributes plugin
Under the Condition section, enter the DN used to access the data in the database into the Base DN text box. Although there is a note on the GUI warning you not to enter a Base DN in the conditions section of the configuration, if you are doing attribute mapping from the server to the client, it is important that you ignore this, for this configuration, as the schemas from the Join are likely to conflict so heavily.

Under the Attribute Mapping Configuration section, we will need to define attribute mappings that work both ways (from client to server and vice versa). On the Attribute (server) side of the table, we will list the names of fields within our MySQL table. On the Attribute (client) side of the table, we will list the LDAP attributes that these fields will map onto.

In our example, the table will end up looking something like this:

EmailDisplayName	<-->	displayname
password	<-->	userpassword
FirstName	<-->	cn
LastName	<-->	sn
EmailAddress	<-->	mail

Click the OK button to save the changes.

5 Listener Configuration

Expand the Input node in the navigator tree on the left of the GUI; and click on listener=RDBMS Listener. The listener should be mostly configured from the previous tutorial.

Fig-11: Click on the RDBMS Listener
Click on the Attached Stages tab.
Beneath the stage=Add Entry, double-click where it shows to do so and click on stage=Join Entry in the dropdown box. Repeat the step to add the stage= Map Attributes option to the stages pipeline.

Fig-13: Attach the Processing Stages to the Listener
Click the OK button near the top of the screen to save the Listener configuration.

6 Save Configuration

Before you attempt to run the configuration, you will need to save all of the changes to file. To do this, follow the instructions below.

Click on the File button on the menu bar.
Click Save and your configuration will then be ready to launch.

7 Launch and Test Configuration

While Symlabs Virtual Directory Server comes with its own built-in LDAP browser, this browser is not adequate for WRITE testing in an LDAP environment. For this tutorial, we will use JXplorer, a 3rd Party LDAP Browser, to test our configuration properly. You can use an alternative browser for your own purposes, or install JXplorer according to the instructions provided on the JXplorer website. To begin with, we will need to start our configuration, so that we are able to access the data from both repositories.

Click the Process button on the menu bar.
Click Run on the drop-down menu. At this point the Virtual Directory Server is running and is ready to accept LDAP requests.
Open JXplorer, or an alternative LDAP browser, and configure it to connect to our VDS instance:

Fig-12: Configure JXplorer to connect to the VDS instance
Connect to the VDS instance and expand the People DN in the navigation tree.
A list of users that are on the LDAP server should now be available. Details for any users that also exist in the MySQL database will be available to view for any user.

Fig-13: Expand the People DN
Right click on the People node in the navigation tree, and select the New option from the dialog.

Enter and RDN with uid=testuser in the Enter RDN field, and ensure that the inetOrgPerson, organizationalPerson, person and top Classes are selected. Click OK.

Fig-14: Add a test user to the directory.
Assign compulsory values, such as the cn and sn attributes. And add values for the displayname, givenname and mail attributes. Click Submit.
If you have correctly configured your VDS instance, an entry for testuser should appear in your MySQL database as well as in your LDAP directory. Note that users already existing in the LDAP directory will not exist within the MySQL database automatically. However, once added, any changes made to the directory in VDS will be reflected in the MySQL database. In our current configuration, it is important to note that we have allowed the data in the LDAP directory to have precedence. This means that changes to the database will only be reflected in the VDS directory if no data already exists for the user in the LDAP directory. The order of precedence can easily be changed in the configuration, by clicking on the Join Entries node in the navigation panel of DSGUI, and shuffling the Order of Precedence on the Main Parameters tab.

Fig-15: The user will appear in the DB node, which represents data stored in the MySQL database.

We have also allowed for the mail attribute to be aggregated. This means that if the user changes the EmailAddress in the MySQL database, our VDS directory will provide the address stored in the LDAP directory, along with the Email address in the MySQL database.

TOP

Tutorial #5 - Working with Remote Configurations

Click here to download this tutorial as a PDF file.

1 Overview

Symlabs Virtual Directory Server (VDS) provides the option of working directly with remote configurations within a GUI environment on a local system. This facility is made available through the Remote Administration Server, a separate daemon or service that runs on the host system and is capable of interacting directly with configuration files on the server, as well as being able to initiate or stop a Virtual Directory Server instance. With some basic setup steps, it is possible for an administrator to work directly on a Virtual Directory Server host remotely, without requiring direct access to the host system. This provides a number of benefits to any enterprise environment. Firstly, it provides an additional layer of security in that administrators responsible for the maintenance of the VDS instance, do not need to be provisioned with any other form of access to the host system. Secondly, it massively eases configuration and maintenance tasks in environments where there are multiple Virtual Directory Server instances running, as the administrator only needs to open the GUI on his or her local system and connect to the VDS host that needs to be configured. Finally, and perhaps most importantly, systems running RAS do not need to have a graphical display available in order to configure and manage them. For Unix environments in particular, production servers rarely have an X server or windows environment installed. This helps to improve security and reduce unnecessary load on a production system. Using the RAS allows administrators to configure and manage Virtual Directory Server instances with the convenience of a GUI without requiring a windows environment to be loaded on the VDS host.

This tutorial will set out to explain how to configure the Remote Administration Server (RAS) on a host, how to start it, and how to connect to it using a locally installed graphical user interface. Once the host is accessible via RAS, an administrator should be able to configure the Virtual Directory Server instance on the remote host as if it were a local configuration. At this point, any of the other tutorials (or customized configurations) can be followed with the only variation being that the configuration will be created or edited remotely.

2 Assumptions

Virtual Directory Server is installed and configured properly; VDS is currently running.
The Administrator following this tutorial has access to the system that will run the VDS instance (from now on, referred to as the Remote VDS Host).
The Administrator has installed the Virtual Directory Server GUI on a separate system that has network access to the Remote VDS Host. This system will be referred to from now on as the Local VDS Controller.
Port 9443 is available on the Remote Virtual Directory Server Host.
The Local VDS Controller is able to communicate with the Remote VDS Host on port 9443 (i.e. there are no firewall restrictions for this port).

3 Connect to the Remote Virtual Directory Server Host and Configure RAS

Depending on the Operating System that the Remote Virtual Directory Server Host is using, you will need to determine how best to access the Remote Virtual Directory Server Host. For Microsoft Windows environments, this might be done using Terminal Services. Unix and Linux environments can be accessed using SSH. Alternatively, you may find it easier to work directly on the Remote Virtual Directory Server Host locally, to perform the initial RAS configuration. In this section, we will assume that regardless of the Operating System, you are able to access the system and perform the tasks required.

The RAS configuration parameters are stored in an LDIF file within the admrem folder or subdirectory within the root folder for the VDS installation. On Windows, this is likely to be in the path C:\Program Files\Symlabs\DE\R4.0.0. While on Unix and Linux platforms, this is likely to be in the path, /opt/ds/std/.

Using your preferred editor, open the file named admconf.ldif in the admrem directory.
Within this file, regardless of the Operating System, are the following lines:
dn: cn=administrator,o=dsproxyremote user: demanager passwd: admin123
The user and passwd lines specify the credentials that are used to access the RAS instance. In production environments, we highly recommend that you change the user and password credentials for the RAS service, as this facility allows full control of any VDS instance running on the Remote VDS Host. In our example tutorial we will only change the passwd value, and we will set it to 'symlabs123'.
Save the edited admconf.ldif file, and close it.

4 Start the RAS service on the Remote VDS Host

The RAS service will essentially run as its own unique Virtual Directory Server instance and will intercept requests from the Local VDS Controller that are directed to port 9443, and will act on them as required. Incidentally, it is possible to run the RAS service on a different port, by editing the admRemServer.ldif configuration file (also within the admrem folder in the root of your installation). However, we do not recommend that you edit this file unless absolutely necessary.

Now that the RAS service has been configured, you will need to start it on the Remote VDS Host.

Start the RAS service.

In Windows environments you can now start the RAS service by running the RAS Monitor will be listed in the Start menu (under Symlabs > DE > VDS > R4.5.0). When the RAS Monitor is started for the ﬁrst time, the RAS Service will be registered as a regular Windows Service with the name "Symlabs DE VDS RAS" and can be controlled either using the RAS Monitor applet, or by using the Windows Services environment. Right clicking on the RAS Monitor applet will present you with a menu that will allow you to control the RAS service.

Fig-1: The Windows RAS Monitor.

The Windows RAS Monitor directly interacts with a batch script that is responsible for controlling how the RAS system functions. You can alternately start the RAS service by opening a command prompt. Changing to the root directory of your Virtual Directory Server installation (usually, C:\Program Files\Symlabs\VDS\R4.5.0) and typing:
```
init-admrem.bat start
```
For Unix or Linux systems, you can start the RAS service by opening a shell and changing to the root directory of your Virtual Directory Server installation (usually, \opt\ds\std) and typing:
```
./init-admrem start
```

The Remote VDS Host should now be running the RAS service and should be accessible remotely.

5 Configure the Local VDS Controller

Now open the DSGUI application on your Local VDS Controller system. We will configure the GUI to be able to connect to our RAS instance, so that it can be controlled using the local system across the network.

Click on File in the File menu at the top of the GUI, and select Preferences from the dropdown menu.
In the Preferences dialog, select the Administration Server Preferences option from the navigation panel on the left.

Fig-1: Select the Admin Server Preferences option
Click on the Add button at the bottom of the screen. In the dialog that pops up, you will need to enter the details for the Remote VDS Host. In the Name field, enter a short name that will be used to reference the remote host (in our example, we have simply called the instance RemoteHost). In the Hostname field, you can enter a hostname that is resolvable by DNS, or simply enter the IP address of the Remote VDS Host. Finally, in the password fields, enter the password that we defined in the RAS configuration file. In this case, we changed it to 'symlabs123'.

Fig-2: Define the parameters required to connect to the Remote VDS Host
Click the Test button to ensure that you are able to connect to the RAS service. A dialog should pop up to tell you if the connection was successful.
Click the OK button.
In the Preferences screen, click the OK button at the top of the screen, and then in the File menu at the top of the screen select the option to Save your preferences.
Close the Preferences screen.

6 Connect to the Remote Virtual Directory Server Host and Create a New Configuration

You will now be able to connect to the Remote Virtual Directory Server Host that you have defined in your preferences, and create a new configuration.

Click on the File button on the menu bar, and select New->New Remote Config. A dialog will pop-up allowing you to select the Remote Virtual Directory Server Host that you have specified in your Preferences. Click OK.

Fig-3: Select the Virtual Directory Server Host that you wish to connect to.
Provide a filename for your configuration. In our example, we have assigned the name RasTest. Click the New Config button.

Fig-4: Create a new remote config.

The configuration will be saved by default in the confs folder in the root of the installation of the VDS software on the Remote VDS Host.

You will now be able to work with this configuration as if you were interacting with a local configuration. Changes will be saved on the Remote VDS Host. Any attempt to start or stop the configuration, will execute the appropriate action on the Remote VDS Host. Logging to STDOUT performed by the configuration will be returned via RAS to the Local VDS Controller to be displayed in the GUI logging window.

TOP

Tutorial #6 - Sharepoint Integration with Symlabs Enabled Identity Stores

Sharepoint Integration with Symlabs Enabled Identity Stores

Overview

Symlabs Virtual Directory Server and LDAP Proxy can be used to facilitate the integration of Sharepoint Portal, or MOSS (Microsoft Office Sharepoint Server), within an environment that includes more than one Active Directory identity store where trust relationships have not been established between different domain controllers. Symlabs LDAP Proxy will allow Sharepoint Portal to integrate with any LDAP identity store, while Symlabs Virtual Directory Server can be used to all Sharepoint Portal to integrate with relational database backend repositories.

Sharepoint Portal is capable of using one of three authentication modes: Windows, Forms and Web SSO. Traditional intranet deployments use the default Windows authentication mode, which allows authenticated Windows domain users to access the Sharepoint Portal linked to that domain without being challenged for credentials. To give access to users from different domains, the Sharepoint administrator will need to extend the web application to a different zone (usually to the "extranet") and will usually make use of the Forms authentication mode for that zone. The administrator will need to select a 'Membership and Role Provider'. Microsoft provides two such implementations: a AspNetSqlProvider and the LdapProvider. These implementations work as advertised but have the constraint that they can only use one identity store.

In this document we explain how it is possible to extend Microsoft's LdapProvider Membership and Role Provider implementation, so that it is capable of integrating with more than one identity store, by using the Symlabs Virtual Directory Server product to aggregate identity stores so that they look like one to Sharepoint. It is important to note, that this solution is also achievable using Symlabs LDAP Proxy, but you will be limited to working only with LDAP data stores.

Configuring Virtual Directory Server

In order to allow Microsoft LdapProvider to use multiple backend identity stores, including RDBMS servers, we will need to configure Symlabs Virtual Directory Server in such a way that data from all of the different backend repositories is presented as belonging to a single tree.

Let's consider that we need to give Sharepoint access to users stored in two external Active Directory instances, that are not already linked as the local Active Directory store that Sharepoint is already using. These two ADs belong to two independent domains, partnerone.com and partnertwo.com. Users for both ADs are stored in the CN=Users branch on each directory. We will configure Virtual Directory Server to aggregate the data stored in each of these branches using the MergeTrees plugin that comes bundled with the software.

Plugins are useful components that are bundled with Symlabs products to encapsulate commonly used functionality. These plugins can be configured using the graphical interface within the DSGUI configuration and management tool, without requiring an administrator or developer to write a single line of code.

The MergeTrees plugin is capable of aggregating the entries stored in different branches on different servers and mapping them onto a single "mount point" entry or node within an existing directory. To keep this example configuration simple, we will use the local Active Directory to create a mount point entry that can be used by the MergeTrees plugin. Simply open your local "Active Directory Users and Computers" and create two organizational units under the root. To do this, right click the root node and select "New => Organizational Unit". Name the first node "AllUsers", and the second node "AllGroups". The local Active Directory instance is now ready to interact with the Virtual Directory to present a unified set of Users and Groups from each of your backend Active Directory instances.

Fig-1: Setting up mount points in Active Directory

Open the DSGUI Management Console and create a new Virtual Directory Server local configuration. This will open a new configuration with the Input, Processing and Output nodes on the left, in the navigation panel.

Under the "Output" node, you will need to add three server groups. One for each external AD (partnerone.com and partnertwo.com) and the third one for the local AD (mycompany.com). For each server group, you will need to provide the IP address or hostname of each Active Directory server and the port number (usually 389) on which the AD instance is listening.

Fig-2: Create three server groups in the output configuration

Under the "Input" node of the configuration, you will need to add a new listener. The listener will be the interface on the Virtual Directory Server instance that the Microsoft LdapProvider, for your Sharepoint Portal, connects to. As you are running a local instance of Active Directory, it is likely that you will need to set the Listener port to something other than the port being used by Active Directory (try setting it to 3890). You should also select a default Server Group that should be used to route all incoming traffic to. In this case, select the server group that you configured for the local Active Directory instance within the Output part of your configuration.

Fig-3: Set the default server group in the Listener

Now we are ready to add the MergeTrees plugin. Under the Processing node in the configuration, you will need to add a new 'Automatic' stage, which you can name something useful like "Aggregation". Once you have added the stage, you will be able to click on the Add Plugin button in the configuration panel and select the Merge Trees plugin. Rename the plugin entry in your configuration to something relevant to its use, something like 'Allusers'.

The plugin configuration panel offers a variety of configuration options. In order to limit the plugin functionality to requests for entries from the DN "ou=allusers,dc=mycompany,dc=com", you will need to enter this DN within the BaseDN field in the Conditions section of the panel. You also need to enter this DN into the Joined Tree DN field in the Merge Trees Configuration section of the configuration panel. You will notice that this DN points to the the "AllUsers" OU that we created on the local AD instance.

Beneath the Joined Tree DN field, you will notice three checkboxes. All three boxes should be checked. By default, two of these boxes will already be checked, and as we will be using the new branch for authentication purposes, you should also check the BIND Support option.

Fig-4: Configure the MergeTrees plugin to aggregate all users

Finally, you are able to select the branches that you wish to aggregate from each of the external server groups that you wish to be able to use with the LdapProvider. So, add the DN for the users stored on the first external AD instance, "cn=users,dc=partnerone,dc=com" and select the servergroup that contains this entry from the list of server groups that you created in the Output configuration. Now add an entry for the second external AD, "cn=users,dc=partnertwo,dc=com" and select the appropriate servergroup that contains this entry from the list of server groups that you created in the output configuration.

This configuration will now be capable of merging all of the users from your external Active Directories into a branch accessible within a virtual representation of your local Active Directory instance. However, in order for Sharepoint to function properly, you will also need to aggregate Group information. To do this, you simply need to add another Merge Trees plugin to the same processing stage that you have already created. Rename it to something like "Allgroups".

Now you will need to limit the plugin functionality to requests for entries from the DN "ou=allgroups,dc=mycompany,dc=com", by entering this DN within the BaseDN field in the Conditions section of the panel. You also need to enter this DN into the Joined Tree DN field in the Merge Trees Configuration section of the configuration panel.

Now select the "group" branches that you wish to aggregate from each of the external server groups that you wish to be able to use with the LdapProvider. So, add the DN for the groups stored on the first external AD instance, "cn=groups,dc=partnerone,dc=com" and select the servergroup that contains this entry from the list of server groups that you created in the Output configuration. Now add an entry for the second external AD, "cn=groups,dc=partnertwo,dc=com" and select the appropriate servergroup that contains this entry from the list of server groups that you created in the output configuration.

Fig-5: Configure the MergeTrees plugin to aggregate all groups

At this point, the configuration of your Virtual Directory Server instance is almost complete. However, as most Active Directory configurations will not allow anonymous searches, we may need to cater for the fact that in many cases, the searches originating from Sharepoint will be anonymous. Note that Sharepoint with Service Pack 1 allows for authenticated searches but this only works where there is just one LDAP server, in which case a virtual directory is generally not needed. To handle this constraint we can add a "Connection Pool" to each server group. The connection pool can be configured to use fixed credentials, which will ensure that all anonymous connections are authenticated using the specified credentials. Connection Pools can be configured on the Connection Pool tab for each server group that you have in the Output configuration.

An alternative, and cleaner, approach to this problem is to make use of the AddCredentials plugin. In this case, you will simply need to create a second 'Automatic' processing stage within your configuration. You could call this stage something like 'binding', and then add the AddCredentials plugin to it. In the AddCredentials configuration panel, change the name to BindMyCompany, fill the Base DN field in the Conditions section with "dc=mycompany,dc=com" and then provide the BIND credentials that should be used in the Add Credentials Configuration section. Under the same stage you will need to add another AddCredentials plugin for each of the external AD instances, partnerone.com and partnertwo.com.

Fig-6: Configure the AddCredentials plugin to provide BIND credentials to authenticate anonymous Sharepoint access

Make sure to attach the stages to the listener defined earlier, save, and start the configuration.

Fig-7: Don't forget to attach your processing stages

Configuring and Testing Sharepoint

In the Central Administration page of your Sharepoint installation extend the application, that you wish to share with your partners, to the extranet zone. By default the extranet zone uses Windows authentication. To change that go to the list of Authentication Providers for the application you have just extended, select the extranet zone, and change the authentication type to Forms. In the "Membership provider name" enter SymlabsLDAPMembership and in the "Role manager name" enter SymlabsLDAPRole (these names can be anything as long as they match the names in the web.config files described next).

Fig-8: Membership Provider and Role Manager Names

To complete the configuration you will need to edit the web.config files for the Administration, internal and external site. Under the <PeoplePickerWildcards> node of these web.config files add the following keys:

 <PeoplePickerWildcards> <clear /> ...... <add key="SymlabsLDAPMembership" value="*" /> <add key="SymlabsLDAPRole" value="*" /> </PeoplePickerWildcards>

These are necessary so that searches can be done against users and groups, as happens when giving access rights to users or roles.

Edit the web.config of the Administration site so that the <membership> and <roleManager> provider entries (inside the <system.web> node) look similar to this:

 <system.web> ............ <membership> <providers> <add name="SymlabsLDAPMembership" type="Microsoft.Office.Server.Security.LDAPMembershipProvider, Microsoft.Office.Server, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71E9BCE111E9429C" server="svds.mycompany.com" port="3890" useSSL="false" userDNAttribute="distinguishedName" useDNAttribute="false" userNameAttribute="userPrincipalName" userContainer="ou=allusers,dc=mycompany,dc=com" userObjectClass="person" userFilter="(ObjectClass=person)" scope="Subtree" otherRequiredUserAttributes="sn,givenName,cn" /> </providers> </membership> <roleManager enabled="true" defaultProvider="AspNetWindowsTokenRoleProvider"> <providers> <remove name="AspNetSqlRoleProvider" /> <add name="SymlabsLDAPRole" type="Microsoft.Office.Server.Security.LDAPRoleProvider, Microsoft.Office.Server, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71E9BCE111E9429C" server="svds.mycompany.com" port="3890" useSSL="false" dnAttribute="distinguishedName" groupNameAttribute="cn" groupMemberAttribute="member" userNameAttribute="userPrincipalName" groupContainer="ou=allgroups,dc=mycompany,dc=com" groupObjectClass="group" groupFilter="(ObjectClass=group)" scope="Subtree" /> </providers> </roleManager> ............ </system.web>

Note that we have specified the servername and portnumber that the Virtual Directory Server instance is running on. You will, no doubt, need to change these settings to match your own configured environment.

Similarly edit the web.config of the internal and external sites with the following entries (inside the <system.web> node):

 <system.web> ............ <membership defaultProvider="SymlabsLDAPMembership"> <providers> <add name="SymlabsLDAPMembership" type="Microsoft.Office.Server.Security.LDAPMembershipProvider, Microsoft.Office.Server, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71E9BCE111E9429C" server="svds.mycompany.com" port="3890" useSSL="false" userDNAttribute="distinguishedName" useDNAttribute="false" userNameAttribute="userPrincipalName" userContainer="ou=allusers,dc=mycompany,dc=com" userObjectClass="person" userFilter="(ObjectClass=person)" scope="Subtree" otherRequiredUserAttributes="sn,givenName,cn" /> </providers> </membership> <roleManager defaultProvider="SymlabsLDAPRole" enabled="true" cacheRolesInCookie="false" cookieName=".PeopleDCRole"> <providers> <add name="SymlabsLDAPRole" type="Microsoft.Office.Server.Security.LDAPRoleProvider, Microsoft.Office.Server, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71E9BCE111E9429C" server="svds.mycompany.com" port="3890" useSSL="false" dnAttribute="distinguishedName" groupNameAttribute="cn" groupMemberAttribute="member" userNameAttribute="userPrincipalName" groupContainer="ou=allgroups,dc=mycompany,dc=com" groupObjectClass="group" groupFilter="(ObjectClass=group)" scope="Subtree" /> </providers> </roleManager> ............ </system.web>

Once again, note that we have specified the servername and portnumber that the Virtual Directory Server instance is running on. You will, no doubt, need to change these settings to match your own configured environment.

In the above configuration files we chose userPrincipalName, which looks like an e-mail address, as the userNameAttribute. This means that users should use their userPrincipalName (say, john@partnerone.com) as their login account. We could equally have chosen the usual sAMAccountName but since users from different ADs can have the same sAMAccountName that choice might have been prone to problems.

When you have finished editing these files and making changes to your configuration, you will need to restart IIS before the changes will become apparent. Once you have restarted IIS, you should test your configuration by giving access rights to users and groups (roles) and trying to login as such users or users of such groups. For instance, ask your partners to create accounts for John and Mary (say, john@partnerone.com and mary@partnertwo.com). Ask PartnerTwo to create the group PartnersUsers and add Mary to it. Ask the administrator of your internal Sharepoint site to give access to user john@partnerone.com and to group PartnersUsers. Once this has been done, you should see the names being resolved and that these appear underlined. By hovering the mouse over the resolved names, you will be able to confirm that the LDAP Membership and Role providers are being used.

Fig-9: Giving LDAP Based Role Access Right to a Group

Finally, try to login as john@partnerone.com and mary@partnertwo.com. In the first case you will be given access on an individual basis. In the second case the access is given on a role basis.

Conclusion

With the configuration suggested in this document, it should be clear that by using Symlabs Virtual Directory Server, you are able to quickly add further external Active Directory instances to the VDS configuration to rapidly provision access to your Sharepoint portal without needing to configure trust relationships between your domains, and with little impact on the existing infrastructure.

For questions and help in integrating Sharepoint with multiple Active Directory and LDAP server instances, or to enable authentication against identity information stored within relational databases, please contact support@symlabs.com.

TOP

Tutorial #7 - Create a unified login resource for two different Active Directory instances

Tutorial #7 - Create a unified login resource for two different Active Directory instances using a Virtual Tree

Click here to download this tutorial as a PDF file.

1 Overview

While it is possible to provide a single authentication resource for multiple Active Directory instances, using only Active Directory, doing so requires that you configure complex trust relationships between the different Active Directory instances that you would like to pool together. Often this can be time consuming and difficult to administer, particularly if all you require is the ability to allow users to authenticate regardless of which Domain they belong to. Furthermore the trust relationship between Domains might have some implications that you want to avoid, when the only real requirement is to have a single place to access the user information of all the Domains. In this tutorial we will explore how you are able to use Symlabs Virtual Directory Server to unify the data stored in two different domains without any need to configure trust relationships between the domains. To do this, we will create a Virtual Tree that can present data from either of the backend Active Directory servers. This solution is highly scalable and can accommodate as many branches and Active Directory instances as required.

In this tutorial, we have set up two domains running on different Active Directory instances hosted on Windows 2003 Servers. The first instance is for a domain called MyCompany, while the second is for a domain called PartnerComp. The MyCompany domain contains users within an organizational unit branch called Managers, while the PartnerComp users are stored across a number of different branches within the Directory. The goal of this tutorial will be to create a virtual tree that contains all of the users stored in each of the different branches on the two Active Directory instances.

Fig-1: Users in the MyCompany domain are stored in a single branch called Managers

Fig-2: Users in the Partnercomp domain are stored in a number of different branches, including Accounting, Sales, Managers and Development.

It is worthwhile noting that while this tutorial is presented for Virtual Directory Server, all of this functionality is available in Symlabs LDAP Proxy and an identical configuration could be used in this environment if required.

2 Create A New Configuration

We will begin by creating a new configuration and attaching the two Active Directories to it as two different ServerGroups.

Click File on the menu bar, then click New.
Click the OK button when asked which server you want to create the new configuration on (the default server is Local).
Enter AD-VirtTree for the filename when prompted, then click the Save button and the following will appear:

Fig-3: New configuration

3.1 Server Group Configuration

Server Groups are the directories where your user information is stored. Examples include Active Directory, Sun Directory Server and Oracle Internet Directory. For this tutorial we will be creating two separate Server Groups that will contain each of our Active Directory instances.

Click on the Output button on the left-hand side of the application and then click on the New Server Group button near the bottom of the screen.
Label the first servergroup as 'MyCompany' and ensure that the ServerGroup type is set to Automatic.
Click on the MyCompany node in the Output section in the configuration navigator to enter the configuration panel for the new Server Group.

Fig-4: Configure the MyCompany server group
Verify that the Protocol is set to ldap.
Under the Servers tab, enter the Hostname / IP Address and the port number (389) for the Active Directory instance that hosts the MyCompany domain.
Click on the Connection Pooling tab and check the 'Use connection pooling' option.
Select the option to 'Use fixed credentials' and enter the Bind DN and password of a trusted user in the MyCompany domain.

Fig-5: Add Connection Pooling to the Server Group

Click OK and then click on the Output node to add another server group.
Label the second servergroup as 'PartnerComp' and ensure that the ServerGroup type is set to Automatic.
Click on the PartnerComp node in the Output section in the configuration navigator to enter the configuration panel for the new Server Group.

Fig-6: Enter the details for the PartnerComp Active Directory instance
Under the Servers tab, enter the Hostname / IP Address and the port number (389) for the Active Directory instance that hosts the PartnerComp domain.
Click on the Connection Pooling tab and check the 'Use connection pooling' option.
Select the option to 'Use fixed credentials' and enter the Bind DN and password of a trusted user in the PartnerComp domain.

Fig-7: Enter connection pooling details for the PartnerComp domain
Click the OK button near the top of the application to save the ServerGroup configuration to memory.

3.2 Listener Configuration

The listener will provide the interface that LDAP clients are able to connect to in order to have access to the virtual tree that we will create.

Click on the Input button on the left-hand side of the application, and then on the New Listener button near the bottom of the screen.
Enter VirtualTree for the new input / listener and then click the Okay button.
Click on the VirtualTree button on the left-hand side of the screen and the following will appear:

Fig-8: Listener configuration

Under the Main Listener Properties tab, make sure the Protocol is set to ldap.
Under the Main Listener Properties tab, set the port to 3890.
Under the Main Listener Properties tab, in the Routing Information box, select the Virtual Tree option.
Click the OK button near the top of the screen to save the Listener configuration.

4 Create a Virtual Tree

You will now need to define a Virtual Tree that will be attached to the listener that you have created. You can get started by clicking on the New Virtual Entry Root button in the Routing Information box on the Main Listener Properties tab of your new listener. This will prompt you for a name for the root entry of your Virtual Tree. This should be the base DN that you wish to use for your tree. In this example, we will use dc=virtcomp,dc=com.

Once you have created the root entry for your Virtual Tree, it should appear in the navigation panel on the left. Click on it, and you will be able to edit the attributes for the virtual entry. You should, at least, define an 'objectclass' attribute and specify the base naming attribute. The objectclass attribute, in this case, can have the values 'top' and 'domain'.

Fig-9: Editing the Virtual Entry Root

You are now able to create a virtual entry, within your Virtual Tree, by simply right-clicking on the root of your virtual tree and clicking on the New Virtual Entry option in the context menu. Use this to create an entry with the RDN 'ou=People'.
As with the root entry, you will need to edit the attributes for your virtual entry, creating an objectclass and a naming attribute. In this case, we are defining an 'organizationalunit' as the objectclass, and the naming attribute 'ou' will have the value 'People'.

Fig-10: Adding and editing a Virtual Entry or branch within your tree

Finally, it is also possible to create Virtual Mount Points within your tree. These mount points are used to create virtual branches where data stored in the backend directories can be attached to the tree. To do this, you can right-click on the virtual entry 'ou=People' in the virtual tree, and select the option to Add a Virtual Mount Point, from the context menu. In this example, we will create a mountpoint for each of the User branches in both of the Active Directory instances.
Provide an appropriate RDN for each new virtual mount point. We will create mountpoints with the following RDNs: 'ou=mycomp'; 'ou=accounting'; 'ou=development'; 'ou=managers'; and 'ou=sales'.
The mountpoint 'ou=mycomp' will be used to contain all of the users stored in the single branch in the MyCompany domain. If you click on the mountpoint that you have created, you will be able to specify the ServerGroup and the DN for the data that you wish to attach. In this case, the ServerGroup should be set to MyCompany, and the DN should be: ou=Managers, dc=mycompany,dc=local.

Fig-11: Setting up a virtual mountpoint to point to the Managers node in the MyCompany domain
For each of the other virtual mount points, we will be attaching the different user branches in the PartnerComp domain. To do this, click on each mountpoint and specify the PartnerComp servergroup as the source to obtain the data, and then specify the DN where the data is stored. For instance, for the Accounting users you would specify a DN of 'ou=accounting,dc=partnercomp,dc=local'. Do this for the remaining mountpoints, ensuring that you specify the correct DN for the location of the userdata that you wish to attach.

Fig-12: Setting up a virtual mountpoint to point to the Accounting node in the PartnerComp domain

Now click on the VirtualTree node in the navigation and click to the Virtual Tree tab. Here, you may want to define a Bind Exception, to forward particular BIND requests on to a backend Server Group. In the Bind Request Exceptions section of the configuration panel, add an entry for the administrative users for each domain (e.g. cn=Administrator,cn=Users,dc=MyCompany,dc=local) and select the server group for the administrator that you are configuring (e.g. MyCompany) as the default servergroup to handle bind requests for this user. While this step is not entirely necessary at this point, as the virtualtree will handle the routing of bind requests for users within the configured tree, you may wish to add these exceptions so that you have an easy way of troubleshooting in the future.

Fig-13: Define a Bind Request Exception for your Virtual Tree

5 Testing the VirtualTree

At this point, your VirtualTree is ready to work. Applications will be able to access user data from two separate Active Directory domains, even if no trust relationship has been established between these domains. You could potentially use this configuration for authentication, or for user management purposes. However, it is best that you test that the configuration is working properly and that you are able to access the data in each of branches of the VirtualTree.

Save the configuration, and then click on the Run button to start it. When the configuration has started, you can open an LDAP Browser, such as the one included with Virtual Directory Server, and test that you are able to connect and browse the Virtual Tree. Remember that you are connecting to the Virtual Directory Server instance, so you should enter the hostname that is being used to run the instance, the port number that you configured for the listener (3890) and the Base DN for the Virtual Tree (dc=virtcomp,dc=com). For the bind DN, use one of the Administrator accounts that you configured a Bind Exception for in the last step of the configuration.

Connect to the VDS instance using an LDAP browser

Fig-14: Connect to the Virtual Directory Server instance using an LDAP browser

Once you have connected, you should be able to expand the Virtual Tree to view the ou=People branch. Under this, you will find each of the mount points that you defined in your configuration. Expand each of these to ensure that they contain the appropriate user entries for each branch, and ensure that the user entries are readable.

Fig-15: Check that the Virtual Mount Points are working and that all of the users are accessible within your virtual tree

6 Grouping users together into a single branch

While the configuration, so far, may be adequate for use by many applications, some applications may expect all of your users to be contained within a single branch. This can be easily accommodated by making use of the Merge Trees plugin that is bundled with Virtual Directory Server.

To add this functionality, we will need to make a few minor modifications to the configuration, including the addition of an automatic processing stage.

First, let's create an entry within the Virtual Tree that we will use to attach the data returned by the Merge Trees plugin. Right click on the Root Node of the virtual tree, and click Add Virtual Entry. Name the entry: ou=allusers.
Click on the new virtual entry, and click the Edit button, to add some basic attributes. Enter an attribute name: 'ou' in the left column of the table, and the value 'allusers' on the right. Also enter an 'objectclass' in the left column, and on the right enter the values 'top' and 'organizationalunit'.

Fig-16: Edit the 'ou=allusers' Virtual Entry that you have created
Click on the Processing node within your configuration navigator and click on the 'New Stage' button to add a processing stage.
Name the processing stage 'MergeUsers' and ensure that it the 'automatic' stage option is set. Click OK.
Click on the MergeUsers stage that you have created, and then click on the Add Plugin button. Scroll through the listed plugins until you see the Merge Trees plugin. Click on it and then click OK.

Fig-17: Select the Merge Trees plugin from the plugin list

Now click on the MergeTrees node that appears under your processing stage.
In the configuration panel for the MergeTrees plugin, first define a condition to only trigger the plugin for requests on the 'ou=allusers,dc=virtcomp,dc=com' BaseDN.
In the Merge Trees part of the configuration, enter the Joined Tree DN as 'ou=allusers,dc=virtcomp,dc=com'
Check the Bind Support option.

Fig-18: Configure the Merge Trees Plugin
In the table, we can define the DN of each branch that we wish to merge, and the servergroup where that branch is hosted. So, first enter 'ou=Managers,dc=MyCompany,dc=local' and select the MyCompany servergroup. Then enter 'ou=accounting,dc=partnercomp,dc=local' and select the PartnerComp servergroup. Do the same for each of the other user branches on the PartnerComp servergroup, taking care to specify the correct DN for each branch.
When you have finished configuring the plugin, click on the VirtualTree listener that you created at the beginning of the configuration.
Click on the Attached Stages tab of the configuration panel, and then in the Pre Virtual Tree Stages table, add the MergeUsers processing stage that you have created.

Fig-19: Attach the Processing Stage to the VirtualTree listener
Now click on the VirtualTree tab in the configuration panel and check the box that says 'Skip PDU with destination'. This will allow the plugin to route the requests to the appropriate backend servers before they are intercepted by the Virtual Tree.

Fig-20: Check the Skip PDU with Destination box in the VitualTree tab

You have now successfully edited the configuration to merge all of your users into a single branch hosted on the virtual tree. Save the configuration. And start it up, so that you can begin testing it.

Open an LDAP browser and, once again, connect to the Virtual Directory Server instance using the configuration information that you used earlier. You should now see that the virtual tree contains an additional node for the organizational unit called 'allusers'. If you expand this node, you will be able to see that all of the users stored across both Active Directory instances have been merged into a single branch.

Fig-21: Open a browser and test that all of your users entries appear in the 'ou=allusers' branch on your virtual tree.

You can now use this virtual branch to act as a single authentication resource for users within both domains, even if the domains have no trust relationship established between them.
TOP

Tutorial #8 - Securing a backend connection with GSSAPI

Click here to download this tutorial as a PDF file.
Click here to view a video demo of this tutorial

1 Overview

Symlabs Virtual Directory Server offers full support for Kerberos backend systems via SASL/GSAPPI. This is particularly useful when you need to secure communications between your Virtual Directory and a Kerberos enabled backend such as Microsoft Active Directory. Although it is possible to encrypt communications using SSL, this requires that you enable SSL on your Active Directory backend, which is not only a cumbersome task, but also results in a measurable performance hit. Since Kerberos is the default authentication and encryption method used within Active Directory environments, it makes sense to ensure that your connections are protected using the native facility provided.

By protecting the connection to your Active Directory backend, you will be able to perform any operation permissable within Active Directory through your Virtual Directory, including the ability to modify password entries. This means that you will be able to enable standard LDAP applications to work perfectly with an Active Directory environment.

This tutorial will explain how to configure Symlabs Virtual Directory Server v5.5 to connect to a Kerberos protected Active Directory backend using GSSAPI. In order to show how this can work across platforms we will configure the Virtual Directory instance on a Linux system and will make use of the MIT Kerberos libraries and tools to authenticate the connection so that Virtual Directory Server can create a Kerberos protected connection pool.

2 Assumptions

VDS is installed on a Linux system and is configured properly.
The MIT Kerberos library packages are installed on the VDS host system.
The Administrator following this tutorial has shell access to the VDS host.
Active Directory is configured and running and is accessible to the VDS Host.

3 Configure the VDS instance

In this example, we will configure a simple pass-thru configuration with a standard LDAP listener to handle client requests on the frontend of the Virtual Directory. We will configure a backend ServerGroup that will contain the connection details for a single Active Directory server, that will service requests for the Virtual Directory. This ServerGroup will be configured to open a connection pool that will be protected using Kerberos through GSSAPI.

Create a new configuration instance, called GSSAPI_AD_Passthru.
In the Output part of the configuration, create a New Automatic ServerGroup and call it GSSAPI_AD.
In the Servers tab, provide the hostname or IP address of your Active Directory instance and set the port to 389.

Fig-1: The Servers Tab for GSSAPI_AD.
On the SASL tab, click the SASL Enabled checkbox to enable SASL/GSSAPI. You can leave the other settings at their default values for now.

Fig-2: The SASL Tab for GSSAPI_AD.
On the Connection Pooling tab, enable the Use Connection Pooling checkbox, and select the option to Use SASL.

Fig-3: The Connection Pooling Tab for GSSAPI_AD.
Finally, in the Input part of the configuration, create a New Listener, set its listening port and set the default ServerGroup to use GSSAPI_AD.

Fig-4: Create a new Listener for your VDS instance.
Save the configuration.

4 Configure Kerberos on the VDS host

Assuming that you have already installed the required MIT Kerberos libraries on the VDS host system, the only remaining configuration step is to ensure that a Kerberos configuration file exists and that it contains the details required to open a connection to the Active Directory instance. Usually this file is stored in/etc/krb5.conf and should look something like this:

[libdefaults]
default_realm = MYCOMPANY.LOCAL
[realms]
MYCOMPANY.LOCAL = {
kdc = ADServer.Mycompany.local
}
[domain_realm]
.mycompany.local = MYCOMPANY.LOCAL
mycompany.local = MYCOMPANY.LOCAL

You will note that this example file has three sections defined:
- libdefaults: sets defaults for Kerberos on your system, e.g.,default realm, default ticket lifetime
- realms: tells where to find the KDCs for each realm
- domain_realm: maps domains to realms
You can define further sections to describe where logging should take place etc, but in order for this to work, a basic configuration such as the example provided above should suffice.
The most notable setting here is the kdc in the realms definition, which describes which system should be connected to in order to obtain a valid Kerberos ticket. In this case, it is the Active Directory instance that will be used as our backend, and it is important that the hostname is specified to exactly match the hostname as it is defined for this within Active Directory. And the VDS host should be able to resolve this hostname to the correct IP address. If you are not certain that this can be done, you can put an entry in your/etc/hosts file to ensure that this works.
In the example configuration file, substitute the MYCOMPANY.LOCAL domain and Kerberos realms to match your own Active Directory domain name.

5 Use KINIT to authenticate against Active Directory, and start your VDS instance

Now that Kerberos is properly configured, the VDS host will need to obtain a TGT (Ticket Granting Ticket) in order to continue to secure its connections to the backend Active Directory Server. This is a fairly simple process, and simply requires that you use the kinit tool provided with MIT Kerberos, in order to authenticate with Active Directory.

Open a console to access the shell.
Ensure that you are the same user that you intend to run the VDS instance as.
Use kinit to authenticate to the Active Directory instance. To do this, simply enter something similar to the following:
```
 kinit Administrator@MYCOMPANY.LOCAL
```
Naturally you should substitute the appropriate domain name, and the user that you wish to connect to the Active Directory instance as. You will be prompted for the user's password, which you should enter.
If the command runs without an error, you have successfully authenticated and the system should have a TGT that it can use to access the Active Directory and encrypt future communications.
Maximize DSGUI and start your configuration.

6 Test your VDS instance and check that GSSAPI is being used

At this point, you have authenticated the VDS Host to Active Directory using the kinit tool. When you started the VDS instance, it will have created a connection pool by opening a number of connections to the backend Active Directory server. These connections are authenticated using the credentials that were specified when you authenticated with kinit. Furthermore, each connection will be encrypted using Kerberos, which is facilitated through the SASL/GSSAPI interface provided by VDS.

All that remains is for you to test that the VDS is working properly.

Open an LDAP browser, we recommend using the bundled Symlabs LDAP Browser to test the connection.
Connect to the VDS instance, by entering the IP address or hostname of the VDS Host and the port number that you have set for the Listener. Enter the Base DN to which you wish to connect on the backend Active Directory server. Provide an appropriate BIND DN and password that you wish to use to browse the directory.

Fig-5: Open an LDAP Browser to connect to your VDS instance
Check that you are able to browse the directory through the VDS proxy that you have created.

Fig-6: Browse the VDS tree to make sure that you have access
Finally, if you wish to check that GSSAPI is being used to encrypt your backend connections, you could either increase the Debug Log Level for Automatic ServerGroups in your VDS configuration under Global Parameters, you could then check the logs of the VDS instance to ensure that SASL/GSSAPI is being used when the connections are opened; or alternatively you could use a TCP traffic sniffing application such as Wireshark to check the actual packets moving between the systems.

TOP

Symlabs Virtual Directory Server Tutorials

Tutorial #1 - Merge Users From Multiple Directories

Tutorial #1 - Merge Users From Multiple Directories

1 Overview

2 Assumptions

3 Create a New Configuration

4 Server Group Configuration

4.1 Add Directory 1

4.2 Add Directory 2

5 Processing Configuration

6 Listener Configuration

7 Save Configuration

8 Launch and Test Configuration

Tutorial #2 - Fragmented Identities

Tutorial #2 - Fragmented Identities

1 Overview

2 Assumptions

3 Create a New Configuration

4 Server Group Configuration

4.1 Add Directory 1

4.2 Add Directory 2

5 Processing Configuration

6 Listener Configuration

7 Save Configuration

8 Launch and Test Configuration

Tutorial #3 - Integrating RDBMS into an LDAP Environment

1 Overview

2 Assumptions

3 Create a New Configuration

4 Server Group Configuration

4.1 Add Directory 1

4.2 Add the RDBMS Server Group

5 Processing Configuration

6 Listener Configuration

7 Save Configuration

8 Launch and Test Configuration

Tutorial #4 - Integrating an RDBMs Into an LDAP Tree

Tutorial #4 - Integrating an RDBMS Into an LDAP Tree

1 Overview

2 Assumptions

3 Open the Existing Configuration from Tutorial 3

4 Add Processing Stages

4.1 Add Join Entries stage

4.2 Add Map Attributes Stage

5 Listener Configuration

6 Save Configuration

7 Launch and Test Configuration

Tutorial #5 - Working with Remote Configurations

Tutorial #5 - Working with Remote Configurations

1 Overview

2 Assumptions

3 Connect to the Remote Virtual Directory Server Host and Configure RAS

4 Start the RAS service on the Remote VDS Host

5 Configure the Local VDS Controller

6 Connect to the Remote Virtual Directory Server Host and Create a New Configuration

Tutorial #6 - Sharepoint Integration with Symlabs Enabled Identity Stores

Sharepoint Integration with Symlabs Enabled Identity Stores

Overview

Configuring Virtual Directory Server

Configuring and Testing Sharepoint

Conclusion

Tutorial #7 - Create a unified login resource for two different Active Directory instances

Tutorial #7 - Create a unified login resource for two different Active Directory instances using a Virtual Tree

1 Overview

2 Create A New Configuration

3.1 Server Group Configuration

3.2 Listener Configuration

4 Create a Virtual Tree

5 Testing the VirtualTree

6 Grouping users together into a single branch

Tutorial #8 - Securing a backend connection with GSSAPI

Tutorial #8 - Securing a backend connection with GSSAPI

1 Overview

2 Assumptions

3 Configure the VDS instance

4 Configure Kerberos on the VDS host

5 Use KINIT to authenticate against Active Directory, and start your VDS instance

6 Test your VDS instance and check that GSSAPI is being used