Details
-
Bug
-
Status: Open
-
Minor
-
Resolution: Unresolved
-
10.8.1.2
-
None
-
Normal
-
Security
Description
The test fails unless Java system property "derbyTesting.ldapPort" is supplied, but it is not used, so the test cannot be used against an LDAP serves that uses anything than 389 (default port).
Additionally, the test property "derbyTesting.dnString" is not what it purports to be, since the parameter given is used as a value for "o=" when doing a search. The property should contain the entire relevant dn (distinguised name) string which is the root of the lookup, I think, e.g.
-DderbyTesting.dnString="o=myOrg" or
-DderbyTesting.dnString="dc=example,dc=com"
cf. e.g. http://www.ldapman.org/articles/intro_to_ldap.html (quote):
"The top level of the LDAP directory tree is the base, referred to as the "base DN." A base DN usually takes one of the three forms:"
- o=foobar.com (base DN derived from the company's Internet presence)
- o="FooBar, Inc.", c=US (base DN in X.500 format)
- dc=foobar, dc=com (base DN derived from the company's DNS domain components)
This will make the test more independent of actual LDA server organization.
Similarly, the test specifies that ou=People should be used. I this this should be parameterizable as well.
The attempt to store the dn locally using the "derby.user.<user>" (to avoid lookup) doesn't seem to be working. I think there is a bug in LDAPAuthenticationSchemeImpl as well in this regard:
#authenticateUser:
:
// Retrieve the user's DN (Distinguished Name)
// If we're asked to look it up locally, do it first
// and if we don't find it, we go against the LDAP
// server for a look-up (search)
//
if (useUserPropertyAsDN)
userDN =
authenticationService.getProperty(
org.apache.derby.iapi.reference.Property.USER_PROPERTY_PREFIX);
The lookup happens against the property "derby.user.", the username is not appended first, so userDN always returns null, and search ensues before bind. I'll file a separate issue for this.