Initial Configuration for Enabling LDAP Authentication¶

To enable the LDAP authentication, global or per database, in both cases, you need to do the following steps:

1. In the LDAP server, do the following:

   1. Create a node for each Virtual DataPort role that you want to assign to the users.

   2. In each one of these nodes, create an attribute that stores the name of the role it represents. The name of this attribute has to be the same in all these nodes.

      Note

      At runtime, when a user tries to connect to a database with LDAP authentication, the Server obtains the name of the roles assigned to the user, from the LDAP server. The role names obtained from the LDAP server that do not exist in Virtual DataPort are ignored. The comparison of role names is case sensitive. In case “Identifiers charset” of the Server (“Identifiers charset” tab on the menu Administration > Server configuration) is restricted, roles obtained from the user are converted to lowercase before the comparison (in case roles were imported in restricted mode too, we could say comparison is case-insensitive in this case).

   3. In each one of these nodes, create an attribute whose value is the Distinguished Name of a user that has this role. That is, a node of a role has to have N attributes with the same name and the value of each of them has to be the Distinguished Name of a user.

   Virtual DataPort defines a special role called serveradmin. Having this role is equivalent to being an administrator user of the Virtual DataPort server, except that it does not grant the privilege of connecting to Virtual DataPort via JMX.

   If you want to grant this role to a user, follow the steps above, for the role serveradmin.

2. Create an LDAP data source that connects to the LDAP server you want to use to check the credentials of users (the section LDAP Sources explains how to create an LDAP data source).

   Note

   If the organization adopted a multi-domain environment, you have to select the check box Use GSSAPI SASL authentication mechanism in the LDAP data source.

   Also, the administrator of the LDAP server (usually, Active Directory) has to establish a trust relationship between the domains, to allow authentication of users from all domains.

3. Create roles in Virtual DataPort (explained in the section Creating Roles) and assign them privileges.

   The name of these roles has to match the names that will be obtained from the LDAP server when authenticating the users.

   With the Wizard “Import Roles from LDAP” wizard, you can easily create in Virtual DataPort all the roles that have been defined in the LDAP server. Note that you still need to assign privileges to the imported roles. The section Creating Roles explains how to use this wizard.

   To grant users the role “serveradmin”, “assignprivileges” or any of the default roles, you cannot create groups in the Active Directory with these names and add users to these groups.

   For example, if in the Active Directory you create a group called “serveradmin” and add users to this group, when these users log in to Virtual DataPort, they will not have this role. That is because when a user logs in, Virtual DataPort ignores the groups assigned in the Active Directory that have the same name as the “default roles”.

   The goal of this behavior is to ensure that only the administrators of Denodo grant administrative privileges to users. Otherwise, the administrators of the Active Directory could grant special privileges to users without going through the approval of the administrators of Denodo.

Enabling Global LDAP Authentication for the Virtual DataPort Server¶

To set up the global LDAP authentication in Virtual DataPort, login with the Administration Tool as an administrator user, click the menu Administration > Server configuration > Server authentication and then, click the tab LDAP.

Enabling Global LDAP Authentication¶

You have to provide the following data:

• Database: select the database of Virtual DataPort where you have created the LDAP data source.

• LDAP data source: select the data source.

• User base: node of the LDAP server that is used as scope to search nodes that represent users.

  You can enter more than one “User base” by clicking on the button beside the User base box. When there is more than one “User base”, the Server searches the user’s node in the first “User base” scope. If the Server does not find the node that represents the user, it searches it in the second “User base” scope. If it also fails, in the third, etc. If the Server does not find the node that represents the user, it denies access to the user.

• Attribute with user name: name of the attribute that contains the user name of users, in the nodes that represent users.

• User search pattern: pattern used to generate the LDAP queries that will be executed to obtain the nodes that represent the users that try to connect to the Server.

• Role base: node of the LDAP server that is used as the scope to search the nodes that represent roles that users of this database can have.

  You can enter more than one “Role base” by clicking on the button beside the “Role base” box. The LDAP query formed with the “Role search” pattern will be executed in every “Role base” scope.

• Attribute with role name: name of the attribute that contains the name of the role, in the nodes that represent roles.

• Role search pattern: pattern used to generate the LDAP queries that will be executed to obtain the nodes that represent the roles of a user. This pattern has to contain the token @{USERDN} or @{USERLOGIN} (it cannot contain both) and optionally, it can also contain @{OBJECT_SID}:

  • @{USERDN} will be replaced with the Distinguished Name of the user that tries to connect to this database. For example, “CN=john,CN=Users,DC=acme,DC=loc”.

  • @{USERLOGIN} will be replaced with the login name of the user that tries to connect to this database. For example, “john”.

  • @{OBJECT_SID} will be replaced with the object security identifier of the user in the Active Directory server. For example, “S-1-5-21-1111111111-2222222222-3333333333-4444”. This value can be useful to retrieve the groups the user that belongs to other domains (Only applicable for multi-domain architectures).

• Assign “allusers” role for every connected user: if selected, the Server will grant the privileges of the role “allusers” to all the users that log in successfully even if this role has not been assigned to the user in the LDAP server.

  For example, if you want all users to have read access over a particular database, select this option and grant this privilege to the role “allusers”.

  This option does not modify the roles granted to the user in the LDAP server. This means that if you later clear this check box, the users that log in will not have the privileges granted by the role “allusers” anymore.

• Session attribute mapping: you can define a mapping between LDAP attributes from the authenticated user and attributes which will be added to the user session. The name on Virtual DataPort is represented by Session Attribute column, and the name on the LDAP is the one specified on Authentication Attribute.

  For example, if the LDAP user has an attribute department, you can create a mapping to a user_department Session Attribute which will be added to the user session on Virtual DataPort. The user_department attribute is accessible to functions such GETVAR and to the Global Security Policies as attribute of the user’s session.

You do not need to restart to apply these changes.

If some users will log in to Virtual DataPort with a login name that has the domain (e.g. “jsmith@contoso.com”), execute the following command and restart Virtual DataPort to apply the change:

SET 'com.denodo.vdb.security.UserManager.UseLDAPDomainName' = 'true';

This also applies when enabling LDAP authentication on a specific database instead of for the server.

Enabling LDAP Authentication for a Virtual DataPort Database¶

Virtual DataPort allows using the LDAP authentication for a database. You can enable the LDAP authentication for an existent database or create a new database with LDAP authentication. Both processes are similar. First, open the Virtual DataPort Administration Tool, click Database management on the Administration menu. Next, to enable the LDAP authentication for an existent database, select the database and then click Edit. Instead, if you want to create a database with LDAP authentication, click New.

Creating a new database with LDAP authentication¶

You have to provide the following data:

• Name of the database.

• Description of the database (optional).

• Identifiers charset: if you select Default, the database will use the setting configured for the entire Server (see section Identifiers Charset).The section Element Names (Identifiers) of the VQL Guide explains in detail the differences between the Restricted and the Unicode charset.

• Authentication type: LDAP.

• The section Enabling Global LDAP Authentication for the Virtual DataPort Server explains the meaning of the next fields of the form.

• Use data source credentials to obtain user roles: when a user tries to connect to a database with LDAP authentication, the Server validates the password she provided and then, it executes a LDAP query to obtain the roles of the user.

  If this check box is selected, the Server executes this LDAP query using the credentials of the LDAP data source selected in the “LDAP data source” list of this dialog.

  If this check box is cleared, the LDAP query is executed using the credentials of the user that is trying to connect to this database.

The LDAP Authentication Process¶

This section describes how Virtual DataPort authenticates users that connect to a database with LDAP authentication.

The explanation below also applies for when the user connects to the Server using Kerberos authentication or a web service with SAML authentication.

Let us say that we have created database with LDAP authentication and that the user “john” tries to connect to this database.

1. The Server performs an LDAP query to obtain the node that represents the user “john”. This LDAP query searches the node whose attribute “Attribute with user name” has the value of the user name provided by the user (in this case “john”), using the “User search pattern” in the “User base” scope. If the query does not return any node and there is more than one “User base”, the Server performs the same search in the second “User base” scope. If it does not find the node, it uses the third “User base”, etc. If it does not find any matching node, the Server denies access to the user.

   To perform these queries, the Server connects to the LDAP server with the credentials of the data source.

   Note

   Virtual DataPort would avoid querying the LDAP server when the LDAP Roles Cache is configured. See section Enabling the LDAP Roles Cache for more information.

2. After obtaining the user’s LDAP node, the Server tries to log in the LDAP server with the Distinguished Name (DN) of this node and the password provided by the user. If the password is refused by the LDAP server, the Server denies access to the user.

   This step is skipped if the user connected to the Server using Kerberos authentication or a web service with SAML authentication. The reason is that at this point, the credentials of the user are already validated; this process is to obtain the roles associated to the user.

3. If the credentials of the user are correct, the Server obtains her roles. To do this, it executes an LDAP query. The query is built replacing the token @{USERDN} or @{USERLOGIN} of “Role search pattern”.

   In this example, the pattern has “@{USERDN}”, which is replaced with the Distinguished Name of the user’s LDAP node. This results in something like this: (&(member=CN=john,CN=Users,DC=acme,DC=loc)(objectClass=group))

   The Server executes this LDAP query in the “Role base” scope, in order to obtain the nodes that represent the user’s roles. If there is more than one “Role base”, the LDAP query will be executed from all the “Role base” scopes and the result is the union of the result of each query.

   If the “Use data source credentials to obtain user roles” check box is selected, the Server executes this LDAP query using the credentials of the LDAP data source associated with the database. Otherwise, the query is executed using the credentials of the user that is trying to connect to this database. When the user connected to the Server using Kerberos authentication or a web service with SAML authentication, the Server also executes this LDAP query using the credentials of the LDAP data source.

4. After obtaining the roles’ nodes, the Server executes another LDAP query to obtain the name of the roles assigned to the user from the “Attribute with Role name” attribute of these nodes.

   If the check box “Use data source credentials to obtain user roles” of the database’s configuration is selected, the Server uses the credentials of the data source to execute this query. If this check box is cleared, this LDAP query is executed using the credentials of the user that is trying to connect to this database. When the user connected to the Server using Kerberos authentication or a web service with SAML authentication, the Server also executes this LDAP query using the credentials of the LDAP data source.

   Note

   If a role name obtained from the LDAP server does not exist in Virtual DataPort, it is ignored and the user will have the privileges of the other roles that do exist. If none of the role names obtained from the LDAP server exists in Virtual DataPort, “normal” users will not be able to connect to this database (“administrator” users will be able to connect to this database anyway because they by-pass this type of authentication).

The appendix Useful Tools to Debug Issues with Active Directory or Other LDAP Servers contains a list of tools useful to debug problems related to Active Directory and other LDAP servers.

Configuring a Database with LDAP Authentication and Dynamic Groups¶

In some LDAP services, there are two ways to define membership of a group: statically and dynamically:

• Static groups: they enumerate their member objects explicitly.

• Dynamic groups: instead of enumerating their members, they define an LDAP URL that matches only for group members. In dynamic groups, the members do share a common attribute or set of attributes that are defined in the memberURL filter.

When a user connects to a database with LDAP authentication, the Server retrieves the groups that this user belongs to, in order to know her roles.

By default, Virtual DataPort only supports static groups. This section explains how to configure Virtual DataPort to be able to work with LDAP dynamic groups.

There are several options depending on if you want all the databases with LDAP authentication to work with dynamic groups or only some of them. Note that an LDAP authenticated database can work with either static groups or dynamic groups. Not both.

Option 1: All the LDAP authenticated databases will work with dynamic groups but not with static groups.

Execute the following statements on the VQL Shell of the Administration Tool:

SET 'com.denodo.vdb.security.LDAPUserGroupRetriever.instanceClassName'
    = 'com.denodo.vdb.security.DynamicLDAPUserGroupRetriever';

SET 'com.denodo.vdb.security.DynamicLDAPUserGroupRetriever.memberURL'
    = '<member URL>';

SET 'com.denodo.vdb.security.DynamicLDAPUserGroupRetriever.userMatchPattern'
    = '<LDAP filter>';

In the second statement, <memberURL> is the attribute that contains the LDAP URL used to obtain the dynamic group of the users.

In the third statement, <LDAP filter> is the filter that matches if an LDAP user is the same user that it is trying to connect to Virtual DataPort (this property will usually contain the @{USERLOGIN} and @{USERDN} variables)

Example of <member URL>: memberURL

Example of <LDAP filter>: &(uid=@{USERLOGIN})

Option 2: all the LDAP authenticated databases will work with dynamic groups, except one.

Execute the following statements on the VQL Shell:

# This statement makes the database <databaseName> work with static
# groups.
SET 'com.denodo.vdb.security.LDAPUserGroupRetriever.instanceClassName[.<databaseName>]' =
    'DefaultLDAPUserGroupRetriever';

SET 'com.denodo.vdb.security.LDAPUserGroupRetriever.instanceClassName'
    = 'com.denodo.vdb.security.DynamicLDAPUserGroupRetriever';

SET 'com.denodo.vdb.security.DynamicLDAPUserGroupRetriever.memberURL'
    = '<member URL>';

SET 'com.denodo.vdb.security.DynamicLDAPUserGroupRetriever.userMatchPattern'
    = '<LDAP filter>';

In the first statement, <databasename> is the name of the LDAP-authenticated database that will authenticate users that belong to static groups. The other databases will authenticate users from dynamic groups.

Option 3: one or more LDAP authenticated databases will work with dynamic groups. The other LDAP authenticated databases will work with static groups.

Execute the following statements on the VQL Shell. Execute these statements for each database that you want that it uses dynamic groups.

SET 'com.denodo.vdb.security.LDAPUserGroupRetriever.instanceClassName[.<databaseName>]'
    = 'DynamicLDAPUserGroupRetriever';

SET 'com.denodo.vdb.security.DynamicLDAPUserGroupRetriever.<databaseName>.memberURL'
    = '<member URL>';

SET 'com.denodo.vdb.security.DynamicLDAPUserGroupRetriever.<databaseName>.userMatchPattern'
    = '<LDAP filter>';

Every time a user connects to an LDAP authenticated database, the Server performs an LDAP query to obtain the groups that the user belongs to. When the database is configured to work with dynamic groups, the Server performs more LDAP searches than with static groups. The reason is that with dynamic groups, the Server launches an additional LDAP search, for each group. If there are a lot of groups, the Server will perform a lot of LDAP searches every time a user connects to that database.

Example of setting up dynamic groups

Follow these steps to create a database called “dynamicdb” that authenticate its users with dynamic groups:

1. Execute the following statements on the VQL Shell:

   SET 'com.denodo.vdb.security.LDAPUserGroupRetriever.instanceClassName'
       = 'com.denodo.vdb.security.DefaultLDAPUserGroupRetriever';
   
   SET 'com.denodo.vdb.security.LDAPUserGroupRetriever.instanceClassName.dynamicdb'
       = 'com.denodo.vdb.security.DynamicLDAPUserGroupRetriever';
   
   SET 'com.denodo.vdb.security.DynamicLDAPUserGroupRetriever.dynamicdb.memberURL'
       = 'memberURL';
   
   SET 'com.denodo.vdb.security.DynamicLDAPUserGroupRetriever.dynamicdb.userMatchPattern'
       = '(&(uid=@{USERLOGIN}))';
   

2. Restart the Server and create the database with the following statement:

   CREATE OR REPLACE DATABASE dynamicdb
     'Description: LDAP-Authenticated database (dynamic groups)'
     AUTHENTICATION LDAP admin.ldapds_bertone
     USERBASE = 'ou=users,dc=denodo,dc=com'
     USERATTRIBUTENAME = 'uid'
     USERSEARCH = '(objectClass=person)'
     ROLEBASE = 'dc=denodo,dc=com'
     ROLEATTRIBUTENAME = 'cn'
     ROLESEARCH = '(objectClass=groupOfURLs)';
   

Enabling the LDAP Roles Cache¶

When enabling the “LDAP Roles Cache”, Virtual DataPort stores in memory - for a limited time - the roles of each user that logs in to Virtual DataPort, when the roles of said user are obtained from an LDAP server (e.g. Active Directory). That is, users with Kerberos authentication, OAuth and SAML with the option to retrieve the roles from an LDAP server or with user and password, retrieving the roles from an LDAP server. This reduces the connection time the next time the same user logs in because Virtual DataPort only has to retrieve the roles of the user from the LDAP server (e.g. Active Directory) the first time this user logs in. When the feature is disabled, Virtual DataPort queries the LDAP server for every log in attempt.

This feature is disabled by default. To enable it, log in with an administrator account and execute this command:

SET 'com.denodo.vdb.security.LDAPRolesCache.UseCache' = 'true';

You do not need to restart Virtual DataPort to apply the change. To disable this feature, execute this command but setting the property to “false”.

The roles of a user are stored in memory for a period of time (by default, 10 minutes). After 10 minutes since the roles of this user were stored in memory, they are removed. The next time this user opens a connection, the roles of this user will be retrieved from the LDAP server again and stored in memory.

To modify the settings of the LDAP Roles Cache, execute the following statements on the VQL Shell:

-- To modify for how long the roles of a user are stored in memory.
-- Default value: 10 minutes
SET 'com.denodo.vdb.security.LDAPRolesCache.ExpirationTimeMinutes' = '5';

-- To modify the time, in milliseconds, how often the tasks that removes the expired entries from this cache runs.
-- Default value: 60000 (1 minute)
SET 'com.denodo.vdb.security.LDAPRolesCache.CacheMaintenancePeriodMilliseconds' = '120000';