Frequently Asked Questions
This lesson answers the frequently asked questions users often have when using the JNDI to access LDAP services. Some of the common problems are answered in the Trouble Shooting Tips of the Naming and Directory Operations lesson.
The answer depends on the implementation. This is because the Context and DirContext interfaces do not specify synchronization requirements. The LDAP implementation in the JDK is optimized for single-threaded access. If you have multiple threads accessing the same
Context instance, then each thread needs to lock the
Context instance when using it. This also applies to any
NamingEnumeration that is derived from the same
Context instance. However, multiple threads can access different
Context instances (even those derived from the same initial context) concurrently without locks.
2. Why does the LDAP provider ignore my security environment properties if I do not set theContext.SECURITY_CREDENTIALS (
"java\.naming\.security\.credentials" ) property or set it to the empty string?
If you supply an empty string, an empty
char array, or
null to the
Context\.SECURITY_CREDENTIALS environment property, then an anonymous bind will occur even if the
Context\.SECURITY_AUTHENTICATION property was set to
"simple" . This is because for simple authentication, the LDAP requires the password to be nonempty. If a password is not supplied, then the protocol automatically converts the authentication to
You might be talking to a server that supports only the LDAP v2. See the Miscellaneous lesson of the JNDI Tutorial for an example of how to set the version number.
Try using the
"com\.sun\.jndi\.ldap\.trace\.ber" environment property. If the value of this property is an instance of
java\.io\.OutputStream , then trace information about BER buffers sent and received by the LDAP provider is written to that stream. If the property's value is
null , then no trace output is written.
For example, the following code will send the trace output to
Follow the instructions in the GSS-API/Kerberos v5 Authentication of the JNDI Tutorial for information on how to use Kerberos authentication. To use other authentication mechanisms, see the Using Arbitrary SASL Mechanisms section of the JNDI tutorial.
It really depends on the directory server you are using. Some directory servers won't allow you to change the password if SSL is not enabled but some do allow it. It's good to have SSL enabled to have your password secured in the communication channel.
The attribute name that you are using might be a synonym for another attribute. In this case, the LDAP server might return the canonical attribute name instead of the one that you supplied. When you look in the
Attributes returned by the server, you need to use the canonical name instead of the synonym.
"fax" might be a synonym for the canonical attribute name
"facsimiletelephonenumber" . If you ask for
"fax" , the server will return the attribute named
"facsimiletelephonenumber" . See the Naming and Directory Operations lesson for details on synonyms and other issues regarding attribute names.
An attribute's value can be either
byte\[\] . See the Miscellaneous section of the JNDI Tutorial for information on which attributes' values are returned as
byte\[\] . To do this programmatically, you can use the
instanceof operator to examine the attribute value that you get back from the LDAP provider.
Currently you can't. The LDAP provider returns only attribute values that are either
byte\[\] . See the Miscellaneous section of the JNDI Tutorial.
When you use the following form of
search\(\) , the attribute values are treated as literals; that is, the attribute in the directory entry is expected to contain exactly that value: search(Name name, Attributes matchingAttrs) To use wildcards, you should use the string filter forms of
search\(\) , as follows. search(Name name, String filter, SearchControls ctls)
search(Name name, String filterExpr, ObjectfilterArgs, SearchControls ctls)
For the last form, the wildcard characters must appear in the
filterExpr argument, and not in
filterArgs . The values in
filterArgs are also treated as literals.
A wildcard that appears before or after the attribute value (such as in
"attr=\*I\*" ) indicates that the server is to search for matching attribute values by using the attribute's substring matching rule. If the attribute's definition does not have a substring matching rule, then the server cannot find the attribute. You'll have to search by using an equality or "present" filter instead.
12. Why do I get back only n number of entries when I know there are more in the directory? Some servers are configured to limit the number of entries that can be returned. Others also limit the number of entries that can be examined during a search. Check your server configuration.
Controls are not explained in this tutorial. Check out the JNDI Tutorial.
You must keep count as you enumerate through the results. The LDAP does not provide this information.
getName() always returns a name relative to the target context of the search. So, if the target context satisfies the search filter, then the name returned will be "" (the empty name) because that is the name relative to the target context. See the Search Results section for details.
The LDAP entry was retrieved by following either an alias or a referral, so its name is a URL. See the Search Results lesson for details.
The string forms accept the string representation of a composite name. That is, using a string name is equivalent to calling
new CompositeName\(stringName\) and passing the results to the
DirContext method. The
Name argument can be any object that implements the
Name interface. If it is an instance of
CompositeName , then the name is treated as a composite name; otherwise, it is treated as a compound name.
This is related to the previous question. Yes, you can. NameParser.parse() returns a compound name that implements the
Name interface. This name can be passed to the
Context methods, which will interpret it as a compound name.
19. What's the relationship between the name I use for theContext.SECURITY_PRINCIPAL property and the directory?
You can think of the principal name as coming from a different namespace than the directory. See RFC 2829 and the Security section for details on LDAP authentication mechanisms. The LDAP service provider in the JDK accepts a string principal name, which it passes directly to the LDAP server. Some LDAP servers accept DNs, whereas others support the schemes proposed by RFC 2829.
The LDAP name parser in the JDK is conservative with respect to quoting rules, but it nevertheless produces "correct" names. Also, remember that the names of entries returned by NamingEnumerations are composite names that can be passed back to the
DirContext methods. So, if the name contains a character that conflicts with the composite name syntax (such as the forward slash character "/"), then the LDAP provider will provide an encoding to ensure that the slash character will be treated as part of the LDAP name rather than as a composite name separator.
You can use NameClassPair.getNameInNamespace().