On 11/08/11 20:42, Kiran Ayyagari wrote:
1. Does the error message mean the user entry was actually found (as
implied)?
yes, indeed
2. Does the error message really mean the attribute value cannot be read
from the directory, or simply that a hash was made that did not match the
SASL response from the client?
as you already mentioned that the password is in clear text so there
seems to be some other factor that is causing this
but which is not entirely clear to me at the moment
3. Does the SASL logic run under the authenticating user's credentials and
is constrained by that user's ACI's? (I can't think what else it could use
except some kind of "super-user" privilege that puts it outside the
directory's ACI's).
no the attribute fetching is done by using the admin session, (for
this the default internal admin
account uid=admin,ou=system is used)
Thanks very much for your clear and helpful answers, Kiran. You have
saved me a lot of time.
do you have any stack traces on the server logs?
Here is the test user entry as seen by a directory administrator:
#
# LDAPv3
# base <o=PingToo.com> with scope subtree
# filter: (&(objectclass=top)(uid=testDigest))
# requesting: cn sn givenName ou userPassword dontcare
#
# testdigest, People, PingToo.com
dn: uid=testdigest,ou=People, o=PingToo.com
givenname: Brian
cn: Brian Testing Digest
sn: ClearPassword
userpassword:: c2VjcmV0
ou: People
# search result
# numResponses: 2
# numEntries: 1
search ended with rc 0
... and then the cleartext password is...
echo c2VjcmV0 | base64 -d -
secret
Using Directory Studio authenticating as this test user and NO
encryption, when I click the "check network parameter" button, the
connection is established successfully.
On the authentication tab, DIGEST-MD5, correct bindDN, password and SASL
realm, QOP is authentication only and strength is high. When I click the
"check authentication button" it fails with this:
The authentication failed
- [LDAP: error code 49 - INVALID_CREDENTIALS: DIGEST-MD5: cannot
acquire password for uid=testDigest,ou=people,o=pingtoo.com in realm :
pingtoo.com]
javax.naming.AuthenticationException: [LDAP: error code 49 -
INVALID_CREDENTIALS: DIGEST-MD5: cannot acquire password for
uid=testDigest,ou=people,o=pingtoo.com in realm : pingtoo.com]
at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3041)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2987)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2789)
at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2703)
at com.sun.jndi.ldap.LdapCtx.ensureOpen(LdapCtx.java:2602)
at com.sun.jndi.ldap.LdapCtx.ensureOpen(LdapCtx.java:2576)
at com.sun.jndi.ldap.LdapCtx.reconnect(LdapCtx.java:2572)
at
javax.naming.ldap.InitialLdapContext.reconnect(InitialLdapContext.java:173)
at
org.apache.directory.studio.connection.core.io.jndi.JNDIConnectionWrapper$7.run(JNDIConnectionWrapper.java:1055)
at
org.apache.directory.studio.connection.core.io.jndi.JNDIConnectionWrapper.runAndMonitor(JNDIConnectionWrapper.java:1272)
at
org.apache.directory.studio.connection.core.io.jndi.JNDIConnectionWrapper.doBind(JNDIConnectionWrapper.java:1065)
at
org.apache.directory.studio.connection.core.io.jndi.JNDIConnectionWrapper.bind(JNDIConnectionWrapper.java:254)
at
org.apache.directory.studio.connection.core.jobs.CheckBindRunnable.run(CheckBindRunnable.java:80)
at
org.apache.directory.studio.connection.ui.RunnableContextRunner$1.run(RunnableContextRunner.java:123)
at
org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
The server's wrapper.log and also the rolling log have only these two
messages:
INFO | jvm 1 | 2011/08/12 15:54:45 | [15:54:45] INFO
[org.apache.directory.server.ldap.handlers.BindHandler] - Continuation
token had length 167
INFO | jvm 1 | 2011/08/12 15:54:45 | [15:54:45] ERROR
[org.apache.directory.server.ldap.handlers.BindHandler] -
INVALID_CREDENTIALS: DIGEST-MD5: cannot acquire password for
uid=testDigest,ou=people,o=pingtoo.com in realm : pingtoo.com
How easy would it be to turn on more messages from the server... do I
just need to change the log4j properties to say:
log4j.logger.org.apache.directory.shared.ldap.name=DEBUG
I will try to do the test again tomorrow with debugging turned on unless
you see something useful above.
Brian
