Trying to figure out if this search is being denied. I wouldn't think so but the last 3 lines at the end suggest otherwise.
5552876b conn=1000 fd=21 ACCEPT from IP=172.29.34.47:42310 (IP=0.0.0.0:389) 5552876b conn=1000 op=0 BIND dn="uid=an_admin,ou=People,dc=doesn't_matter,dc=com" method=128 5552876b => bdb_entry_get: found entry: "uid=an_admin,ou=people,dc=doesn't_matter,dc=com" 5552876b => bdb_entry_get: found entry: "cn=defaultpp,ou=policies,dc=doesn't_matter,dc=com" 5552876b => access_allowed: result not in cache (userPassword) 5552876b => access_allowed: auth access to "uid=an_admin,ou=People,dc=doesn't_matter,dc=com" "userPassword" requested 5552876b => acl_get: [1] attr userPassword 5552876b => acl_mask: access to entry "uid=an_admin,ou=People,dc=doesn't_matter,dc=com", attr "userPassword" requested 5552876b => acl_mask: to value by "", (=0) 5552876b <= check a_dn_pat: self 5552876b <= check a_dn_pat: anonymous 5552876b <= acl_mask: [2] applying auth(=xd) (stop) 5552876b <= acl_mask: [2] mask: auth(=xd) 5552876b => slap_access_allowed: auth access granted by auth(=xd) 5552876b => access_allowed: auth access granted by auth(=xd) 5552876b conn=1000 op=0 BIND dn="uid=an_admin,ou=People,dc=doesn't_matter,dc=com" mech=SIMPLE ssf=0 5552876b => bdb_entry_get: found entry: "uid=an_admin,ou=people,dc=doesn't_matter,dc=com" 5552876b conn=1000 op=0 RESULT tag=97 err=0 text= 5552876b conn=1000 op=1 BIND anonymous mech=implicit ssf=0 5552876b conn=1000 op=1 BIND dn="uid=an_admin,ou=People,dc=doesn't_matter,dc=com" method=128 5552876b => bdb_entry_get: found entry: "uid=an_admin,ou=people,dc=doesn't_matter,dc=com" 5552876b => bdb_entry_get: found entry: "cn=defaultpp,ou=policies,dc=doesn't_matter,dc=com" 5552876b => access_allowed: result not in cache (userPassword) 5552876b => access_allowed: auth access to "uid=an_admin,ou=People,dc=doesn't_matter,dc=com" "userPassword" requested 5552876b => acl_get: [1] attr userPassword 5552876b => acl_mask: access to entry "uid=an_admin,ou=People,dc=doesn't_matter,dc=com", attr "userPassword" requested 5552876b => acl_mask: to value by "", (=0) 5552876b <= check a_dn_pat: self 5552876b <= check a_dn_pat: anonymous 5552876b <= acl_mask: [2] applying auth(=xd) (stop) 5552876b <= acl_mask: [2] mask: auth(=xd) 5552876b => slap_access_allowed: auth access granted by auth(=xd) 5552876b => access_allowed: auth access granted by auth(=xd) 5552876b conn=1000 op=1 BIND dn="uid=an_admin,ou=People,dc=doesn't_matter,dc=com" mech=SIMPLE ssf=0 5552876b => bdb_entry_get: found entry: "uid=an_admin,ou=people,dc=doesn't_matter,dc=com" 5552876b conn=1000 op=1 RESULT tag=97 err=0 text= 5552876b begin get_filter 5552876b PRESENT 5552876b end get_filter 0 5552876b conn=1000 op=2 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" 5552876b conn=1000 op=2 SRCH attr=* + altServer changelog firstChangeNumber lastChangeNumber lastPurgedChangeNumber namingContexts subschemaSubentry supportedAuthPasswordSchemes supportedControl supportedExtension supportedFeatures supportedLDAPVersion supportedSASLMechanisms vendorName vendorVersion 5552876b => test_filter 5552876b PRESENT 5552876b => access_allowed: search access to "" "objectClass" requested 5552876b => slap_access_allowed: backend default search access granted to "uid=an_admin,ou=People,dc=doesn't_matter,dc=com" 5552876b => access_allowed: search access granted by read(=rscxd) 5552876b <= test_filter 6 5552876b => access_allowed: read access to "" "entry" requested 5552876b => slap_access_allowed: backend default read access granted to "uid=an_admin,ou=People,dc=doesn't_matter,dc=com" 5552876b => access_allowed: read access granted by read(=rscxd) 5552876b => access_allowed: result not in cache (objectClass) 5552876b => access_allowed: read access to "" "objectClass" requested 5552876b => slap_access_allowed: backend default read access granted to "uid=an_admin,ou=People,dc=doesn't_matter,dc=com" 5552876b => access_allowed: read access granted by read(=rscxd) 5552876b => access_allowed: result was in cache (objectClass) 5552876b => access_allowed: result not in cache (structuralObjectClass) 5552876b => access_allowed: read access to "" "structuralObjectClass" requested 5552876b => slap_access_allowed: backend default read access granted to "uid=an_admin,ou=People,dc=doesn't_matter,dc=com" 5552876b => access_allowed: read access granted by read(=rscxd) 5552876b => access_allowed: result not in cache (configContext) 5552876b => access_allowed: read access to "" "configContext" requested 5552876b => slap_access_allowed: backend default read access granted to "uid=an_admin,ou=People,dc=doesn't_matter,dc=com" 5552876b => access_allowed: read access granted by read(=rscxd) 5552876b => access_allowed: result not in cache (namingContexts) 5552876b => access_allowed: read access to "" "namingContexts" requested 5552876b => slap_access_allowed: backend default read access granted to "uid=an_admin,ou=People,dc=doesn't_matter,dc=com" 5552876b => access_allowed: read access granted by read(=rscxd) 5552876b => access_allowed: result was in cache (namingContexts) 5552876b => access_allowed: result not in cache (monitorContext) 5552876b => access_allowed: read access to "" "monitorContext" requested 5552876b => slap_access_allowed: backend default read access granted to "uid=an_admin,ou=People,dc=doesn't_matter,dc=com" 5552876b => access_allowed: read access granted by read(=rscxd) 5552876b => access_allowed: result not in cache (supportedControl) 5552876b => access_allowed: read access to "" "supportedControl" requested 5552876b => slap_access_allowed: backend default read access granted to "uid=an_admin,ou=People,dc=doesn't_matter,dc=com" 5552876b => access_allowed: read access granted by read(=rscxd) 5552876b => access_allowed: result was in cache (supportedControl) 5552876b => access_allowed: result was in cache (supportedControl) 5552876b => access_allowed: result was in cache (supportedControl) 5552876b => access_allowed: result was in cache (supportedControl) 5552876b => access_allowed: result was in cache (supportedControl) 5552876b => access_allowed: result was in cache (supportedControl) 5552876b => access_allowed: result was in cache (supportedControl) 5552876b => access_allowed: result was in cache (supportedControl) 5552876b => access_allowed: result not in cache (supportedExtension) 5552876b => access_allowed: read access to "" "supportedExtension" requested 5552876b => slap_access_allowed: backend default read access granted to "uid=an_admin,ou=People,dc=doesn't_matter,dc=com" 5552876b => access_allowed: read access granted by read(=rscxd) 5552876b => access_allowed: result was in cache (supportedExtension) 5552876b => access_allowed: result was in cache (supportedExtension) 5552876b => access_allowed: result was in cache (supportedExtension) 5552876b => access_allowed: result not in cache (supportedFeatures) 5552876b => access_allowed: read access to "" "supportedFeatures" requested 5552876b => slap_access_allowed: backend default read access granted to "uid=an_admin,ou=People,dc=doesn't_matter,dc=com" 5552876b => access_allowed: read access granted by read(=rscxd) 5552876b => access_allowed: result was in cache (supportedFeatures) 5552876b => access_allowed: result was in cache (supportedFeatures) 5552876b => access_allowed: result was in cache (supportedFeatures) 5552876b => access_allowed: result was in cache (supportedFeatures) 5552876b => access_allowed: result was in cache (supportedFeatures) 5552876b => access_allowed: result not in cache (supportedLDAPVersion) 5552876b => access_allowed: read access to "" "supportedLDAPVersion" requested 5552876b => slap_access_allowed: backend default read access granted to "uid=an_admin,ou=People,dc=doesn't_matter,dc=com" 5552876b => access_allowed: read access granted by read(=rscxd) 5552876b => access_allowed: result not in cache (supportedSASLMechanisms) 5552876b => access_allowed: read access to "" "supportedSASLMechanisms" requested 5552876b => slap_access_allowed: backend default read access granted to "uid=an_admin,ou=People,dc=doesn't_matter,dc=com" 5552876b => access_allowed: read access granted by read(=rscxd) 5552876b => access_allowed: result not in cache (entryDN) 5552876b => access_allowed: read access to "" "entryDN" requested 5552876b => slap_access_allowed: backend default read access granted to "uid=an_admin,ou=People,dc=doesn't_matter,dc=com" 5552876b => access_allowed: read access granted by read(=rscxd) 5552876b => access_allowed: result was in cache (entryDN) 5552876b => access_allowed: result not in cache (subschemaSubentry) 5552876b => access_allowed: read access to "" "subschemaSubentry" requested 5552876b => slap_access_allowed: backend default read access granted to "uid=an_admin,ou=People,dc=doesn't_matter,dc=com" 5552876b => access_allowed: read access granted by read(=rscxd) 5552876b => access_allowed: result was in cache (subschemaSubentry) 5552876b conn=1000 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= 5552876b begin get_filter 5552876b EQUALITY 5552876b end get_filter 0 5552876b conn=1000 op=3 SRCH base="cn=accesslog" scope=2 deref=0 filter="(uid=global.admin)" 5552876b => access_allowed: search access to "cn=accesslog" "entry" requested 5552876b => acl_get: [1] attr entry 5552876b => acl_mask: access to entry "cn=accesslog", attr "entry" requested 5552876b => acl_mask: to all values by "uid=an_admin,ou=people,dc=doesn't_matter,dc=com", (=0) 5552876b <= check a_dn_pat: cn=admin,dc=doesn't_matter,dc=com 5552876b <= check a_dn_pat: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth 5552876b <= acl_mask: no more <who> clauses, returning =0 (stop) 5552876b => slap_access_allowed: search access denied by =0 5552876b => access_allowed: no more rules 5552876b conn=1000 op=3 SEARCH RESULT tag=101 err=32 nentries=0 text=
So the application is a java application and the developers haven't a clue on how to debug the java ldap side. I am not sure why it's looking at accesslog in the context of this connection, and it shouldn't have access to accesslog but it shouldn't matter anyway, accesslog is database{1} and the actual suffix to be searched is database{3}
User uid=an_admin,ou=People,dc=doesn't_matter,dc=com is pretty much allowed to do anything in the suffixed database {dc=doesn't_matter,dc=com}
My contention is that there isn't an error here but the application isn't happy with the new setup and as I said, they are not knowledgeable about how to debug from the java side.
Does this log indicate an error? (I know err=32 is no such object)
Craig
--On Wednesday, May 13, 2015 12:32 AM +0000 Craig White CWhite@skytouchtechnology.com wrote:
5552876b conn=1000 op=3 SRCH base="cn=accesslog" scope=2 deref=0 filter="(uid=global.admin)"
My contention is that there isn't an error here but the application isn't happy with the new setup and as I said, they are not knowledgeable about how to debug from the java side.
The above log line clearly indicates the client issued a search using a base of cn=accesslog. This would be a bug in the java code.
--Quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
-----Original Message----- From: openldap-technical [mailto:openldap-technical-bounces@openldap.org] On Behalf Of Quanah Gibson-Mount Sent: Tuesday, May 12, 2015 6:29 PM To: Craig White; openldap-technical@openldap.org Subject: Re: debugging
--On Wednesday, May 13, 2015 12:32 AM +0000 Craig White CWhite@skytouchtechnology.com wrote:
5552876b conn=1000 op=3 SRCH base="cn=accesslog" scope=2 deref=0 filter="(uid=global.admin)"
My contention is that there isn't an error here but the application isn't happy with the new setup and as I said, they are not knowledgeable about how to debug from the java side.
The above log line clearly indicates the client issued a search using a base of cn=accesslog. This would be a bug in the java code. ---- Thanks - that was valuable. Despite all configuration to JNDI which says where to search, the application is choosing to search 'cn=accesslog' - that was we needed to know.
Craig
--On Wednesday, May 13, 2015 6:24 PM +0000 Craig White CWhite@skytouchtechnology.com wrote:
The above log line clearly indicates the client issued a search using a base of cn=accesslog. This would be a bug in the java code. ---- Thanks - that was valuable. Despite all configuration to JNDI which says where to search, the application is choosing to search 'cn=accesslog' - that was we needed to know.
Using JNDI for LDAP is a very, very bad idea.
I'd strongly advise you point your Java LDAP devs at the Unbound ID SDK for Java.
--Quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
--On Wednesday, May 13, 2015 6:24 PM +0000 Craig White CWhite@skytouchtechnology.com wrote:
The above log line clearly indicates the client issued a search using a base of cn=accesslog. This would be a bug in the java code. ---- Thanks - that was valuable. Despite all configuration to JNDI which says where to search, the application is choosing to search 'cn=accesslog' - that was we needed to know.
Using JNDI for LDAP is a very, very bad idea.
I'd strongly advise you point your Java LDAP devs at the Unbound ID SDK for Java.
Or the Apache LDAP SDK for Java. Or OpenLDAP's JLDAP. Anything but JNDI.
In regard to: RE: debugging, Quanah Gibson-Mount said (at 11:13am on May...:
--On Wednesday, May 13, 2015 6:24 PM +0000 Craig White CWhite@skytouchtechnology.com wrote:
The above log line clearly indicates the client issued a search using a base of cn=accesslog. This would be a bug in the java code. ---- Thanks - that was valuable. Despite all configuration to JNDI which says where to search, the application is choosing to search 'cn=accesslog' - that was we needed to know.
Using JNDI for LDAP is a very, very bad idea.
On this, I'll take your word and Howard's second as "gospel".
For my own edification and possibly the benefit of the archives, though, can you go into the reasons *why* it's a bad idea? I'm not a Java developer but I have some down the hall from me, so I would like to be able to back up "it's a very, very bad idea" with more than just "because Quanah and Howard say so". That's enough for me, but not for some.
Our Java developers are apparently using something called "ldaptive" from Virginia Tech, which defaults to using JNDI but can actually sit on top of the Unbound ID SDK or possibly others.
Tim
--On Friday, May 15, 2015 3:51 PM -0500 Tim Mooney Tim.Mooney@ndsu.edu wrote:
In regard to: RE: debugging, Quanah Gibson-Mount said (at 11:13am on May...:
--On Wednesday, May 13, 2015 6:24 PM +0000 Craig White CWhite@skytouchtechnology.com wrote:
The above log line clearly indicates the client issued a search using a base of cn=accesslog. This would be a bug in the java code. ---- Thanks - that was valuable. Despite all configuration to JNDI which says where to search, the application is choosing to search 'cn=accesslog' - that was we needed to know.
Using JNDI for LDAP is a very, very bad idea.
On this, I'll take your word and Howard's second as "gospel".
For my own edification and possibly the benefit of the archives, though, can you go into the reasons *why* it's a bad idea? I'm not a Java developer but I have some down the hall from me, so I would like to be able to back up "it's a very, very bad idea" with more than just "because Quanah and Howard say so". That's enough for me, but not for some.
Our Java developers are apparently using something called "ldaptive" from Virginia Tech, which defaults to using JNDI but can actually sit on top of the Unbound ID SDK or possibly others.
Years of experience of using JNDI and dealing with its multitude of bugs and the fact the LDAP portion of JNDI is generally unmaintained. The developers who worked on it left Sun/Oracle and went and created UnboundID, but did it from scratch and were able to fix the many deficiencies in JNDI's ldap bits.
see also: http://www.sfu.ca/~hillman/zimbra-hied-admins/msg00458.html
for a bug that's *years* old and remains unfixed.
--Quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
In regard to: RE: debugging, Quanah Gibson-Mount said (at 1:01pm on May 15,...:
--On Friday, May 15, 2015 3:51 PM -0500 Tim Mooney Tim.Mooney@ndsu.edu wrote:
In regard to: RE: debugging, Quanah Gibson-Mount said (at 11:13am on May...:
[cut]
Using JNDI for LDAP is a very, very bad idea.
For my own edification and possibly the benefit of the archives, though, can you go into the reasons *why* it's a bad idea?
[cut]
Years of experience of using JNDI and dealing with its multitude of bugs and the fact the LDAP portion of JNDI is generally unmaintained. The developers who worked on it left Sun/Oracle and went and created UnboundID, but did it from scratch and were able to fix the many deficiencies in JNDI's ldap bits.
see also: http://www.sfu.ca/~hillman/zimbra-hied-admins/msg00458.html
for a bug that's *years* old and remains unfixed.
Thanks for following up and providing that information.
Tim
openldap-technical@openldap.org
-
Craig White -
Howard Chu -
Quanah Gibson-Mount -
Tim Mooney