1. Securing Oracle Enterprise Data Quality
  2. Configuring External User Management (LDAP) directly with EDQ
  3. Integrate EDQ with LDAP

Integrate EDQ with LDAP

This section consists of pre-requisites and procedure to integrate EDQ with LDAP.

If you are not using WebLogic, or wish to use more than one LDAP store, you can integrate EDQ directly with LDAP using settings in login.properties. This may also be convenient if WebLogic does not provide a pre-defined Authenticator for your type of LDAP server. For example, AD-LDS, the lightweight LDAP server provided on Windows, is not compatible with Active Directory and you cannot use the WebLogic ActiveDirectoryAuthenticator.

This section covers the settings required in login.properties for simple LDAP integration. Kerberos support, used for Windows integrated authentication, is covered in Configuring EDQ to support Windows Integrated Authentication (Kerberos).

Prerequisites

Before beginning the configuration process, the following information must be gathered:

  • The type of LDAP server in use. EDQ has built-in profiles for Active Directory, Oracle Internet Directory, OpenLDAP (using the inetOrgPerson user schema) and servers using the RFC 2307 (Posix) style user schema.

  • The host name and port of the LDAP server. If your environment contains multiple servers for high availability, you can use more than one host in the configuration. The default LDAP port is 389.

  • The identity and password of an LDAP user which can connect and perform searches. The user identity is normally a full Distinguished Name (DN) but Active Directory also allows shorter forms.

  • The base DN of the LDAP tree. Where possible this is determined automatically from the LDAP RootDSE defaultNamingContext attribute, but if this is not available, it must be provided in login.properties.

  • The name of an LDAP group containing all the users that will be working with EDQ. The group is used to filter the list of users presented for EDQ issue assignment, etc. Without this filter, every user in the LDAP server would be presented, and this is generally not recommended.

Integrating with Active Directory

The rest of this section will cover the detailed steps for an integration with Active Directory. The steps are broadly similar for other types of LDAP server. Initial configuration will not use SSL.

In the walkthrough, these settings are used:

  • Active Directory Domain: EXAMPLE.COM

  • Domain Controller (LDAP server): dc1.example.com. The default, non-SSL, port 389 will be used.

  • LDAP user: cn=netuser,cn=users,dc=example,dc=com. Assuming that the AD username for this user is 'netuser' then you can also use netuser@example.com or example\netuser.

  • Base DN: dc=example,dc=com. When using Active Directory this is determined automatically from the RootDSE.

  • All EDQ users group: edqusers

    Note:

    Ensure that you have a login.properties in the security directory in the EDQ 'local' configuration area. Tomcat installs do not have a default login.properties so just create a new empty file.

  • Global Settings:

    In this example the Active Directory realm will be named 'ad'.

    realms                    = internal, ad
gss                       = false
ldap.prof.useprimarygroup = false

    Define the realm list. The EDQ internal realm is used so that the built-in administrator user 'dnadmin' can be used to set up external group mappings in the EDQ web console. The final setting indicates that the 'primary group' of the user should not be considered in determining group membership. For Active Directory this is always the 'Domain Users' group, containing every user and would not be used for EDQ.

  • Realm name:

    ad.realm = EXAMPLE.COM

    Set the name of the Active Directory domain. If more than one realm is defined in login.properties, a dropdown selector for the realm is present on the EDQ login screens. If you wish this to contain more explanatory text, add a 'label' property: 

    ad.label = Example, Inc. Active directory

  • LDAP server settings: 

    ad.ldap.server = dc1.example.com
ad.ldap.auth   = simple
ad.ldap.user   = cn=netuser,cn=users,dc=example,dc=com
ad.ldap.pw     = <password for the user>

    Set the server name and user information. If the server is omitted EDQ attempts to determine it automatically by a DNS lookup for ldap service records. If the server running EDQ is configured to use the Active Directory domain controllers for DNS, then these records should be setup automatically. Otherwise specify the server in login.properties. Multiple servers can be specified using a comma or space separated list: 

    ad.ldap.server = dc1.example.com, dc2.example.com:2342

    To configure encryption for connections between EDQ and LDAP, add:

    ad.ldap.security = ssl or tls

    If you specify ssl as the value then a connection is made to the SSL port of the LDAP server (normally 636). In this case the certificate used by the LDAP server must be trusted by the JRE running EDQ. If the certificate was not created by a recognized provider, add the server or Root CA certificate to the JRE cacerts trust store using the keytool command. See: https://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.html

    If you specify tls as the property value then a connection is made to the normal non-SSL LDAP port and a StartTLS command is then issued to switch the connection to use TLS encryption. All sensitive information such as passwords is sent after the switch to TLS. In this case, EDQ applies relaxed checks to the server certificate - it need not be trusted by the JRE. If you are concerned about spoofing on the internal network, use SSL for extra checks; otherwise using TLS simplifies the configuration.

  • Configure User Authentication:

    This set of properties defines how a username and password presented to EDQ are verified in LDAP. This is a two-stage process. First a search is done to locate the user record identified by the username. For Active Directory this is done by searching for a user with the sAMAccountName matching the username or the userPrincipalName matching username@DOMAIN. These Active Directory attributes represent the 'short' and 'long' Windows login names.

    If the user record is not found, authentication does not succeed. Then there are three different methods in which the password can be verified:

    • bind: Attempt to connect to LDAP using the discovered user identity and the password. If this does not succeed, authentication fails.

    • password: read the hashed password from the user record and compare it with the supplied password. Most LDAP servers do not allow user password values to be read and this method is rarely applicable. It is sometimes used with Posix style user schemas.

    • compare: Use an LDAP compare operation to check the password. This method can be used with Oracle Internet Directory and can be preferable to 'bind' because it does not involve creating a new session on the LDAP server.

    The default method is 'bind' and this is always used with Active Directory.

    ad.auth            = ldap
ad.auth.bindmethod = simple
ad.auth.binddn     = search: dn

    The 'auth' property sets LDAP-based authentication; other settings are possible if using advanced methods such as Kerberos. The 'bindmethod' property sets the connection method - 'simple' sends the user name and password in clear. The 'binddn' property sets the identity used in the connection attempt; here the DN (Distinguished Name) found from the initial user search is used.

    An alternative bind method is digest-md5 which sends the password in hashed form rather than clear. To use this method, replace the bind properties with:

    ad.auth.bindmethod = digest-md5
ad.auth.binddn     = search: sAMAccountName

    The Windows user name is used for the connection instead of the Distinguished Name - this is required for digest-md5 connections.

    To use LDAP compare for password verification, with Oracle Internet Directory, use these settings:

    oid.auth        = ldap
oid.auth.method = compare

  • LDAP profile:

    These settings define the LDAP schema in use and customise user lookup:

    ad.ldap.profile               = adsldap
ad.ldap.prof.defaultusergroup = edqusers

    The 'adsldap' profile is used with Active Directory. Other pre-defined profiles are:

    • inetorgoidldap: Oracle Internet Directory, with inetOrgPerson users

    • inetorgopenldap: OpenLDAP, with inetOrgPerson users

    • rfc2307ldap: RFC 2307 (Posix) style user records

    The 'defaultusergroup' property defines the group containing all EDQ users.

    LDAP stores in large organizations may include thousands of distinct groups and with no additional filtering, all of these will appear in the external group mapping list on the EDQ web console. To filter the group list to a manageable size, you can add an LDAP group filter:

    ad.ldap.prof.groupsearchfilter = LDAPGROUPFILTER

    where LDAPGROUPFILTER is an LDAP-style filter to select groups. The filter must return any groups used in pre-defined mappings.

    In the EXAMPLE.COM setup all the groups used with EDQ start with the prefix ‘edq' so the filter would be:

    ad.ldap.prof.groupsearchfilter = (cn=edq*)

  • Putting it all together:

    This is the complete login.properties used for the Active Directory integration example: 

    # EXAMPLE.COM LDAP integration
# ----------------------------
 
realms                        = internal, ad
gss                           = false
ldap.prof.useprimarygroup     = false
 
ad.realm                      = EXAMPLE.COM
ad.ldap.server                = dc1.example.com
ad.ldap.auth                  = simple
ad.ldap.user                  = cn=netuser,cn=users,dc=example,dc=com
ad.ldap.pw                    = <password for the user>
ad.auth                       = ldap
ad.auth.bindmethod            = simple
ad.auth.binddn                = search: dn
 
ad.ldap.profile               = adsldap
ad.ldap.prof.defaultusergroup = edqusers

  • Integrating with more than one LDAP store:

    To integrate with multiple LDAP stores, simply define multiple realms and include a block of settings for each:

    realms = internal, ad1, ad2, oid
ad1.realm = …
…
ad2.realm = …
…
oid.realm = … 
…

    If you are using an Active Directory Forest with multiple domains, each domain must be defined as a separate realm in login.properties - EDQ cannot make cross-domain references. For example: 

    realms = internal, aduk, asus
aduk.realm       = UK.EXAMPLE.COM
aduk.ldap.server = DC1.UK.EXAMPLE.COM
…
adus.realm       = US.EXAMPLE.COM
asus.ldap.server = DC1.US.EXAMPLE.COM
…