The issues below are common when configuring LDAP.
Before you can test your searches, you first need to successfully connect to an LDAP server. A shell script, which calls a small Java program, is attached that will allow you to test connection parameters before you use them in the Pentaho BI Server.
The parameters to the script are as follows:
- Pentaho application software LDAP administrative user Distinguished Name $(PentahoDN)
- administrative user password $(PentahoPassword)
- LDAP or ActiveDirectory protocol name $(LDAPProtocol)
- LDAP or ActiveDirectory host $(LDAPHost)
- LDAP or ActiveDirectory port number $(LDAPPort)
- LDAP base search $(BaseSearch)
- optional trust store path $(TrustStore)
An example for $(PentahoDN) is "cn=pentaho,ou=Users,dc=example,dc=com".
For $(PentahoPassword), "HardToGuess2+".
The value of $(LDAPHost) could be "ldap1.public-ldap.example.com" or
"ldap2.secure-ldap.example.com". $(LDAPProtocol) can be either "ldap" or "ldaps" and $(LDAPPort) will usually be "389".
An example $(BaseSearch) could be "ou=Users,dc=example,dc=com".
The parameter $(TrustStore) is relevant only when using secure LDAP. The trust store is necessary if the root of the certificate chain is not available in
jre/lib/security/cacerts. An example is "/lib/security/cacerts".
It is also possible to test the LDAP/ActiveDirectory credentials using the Linux utility "ldapsearch". An example equivalent to LdapConnect.sh would be:
When locating users and their roles within a directory, you can specify a search scope. Spring Security allows you to specify search scope by setting the
searchSubtree property on either or both of
DefaultLdapAuthoritiesPopulator. By setting
true, the search scope is
SearchControls.SUBTREE_SCOPE. Otherwise, the search scope is
If the objects for which you are searching (e.g. users or roles) are located directly under the node denoted by the search base, then set the
searchSubtree property to
false. Otherwise, tell Spring Security to search the entire subtree by setting the
searchSubtree property to
Note: The search base for
FilterBasedLdapUserSearchis specified via its constructor argument index 0. The search base for
DefaultLdapAuthoritiesPopulatoris specified via its constructor argument index 1.
DefaultLdapAuthoritiesPopulatorhas a configurable search scope via its
LdapSearchParamsFactoryImplprovides a way to set a search scope by passing a
SearchControlsinstance into the constructor. The XML below demonstrates this. If no
SearchControlsis supplied via the constructor, the default search scope is
You must be very careful when formatting the
applicationContext-*.xml files. In particular, whitespace is not always stripped from string properties before they are used. While well-formed, the following
FilterBasedLdapUserSearch example contains whitespace the will negatively impact its functioning.
The ampersand character (i.e. &) appears commonly in LDAP search filters. However, this character has special meaning in XML. Therefore, the ampersand character must be escaped in one of two ways:
- Replace the ampersand character with an entity reference.
- Wrap the LDAP search filter value in a
Root Distinguished Name (DN)
With some directory servers, you might need to use (non relative) DNs for your search bases even though you specified a root DN in your LDAP URL. (Spring Security calls an LDAP URL a "provider URL.")
ou=system is the root DN in the LDAP URL
ldap://localhost:10389/ou=system. In the default configuration, the user search base is
ou=users; some directory servers might require a user search base of