You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Emmanuel Lecharny (JIRA)" <ji...@apache.org> on 2009/02/09 01:06:59 UTC

[jira] Commented: (DIRSERVER-1309) Connecting with null password causes wrong LDAP result code

    [ https://issues.apache.org/jira/browse/DIRSERVER-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12671699#action_12671699 ] 

Emmanuel Lecharny commented on DIRSERVER-1309:
----------------------------------------------

OpenGroup is wrong. This behavior is expected by RFC 4513, chap 5.1.2, unless I misinterpreted the RFC :

"5.1.2.  Unauthenticated Authentication Mechanism of Simple Bind

   An LDAP client may use the unauthenticated authentication mechanism
   of the simple Bind method to establish an anonymous authorization
   state by sending a Bind request with a name value (a distinguished
   name in LDAP string form [RFC4514] of non-zero length) and specifying
   the simple authentication choice containing a password value of zero
   length.
   The distinguished name value provided by the client is intended to be
   used for trace (e.g., logging) purposes only.  The value is not to be
   authenticated or otherwise validated (including verification that the
   DN refers to an existing directory object).  The value is not to be
   used (directly or indirectly) for authorization purposes.

   Unauthenticated Bind operations can have significant security issues
   (see Section 6.3.1).  In particular, users intending to perform
   Name/Password Authentication may inadvertently provide an empty
   password and thus cause poorly implemented clients to request
   Unauthenticated access.  Clients SHOULD be implemented to require
   user selection of the Unauthenticated Authentication Mechanism by
   means other than user input of an empty password.  Clients SHOULD
   disallow an empty password input to a Name/Password Authentication
   user interface.  Additionally, Servers SHOULD by default fail
   Unauthenticated Bind requests with a resultCode of
   *unwillingToPerform*."


> Connecting with null password causes wrong LDAP result code
> -----------------------------------------------------------
>
>                 Key: DIRSERVER-1309
>                 URL: https://issues.apache.org/jira/browse/DIRSERVER-1309
>             Project: Directory ApacheDS
>          Issue Type: Bug
>    Affects Versions: 1.5.4
>         Environment: Windows XP
> Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
> ApacheDS 1.5.4
> Sun ONE Directory SDK for Java 4.1
>            Reporter: Stefan Zoerner
>            Priority: Minor
>             Fix For: 2.0.0-RC1
>
>         Attachments: NullPasswordBindTest.java
>
>
> If a client tries to bind to the server with password value "null", the bind fails (OK) and the return code is 53 (LDAP_UNWILLING_TO_PERFORM).
> The expected behaviour according to the Open Group is different: 
> Either we return error code 48 (LDAP_INAPPROPRIATE_AUTH) or 49 (LDAP_INVALID_CREDENTIALS),  or we bind successfully, but accepts this as an anonymous client. 
> IBM Tivoli Directory Server 6.0 for instance raises an RC 48.
> Sun Java System Directory Server 5.2 has chosen option 2 (accepting as anonymous bind).
> Please note that it is tricky to reproduce with JNDI. If you set the password in JNDI explicitly to null, you cause an NPE on the client. I will continue to find a solution here. In the maentime, find attached a test case with Sun ONE Directory SDK for Java 4.1.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.