JDK-4514381 : JNDI does LDAP bind even if Context.SECURITY_AUTHENTICATION is set to "none"
  • Type: Bug
  • Component: core-libs
  • Sub-Component: javax.naming
  • Affected Version: 1.4.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2001-10-13
  • Updated: 2002-04-19
  • Resolved: 2002-04-19
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.1 hopperFixed
Related Reports
Relates :  
Description

Name: ddT132432			Date: 10/12/2001


java version "1.4.0-beta2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta2-b77)
Java HotSpot(TM) Client VM (build 1.4.0-beta2-b77, mixed mode)


One of the problems that I found with regard to using StartTLS with JNDI and
LDAP is that you end up doing two binds, one anonymously and one as the user
that you want to authenticate as.

For example, the following lines taken from the access log on a iPlanet
Directory Server 5.0. As you can see, it first binds as "", and then
as "cn=Directory Manager".

[10/Oct/2001:17:49:08 -0500] conn=19 fd=28 slot=28 connection from 128.135.99.6
to 128.135.99.138
[10/Oct/2001:17:49:08 -0500] conn=19 op=0 BIND dn="" method=128 version=3
[10/Oct/2001:17:49:08 -0500] conn=19 op=0 RESULT err=0 tag=97 nentries=0
etime=0 dn=""
[10/Oct/2001:17:49:08 -0500] conn=19 op=1 EXT oid="1.3.6.1.4.1.1466.20037"
[10/Oct/2001:17:49:08 -0500] conn=19 op=1 RESULT err=0 tag=120 nentries=0
etime=0
[10/Oct/2001:17:49:14 -0500] conn=19 SSL 128-bit RC4
[10/Oct/2001:17:49:14 -0500] conn=19 op=2 BIND dn="cn=Directory Manager"
method=128 version=3
[10/Oct/2001:17:49:14 -0500] conn=19 op=2 RESULT err=0 tag=97 nentries=0
etime=0 dn="cn=directory manager"
[10/Oct/2001:17:49:14 -0500] conn=19 op=3 SRCH base="ou=People, dc=uchicago,
dc=edu" scope=2 filter="(uid=jemiller)" attrs=ALL
[10/Oct/2001:17:49:14 -0500] conn=19 op=3 RESULT err=0 tag=101 nentries=1
etime=0
[10/Oct/2001:17:49:14 -0500] conn=19 op=4 UNBIND
[10/Oct/2001:17:49:14 -0500] conn=19 op=4 fd=28 closed - U1

It does this even though I have Context.SECURITY_AUTHENTICATION set to "none"
initially. IMHO, it should not do a bind at all for performance reasons.

For example, if you use the command-line ldapsearch command that comes with
iPlanet Directory Server, you see that it does not do a bind if you don't
authenticate.

import java.security.*;
import java.util.*;
import javax.naming.*;
import javax.naming.directory.*;
import javax.naming.ldap.*;

public class JNDITLSSearch
{
	public static void main (String[] args)
	{
		try
		{
			if(args.length != 6)
			{
				System.err.println("Usage: JNDITLSSearch host port user password baseDN filter");
				System.exit(-1);
			}
				
			String host = args[0];
			int port = Integer.parseInt(args[1]);
			String user = args[2];
			String password = args[3];
			String baseDN = args[4];
			String filter = args[5];
			Hashtable h = new Hashtable();
			h.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
			h.put(Context.PROVIDER_URL, "ldap://" + host + ":" +port);
			h.put(Context.SECURITY_AUTHENTICATION, "none");
			LdapContext lc = new InitialLdapContext(h, null);
			StartTlsResponse stlsr = (StartTlsResponse)lc.extendedOperation(new StartTlsRequest());
			stlsr.negotiate();
			lc.addToEnvironment(Context.SECURITY_AUTHENTICATION, "simple");
			lc.addToEnvironment(Context.SECURITY_PRINCIPAL, user);
			lc.addToEnvironment(Context.SECURITY_CREDENTIALS,password);
			SearchControls sc = new SearchControls();
			sc.setSearchScope(SearchControls.SUBTREE_SCOPE);	
			NamingEnumeration ne = lc.search(baseDN, filter, sc);
			while(ne.hasMore())
			{
				System.out.println((SearchResult)ne.next());
			}
			lc.close();
		}
		catch(Exception e)
		{
			e.printStackTrace();
			System.exit(-1);
		}
	}
}
(Review ID: 133510) 
======================================================================

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: hopper FIXED IN: hopper INTEGRATED IN: hopper
02-09-2004

EVALUATION The JNDI property java.naming.security.authentication (a.k.a. Context.SECURITY_AUTHENTICATION) does not control whether an LDAP bind operation is performed or not. Setting the property to "none" indicates that an anonymous bind should be performed. See: http://java.sun.com/j2se/1.4/docs/guide/jndi/jndi-ldap-gl.html#JNDIPROPS The JNDI property java.naming.ldap.version controls whether an LDAP bind operation is performed or not. By setting the property to "3" the LDAP provider is configured as an LDAPv3 client and therefore it does not perform an LDAP bind (unless user credentials have been supplied).
02-09-2004

PUBLIC COMMENTS The JNDI property java.naming.security.authentication (a.k.a. Context.SECURITY_AUTHENTICATION) does not control whether an LDAP bind operation is performed or not. Setting the property to "none" indicates that an anonymous bind should be performed. See: http://java.sun.com/j2se/1.4/docs/guide/jndi/jndi-ldap-gl.html#JNDIPROPS The JNDI property java.naming.ldap.version controls whether an LDAP bind operation is performed or not. By setting the property to "3" the LDAP provider is configured as an LDAPv3 client and therefore it does not perform an LDAP bind (unless user credentials have been supplied).
02-09-2004

SUGGESTED FIX There are two subproblems that should be addressed: - If creating an InitialLdapContext, then automatically use LDAP v3 and not send the optional 'bind' for 'none' authentication because InitialLdapContext makes sense only for LDAP v3. This is regardless of the setting of the java.naming.ldap.version property, or perhaps the property may be set automatically to "3" upon invocation of the InitialLdapContext constructors. - If the supplied connection controls is non-null, then need to send the 'bind' even for anonymous authentication because the control(s) need to be used with the 'bind'. ###@###.### 2001-10-29 ------------------------------- Note that by default, there will always be a non-null controls because java.naming.referral is 'ignore', which causes the ManageDsA control to be sent. Is this control used in resolving the bind DN? If it is of no use, then perhaps it could be not sent by default during the bind. ###@###.### 2001-11-07 -----------------------------------------------------------------
07-11-2001