Why slapd is requesting backend to load different dn than the one asked?

Question

Could anyone please explain why slapd requesting its backend to load data corresponding to the distinguished name "cn=kerberoskdc,cn=config,dc=example,dc=com" when I'm actually asking for dn= 'cn=user,dc=example,dc=com', 'user'

code :

require 'net/ldap'
con = Net::LDAP.new
con.host = 'localhost'
con.port = 389
con.auth 'cn=user,dc=example,dc=com', 'user'

if con.bind
  puts con.get_operation_result
else
  puts con.get_operation_result
end

slapd.conf:

include         /private/etc/openldap/schema/core.schema
include         /private/etc/openldap/schema/cosine.schema
include         /private/etc/openldap/schema/nis.schema
include         /private/etc/openldap/schema/inetorgperson.schema

pidfile         /private/var/db/openldap/run/slapd.pid
argsfile        /private/var/db/openldap/run/slapd.args

 modulepath     /usr/libexec/openldap
 moduleload     back_bdb.la

access to *
        by self write
        by * read
        by anonymous auth

database        bdb
suffix          "dc=example,dc=com"
rootdn          "cn=admin,dc=example,dc=com"

rootpw          {SSHA}VPu01KnHRk2FZtTi52W6LNFqr4nJazyK

directory       /private/var/db/openldap/openldap-data

index   objectClass     eq

detail Server message :

 ... 
    5a41d4ae <<< dnPrettyNormal: <cn=user,dc=example,dc=com>, <cn=user,dc=example,dc=com>
    5a41d4ae conn=1000 op=0 BIND dn="cn=user,dc=example,dc=com" method=128
    5a41d4ae do_bind: version=3 dn="cn=user,dc=example,dc=com" method=128
    5a41d4ae ==> bdb_bind: dn: cn=user,dc=example,dc=com
    5a41d4ae bdb_dn2entry("cn=user,dc=example,dc=com")
    5a41d4ae => bdb_dn2id("dc=example,dc=com")
    5a41d4ae <= bdb_dn2id: got id=0x5
    5a41d4ae => bdb_dn2id("cn=user,dc=example,dc=com")
    5a41d4ae <= bdb_dn2id: got id=0x17
    5a41d4ae entry_decode: "cn=user,dc=example,dc=com"
    5a41d4ae <= entry_decode(cn=user,dc=example,dc=com)
    5a41d4ae => bdb_search
    5a41d4ae bdb_dn2entry("cn=kerberoskdc,cn=config,dc=example,dc=com")
    5a41d4ae => bdb_dn2id("cn=config,dc=example,dc=com")
    5a41d4ae <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30988)
    5a41d4ae entry_decode: "dc=example,dc=com"
    5a41d4ae <= entry_decode(dc=example,dc=com)
    5a41d4ae => access_allowed: disclose access to "dc=example,dc=com" "entry" requested
    5a41d4ae => acl_get: [1] attr entry
    5a41d4ae => acl_mask: access to entry "dc=example,dc=com", attr "entry" requested
    5a41d4ae => acl_mask: to all values by "cn=kerberoskdc,cn=config,dc=example,dc=com", (=0) 
    5a41d4ae <= check a_dn_pat: self
    5a41d4ae <= check a_dn_pat: *
    5a41d4ae <= acl_mask: [2] applying read(=rscxd) (stop)
    5a41d4ae <= acl_mask: [2] mask: read(=rscxd)
    5a41d4ae => slap_access_allowed: disclose access granted by read(=rscxd)
    5a41d4ae => access_allowed: disclose access granted by read(=rscxd)
    5a41d4ae send_ldap_result: conn=-1 op=0 p=0
    5a41d4ae send_ldap_result: err=10 matched="dc=example,dc=com" text=""
    5a41d4ae Entry *odusers_copy_entry(Operation *): Unable to locate cn=kerberoskdc,cn=config,dc=example,dc=com (32)
    5a41d4ae odusers_copy_krbrealm: No entry associated with KerberosKDC cn=kerberoskdc,cn=config,dc=example,dc=com
    5a41d4ae odusers_krb_auth: could not retrieve krb realm while authing user
    5a41d4ae send_ldap_result: conn=1000 op=0 p=3
    5a41d4ae send_ldap_result: err=50 matched="" text=""
    5a41d4ae send_ldap_response: msgid=1 tag=97 err=50
    ....

output on terminal:

fail
#<OpenStruct extended_response=nil, code=50, error_message="", matched_dn="", message="Insufficient Access Rights">

Because of something in your OpenLDAP configuration. Off topic. — user207421, Dec 26 '17 at 09:58
@EJP I edited the question and added my slapd.conf. Could you please tell me what I am missing in my configuration file. — Praneetha, Dec 26 '17 at 11:05
I didn't say anything was missing, and it's still off topic. — user207421, Jan 16 '18 at 23:59

score 0 · Answer 1 · answered Jan 16 '18 at 21:23

Here is a workaround that works for my OpenLDAP server that I use in a Ruby on Rails development environment within OS X El Capitan. I found the answer here. It is more of a workaround than a solution.

Replace 'database hdb' with 'database ldif' within slapd.conf.
Remove 'module load back_hdb.la'
slapd won't run until after you remove any additional database specific configurations, such as indexes.

Here is my slapd.conf:

include   /usr/local/etc/openldap/schema/core.schema
include   /usr/local/etc/openldap/schema/cosine.schema
include   /usr/local/etc/openldap/schema/inetorgperson.schema


# NO SECURITY - no access clause
# defaults to anonymous access for read
# only rootdn can write

# NO REFERRALS

# DON'T bother with ARGS file unless you feel strongly
# slapd scripts stop scripts need this to work
pidfile /var/run/slapd.pid

# enable a lot of logging - we might need it
# but generates huge logs
loglevel  -1 

# MODULELOAD definitions
# not required (comment out) before version 2.3
#moduleload back_hdb.la

# NO TLS-enabled connections

# backend definition not required

#######################################################################
# bdb database definitions
# 
# replace example and com below with a suitable domain
# 
# If you don't have a domain you can leave it since example.com
# is reserved for experimentation or change them to my and inc
#
#######################################################################

database ldif
suffix "dc=example, dc=com"

# root or superuser
rootdn "cn=matt, dc=example, dc=com"
rootpw {SSHA}d+/KMakRv0dLLXp4Qu0ezvfcdpHQA4pU
# The database directory MUST exist prior to running slapd AND 
# change path as necessary
directory /var/db/openldap/openldap-data

# Indices to maintain for this directory
# unique id so equality match only
#index  uid eq
# allows general searching on commonname, givenname and email
#index  cn,gn,mail eq,sub
# allows multiple variants on surname searching
#index sn eq,sub
# sub above includes subintial,subany,subfinal
# optimise department searches
#index ou eq
# if searches will include objectClass uncomment following
# index objectClass eq
# shows use of default index parameter
#index default eq,sub
# indices missing - uses default eq,sub
#index telephonenumber

## other database parameters
## read more in slapd.conf reference section
#cachesize 10000
#checkpoint 128 15

Solution to what? What is the *problem,* and what part of this total reconfiguration constitutes the solution? — user207421, Jan 17 '18 at 00:01
The problem is executing 'ldapsearch' bound to users who are NOT defined as RootDN against OpenLDAP on Mac OS X with a BekelyDB database. If you try running ldap commands against other users, the OpenLDAP logs show a weird injections of a Kerberos CN into the search that seems to cause the lookup to fail. The log looks like this: 'bdb_dn2entry("cn=kerberoskdc,cn=config,...'. The fix is removing the 'database bdb' or 'database hdb' portions of the config and specifying ldif instead. It is not a fix as much as a work around sufficient for a dev environ. — rat, Jan 17 '18 at 18:42

Why slapd is requesting backend to load different dn than the one asked?

1 Answers1