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.