What is the default of `-b`?
by Peng Yu
Hi,
The man page says the following.
`-b` *searchbase*
: Use *searchbase* as the starting point for the search instead of
the default.
I'm wondering what is the default. If I don't specify -b, I will get
an error. Does anyone know how show all the contents from the
database? Thanks.
$ sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=config dn
dn: cn=config
dn: cn=module{0},cn=config
dn: cn=schema,cn=config
dn: cn={0}core,cn=schema,cn=config
dn: cn={1}cosine,cn=schema,cn=config
dn: cn={2}nis,cn=schema,cn=config
dn: cn={3}inetorgperson,cn=schema,cn=config
dn: olcBackend={0}hdb,cn=config
dn: olcDatabase={-1}frontend,cn=config
dn: olcDatabase={0}config,cn=config
dn: olcDatabase={1}hdb,cn=config
$ sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// dn
No such object (32)
--
Regards,
Peng
8 years, 12 months
Re: Kerberos issue running OpenLDAP on Mac OS X Mavericks
by Dan White
Putting the email list back into the CC.
On 03/20/14 10:16 -0500, Denis Ahearn wrote:
>Thanks for responding Dan. We have spent the past several days taking the
>information you provided and trying to get smarter about how OpenLDAP and
>Kerberos work on Mac OS X Mavericks. Unfortunately we haven't made much
>progress. I think it may be because the way we are trying to use OpenLDAP
>is not the standard way that Apple intends it to be used from a server or
>client standpoint, so there doesn't seem to be any documentation available
>that speaks directly to our use case. Responses to your questions are
>listed below.
>
>>> If you are authenticating against Active Directory, how does slapd fit
>>> into the picture?
>
>Our Rails app authenticates using Active Directory only in staging and
>production. We're using OpenLDAP (slapd) in our local development
>environments to simulate this (i.e. to provide a local LDAP server that
>serves the purpose that Active Directory does in production). To test
>locally, we define an organization, groups and users in ldif files that get
>loaded into OpenLDAP using ldapadd.
>
>>> Do you have an authz-regex rule mapping the authentication identity to
>>> this? Can you reproduce this problem with ldapsearch/ldapwhoami, using
>>> the same parameters as your ruby code?
>
>Are you referring to setting an authz-regex rule in slapd.conf? If so, we
>do not have any authz-regex rules in our slapd.conf. I attached the
>slapd.conf and ldap.conf files that are being used with OpenLDAP if that
>helps.
>
>>> It appears your client has a kerberos ticket, and is attempting GSSAPI
>>> authentication. You can verify that with klist or your OS's kerberos
>>> utilities.
>
>I ran the klist command on the Mac that is having this issue. Output is
>below:
>
>$ klist
>
>Credentials cache: API:77A8E90B-01BF-4F18-A94E-035C3AB25A59
>
> Principal: dahearn(a)BWD.INT
>
> Issued Expires Principal
>
>
>>> The client side Ruby code may allow you to configure a sasl mechanism.
>>> If not, see ldap.conf(5) and set an appropriate LDAPSASL_MECH
>>> environment variable or set SASL_MECH within your home .ldaprc file
>>> (to, for instance, DIGEST-MD5).
>
>We tried the suggestions you listed above, none of which seemed to have any
>effect on OpenLDAP's behavior (output in slapd.log is exactly the same).
I'm still not clear if ruby is attempting SASL GSSAPI authentication or
not. Your syslog (auth facility) may tell you that. Since you have a
ticket, it's certainly possible.
You can disable GSSAPI in a couple of additional ways:
1) Remove the SASL GSSAPI shared library, assuming your cyrus sasl install
was compiled using shared libraries. pluginviewer (or saslpluginview)
should list the mechanisms which are installed.
2) Configure a slapd.conf SASL configuration, on the server, which
explicitly lists which mechanisms you wish to offer. The FAQ at:
http://www.cyrussasl.org/mediawiki/index.php/FAQ
details how to *enable* GSSAPI for slapd. Find out where cyrus sasl is
looking for config files (e.g. /usr/lib/sasl2 or /etc/sasl2) and create a
slapd.conf file with this line:
mech_list: PLAIN LOGIN DIGEST-MD5
Are you performing pass-through authentication? In that case, try running
saslauthd in debug mode for testing.
>We are only using OpenLDAP in our development environment as a way to store
>groups and users for testing purposes, and to provide an LDAP server that
>our application can talk to in the same way it talks to Active Directory in
>our production environment. We rely upon logic in the application (the
>Ruby Devise and CanCan gems) to provide the necessary authentication and
>authorization services. What I think we need to do is make OpenLDAP not
>use Kerberos or other authentication mechanisms, but I haven't been able to
>figure out if this is possible and if so, how to do that. Does this sound
>like the way to go? If so, can you provide any assistance in setting this
>up? Is there anything else I can send you to help you understand our setup?
Replace the ruby authentication step with a ldapsearch/ldapwhoami call
(with a -d -1 option for debugging on the client side). Or see if you can
specify a debug option within Ruby (assuming it is using libldap). If you
can figure out how your ruby code is connecting to the server in this way,
your problem will likely stand out pretty quickly. A wireshark trace of the
ruby ldap connection may help with that as well.
--
Dan White
8 years, 12 months
Changing cert paths may cause openldap to stop
by Nick Milas
Hi,
On 2.4.39 (CentOS 5.10 x86_64), I found that if I attempt to change
certificate values but there is an error in a path, openldap stops.
I would expect this should be avoided. Openldap should reject the
modification and not stop.
Running the modification below, it hungs; we press Ctrl-C (and we print
a full backtrace), then we find slapd is stopped.
Please check the output below.
Best regards,
Nick
Example:
-------------------------------------------------------------------------------
Modification file: /root/work/certmod2:
-------------------------------------------------------------------------------
dn: cn=config
changetype: modify
replace: olcTLSCACertificateFile
olcTLSCACertificateFile:
/usr/local/openldap/etc/openldap/certs/chain-2241.pem
-
replace: olcTLSCertificateFile
olcTLSCertificateFile: /usr/local/openldap/etc/openldap/certs/cert-2241.pem
-
replace: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile:
/usr/local/openldap/etc/openldap/certs/priv-2241.pem
-------------------------------------------------------------------------------
In this case priv-2241.pem does not exist (the correct value would be:
key-2241.pem).
-------------------------------------------------------------------------------
Modification attempt:
-------------------------------------------------------------------------------
# /usr/local/openldap/bin/ldapmodify -h localhost -x -v -W -D
"cn=admin,cn=config" -f /root/work/certmod2
ldap_initialize( ldap://localhost )
Enter LDAP Password:
replace olcTLSCACertificateFile:
/usr/local/openldap/etc/openldap/certs/chain-2241.pem
replace olcTLSCertificateFile:
/usr/local/openldap/etc/openldap/certs/cert-2241.pem
replace olcTLSCertificateKeyFile:
/usr/local/openldap/etc/openldap/certs/priv-2241.pem
modifying entry "cn=config"
<it hungs and we press Ctrl-C>
ldap_result: Can't contact LDAP server (-1)
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
(gdb) backtrace full
#0 0x00000033bf830265 in raise () from /lib64/libc.so.6
No symbol table info available.
#1 0x00000033bf831d10 in abort () from /lib64/libc.so.6
No symbol table info available.
#2 0x00000033bf829706 in __assert_fail () from /lib64/libc.so.6
No symbol table info available.
#3 0x000000000044f66d in slap_send_ldap_result (op=0xcd75580,
rs=0x2ba278651c20) at result.c:813
tmp = <value optimized out>
otext = 0x2ba278650664 ""
oref = 0x0
__PRETTY_FUNCTION__ = "slap_send_ldap_result"
#4 0x000000000042ca7f in config_back_modify (op=0xcd75580,
rs=0x2ba278651c20) at bconfig.c:5926
cfb = 0x8787a0
ce = 0xffffffff
last = 0x600000000
ml = 0x6
ca = {argc = 2, argv = 0xce77200, argv_size = 513, line =
0xce75c00 "/usr/local/openldap/etc/openldap/certs/priv-2241.pem",
tline = 0xc81a880 "\220d\224\f", fname = 0x5c7c99 "slapd",
lineno = 0, log = "olcTLSCertificateKeyFile: value #0", '\000' <repeats
4089 times>,
reply = {err = 0, msg = '\000' <repeats 255 times>}, depth =
0, valx = -1, values = {v_int = 209823808, v_uint = 209823808, v_long =
209823808,
v_ulong = 209823808, v_ber_t = 209823808, v_string =
0xc81a840 "/usr/local/openldap/etc/openldap/certs/priv-2241.pem", v_bv =
{bv_len = 209823808,
bv_val = 0x0}, v_dn = {vdn_dn = {bv_len = 209823808,
bv_val = 0x0}, vdn_ndn = {bv_len = 0, bv_val = 0x0}}, v_ad = 0xc81a840},
rvalue_vals = 0x0,
rvalue_nvals = 0x0, op = 0, type = 8, ca_op = 0xcd75580, be =
0x87a520, bi = 0x0, ca_entry = 0xc81ab48, ca_private = 0xc81a280,
cleanup = 0x427850 <config_tls_cleanup>, table = Cft_Global}
rdn = {bv_len = 2, bv_val = 0xc81a7e0 "cn=config"}
rad = 0xc7c4e90
do_pause = 1
#5 0x0000000000455ff7 in fe_op_modify (op=0xcd75580, rs=0x2ba278651c20)
at modify.c:303
repl_user = <value optimized out>
bd = 0x87a520
textbuf =
"\005\000\000\000\000\000\000\000xZ\327\f\000\000\000\000h[\327\f\000\000\000\000\003\000\000\000\000\000\000\000\b\000\000\000\000\000\000\000\270Z\327\f\000\000\000\000P\271}\f\000\000\000\000\000\\\347\f\000\000\000\000\320[\347\f\000\000\000\000:\213E",
'\000' <repeats 21 times>,
"4\000\000\000\000\000\000\000\000\\\347\f\000\000\000\000\270U\327\f",
'\000' <repeats 12 times>, "@\\\347\f", '\000' <repeats 12 times>"\340,
\272}\f\000\000\000\000\020", '\000' <repeats 15 times>"\304,
XE\000\000\000\000\000\340:\306\f\000\000\000\000\000\001\000\000\000\000\000\000\320\032ex\242+\000\000@\034ex\242+\000\000\200U\327\f\000\000\000\000\001\000\000\000\000\000\000\000\270U\327\f\000\000\000\000\250U\327\f\000\000\000\000\340:\306\f\000\000\000\000\251\063"...
#6 0x0000000000456762 in do_modify (op=0xcd75580, rs=0x2ba278651c20) at
modify.c:177
dn = {bv_len = 9, bv_val = 0xcd75459 "cn=config"}
textbuf =
"\000\b\000\000\000\000\000\000\000\001\000\000\000\000\000\000
\000\000\000\000\000\000\000\004", '\000' <repeats 15 times>"\377,
\017\000\000\000\000\000\000\260\005\002", '\000' <repeats 14
times>"\360, \377\377\377\377\377\377\000\000\000\000~", '\000' <repeats
27 times>"\271, \312\065\062\"", '\000' <repeats 11 times>"\340,
I\265\277\063\000\000\000\000\000\020\000\000\000\000\000\000\000\020\000\000\000\000\000\001\000\000\000\000\000\000\000\340:\306\f\000\000\000\000\000\000\020\000\000\000\000\000\236@\207\277\063",
'\000' <repeats 13 times>,
"\020\000\000\000\000\000p\035ex\242+\000\000Mc[\000\000\000\000\000\000\000\020\000\000\000\000\000\373\210E\000\000\000\000\000\001\000\000\000\000\000\000\000\330\002I\000\000\000\000\000\200U\327\f\000\000\000\000]\226F\---Type
<return> to continue, or q <return> to quit---
000\000\000\000"
tmp = 0x0
#7 0x000000000043f0d5 in connection_operation (ctx=0x2ba278651d70,
arg_v=<value optimized out>) at connection.c:1155
rc = <value optimized out>
cancel = <value optimized out>
op = 0xcd75580
rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err =
-1, sr_matched = 0x0, sr_text = 0x2ba278650664 "", sr_ref = 0x0,
sr_ctrls = 0x0,
sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0,
r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref =
0x0}, sru_sasl = {
r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0,
r_rspdata = 0x0}}, sr_flags = 0}
tag = 102
opidx = SLAP_OP_MODIFY
conn = 0xc9c2d20
memctx = 0xcc63ae0
memctx_null = 0x0
__PRETTY_FUNCTION__ = "connection_operation"
#8 0x000000000043f6af in connection_read_thread (ctx=0x2ba278651d70,
argv=<value optimized out>) at connection.c:1291
s = 12
#9 0x000000000058d92c in ldap_int_thread_pool_wrapper (xpool=0xc7c8430)
at tpool.c:688
task = 0xcd752f0
work_list = <value optimized out>
ctx = {ltu_id = 47976804591936, ltu_key = {{ltk_key = 0x43e040,
ltk_data = 0xcd75950, ltk_free = 0x43e110 <conn_counter_destroy>}, {
ltk_key = 0x48ff50, ltk_data = 0xcc63ae0, ltk_free =
0x48ff70 <slap_sl_mem_destroy>}, {ltk_key = 0x0, ltk_data = 0x0,
ltk_free = 0} <repeats 30 times>}}
kctx = <value optimized out>
keyslot = 435
hash = <value optimized out>
__PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper"
#10 0x00002ba23235583d in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#11 0x00000033bf8d526d in clone () from /lib64/libc.so.6
No symbol table info available.
-------------------------------------------------------------------------------
8 years, 12 months
Failure in 2.4.32: similar experiences?
by Nick Urbanik
Dear Folks,
We have some moderately busy OpenLDAP servers, OpenLDAP 2.4.32 running
on CentOS 5.8 on HP BL495cG6 blades, with 24GB RAM, in a cluster of
four, using LVS to balance the load. They peak at just over 3000
LDAP connections per second.
They stopped serving requests, or at least, began serving them so
slowly that they caused an outage. After my colleague restarted
slapd, they resumed serving the requests.
slapd didn't die, or dump core. Sadly, since the most minimal logging
produces 25GB per day, so we have that turned off, and after the
event, I now am graphing some of the statistics from the monitor
database, though that provides less detail than I would wish.
My questions:
=============
Has anyone had a similar experience of failure with this version of
OpenLDAP specifically, or with any other version?
Has anyone any suggestions on what might have happened?
I am upgrading LDAP to 2.4.39, but would like to know if there is a
known problem that I will resolve by this upgrade.
Here is a "sanitised" view of our configuration:
# slapd.conf generated by /usr/bin/conform
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/local.schema
include /etc/openldap/schema/prefs.schema
loglevel stats
allow bind_v2
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
tool-threads 8
password-hash {CRYPT}
password-crypt-salt-format "$1$%.8s"
TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
TLSCertificateFile /etc/openldap/ldap.syd.crt
TLSCertificateKeyFile /etc/openldap/ldap.syd.key
############################################################
# GLOBAL database definition
############################################################
access to dn.base=""
by peername.ip=133.3.193.2 read
by peername.ip=19.21.201.10 read
by * read
access to dn.base="cn=Subschema"
by * read
############################################################
# ou=tree1,ou=name database definition
############################################################
database bdb
suffix "ou=tree1,ou=name"
rootdn cn=manager,ou=tree1,ou=name
rootpw root-password
directory /var/lib/ldap/ou=tree1,ou=name
index domain eq,pres
index entryCSN eq
index entryUUID eq
index mail eq,pres
index objectClass eq
index uid eq,pres
shm_key 331
cachesize 100000
idlcachesize 100000
checkpoint 32768 30
idletimeout 3600
writetimeout 90000
access to dn.base="ou=tree1,ou=name"
by peername.ip=96.76.69.162 read
by * none break
access to dn.subtree="ou=tree1,ou=name"
by dn.base="cn=Reader,ou=tree1,ou=name" read
by peername.ip=205.191.75.42 read
by peername.ip=198.132.212.127 read
by peername.ip=101.169.45.146 read
by peername.ip=212.38.134.82 read
by peername.ip=127.0.0.1 read
by peername.ip=49.15.162.36 read
by peername.ip=142.226.69.215 read
by peername.ip=236.107.103.158 read
by peername.ip=57.167.92.229 read
by peername.ip=138.57.161.36 read
by peername.ip=99.33.110.154 read
by peername.ip=196.119.159.149 read
by peername.ip=44.116.9.128 read
by peername.ip=122.234.222.27 read
by self peername.ip=154.238.170.210 read
by self peername.ip=31.62.15.241 read
by self peername.ip=163.226.124.118 read
by self peername.ip=92.190.127.61 read
by self peername.ip=125.225.28.232 read
by self peername.ip=122.148.131.239 read
by self peername.ip=118.160.216.124 read
by self peername.ip=74.226.71.41 read
by self peername.ip=179.149.175.90 read
by self peername.ip=235.160.10.186 read
by self peername.ip=125.80.123.119 read
by self peername.ip=185.5.66.203 read
by self peername.ip=158.224.9.61 read
by self peername.ip=46.146.95.97 read
by self peername.ip=6.182.235.60 read
by self peername.ip=7.137.32.196 read
by self peername.ip=204.184.227.24 read
by self peername.ip=56.10.14.169 read
by self peername.ip=165.49.58.78 read
by self peername.ip=165.211.155.235 read
by self peername.ip=119.216.126.40 read
by self peername.ip=94.212.46.227 read
by self peername.ip=210.225.203.227 read
by self peername.ip=171.235.159.67 read
by self peername.ip=28.94.19.93 read
by self peername.ip=206.12.128.149 read
by self peername.ip=18.223.36.165 read
by self peername.ip=35.164.112.79 read
by self peername.ip=145.100.109.232 read
by self peername.ip=10.230.19.137 read
by self peername.ip=86.124.99.133 read
by self peername.ip=56.223.60.177 read
by self peername.ip=140.114.55.210 read
by self peername.ip=216.13.135.39 read
by self peername.ip=5.93.220.80 read
by self peername.ip=87.215.35.140 read
by self peername.ip=162.101.170.221 read
by self peername.ip=100.59.12.102 read
by self peername.ip=58.223.90.131 read
by self peername.ip=124.165.37.123 read
by self peername.ip=11.178.120.42 read
by self peername.ip=99.205.107.56 read
by self peername.ip=31.26.172.88 read
by self peername.ip=211.133.184.38 read
by self peername.ip=84.215.59.209 read
by self peername.ip=13.70.104.6 read
by self peername.ip=111.100.110.74 read
by self peername.ip=190.199.36.1 read
by self peername.ip=236.212.185.240 read
by self peername.ip=180.4.69.152 read
by self peername.ip=38.63.162.124 read
by self peername.ip=68.34.84.216 read
by self peername.ip=43.41.142.100 read
by self peername.ip=118.225.164.10 read
by self peername.ip=40.26.24.236 read
by self peername.ip=197.161.148.167 read
by self peername.ip=148.163.210.9 read
by self peername.ip=161.141.31.120 read
by self peername.ip=85.59.211.7 read
by self peername.ip=237.59.225.239 read
by self peername.ip=29.114.216.84 read
by anonymous auth
by * none break
syncrepl rid=001
provider=ldap://master:389
type=refreshAndPersist
bindmethod=simple
binddn=cn=syncrepl,ou=tree1,ou=name
credentials=syncrepl-password
searchbase="ou=tree1,ou=name"
retry="5 10 60 +"
############################################################
# ou=tree2,ou=name database definition
############################################################
database bdb
suffix "ou=tree2,ou=name"
rootdn cn=manager,ou=tree2,ou=name
rootpw root-password
directory /var/lib/ldap/ou=tree2,ou=name
index avcid eq
index entryCSN eq
index entryUUID eq
index gsid eq
index objectClass eq
shm_key 320
cachesize 100000
idlcachesize 100000
checkpoint 32768 30
idletimeout 3600
writetimeout 90000
access to dn.base="ou=tree2,ou=name"
by peername.ip=1.224.5.235 read
by * none break
access to dn.subtree="ou=tree2,ou=name"
by dn.base="cn=Reader,ou=tree2,ou=name" read
by peername.ip=124.182.243.237 read
by peername.ip=73.200.132.164 read
by peername.ip=5.106.199.123 read
by peername.ip=243.60.43.234 read
by peername.ip=127.0.0.1 read
by anonymous auth
by * none break
syncrepl rid=010
provider=ldap://master:389
type=refreshAndPersist
bindmethod=simple
binddn=cn=syncrepl,ou=tree2,ou=name
credentials=syncrepl-password
searchbase="ou=tree2,ou=name"
retry="5 10 60 +"
############################################################
# ou=tree3,ou=name database definition
############################################################
database bdb
suffix "ou=tree3,ou=name"
rootdn cn=manager,ou=tree3,ou=name
rootpw root-password
directory /var/lib/ldap/ou=tree3,ou=name
index entryCSN eq
index entryUUID eq
index fnn eq
index lineid eq
index objectClass eq
index serviceid eq
index ullsid eq
shm_key 74
cachesize 100000
idlcachesize 100000
checkpoint 32768 30
idletimeout 3600
writetimeout 90000
access to dn.base="ou=tree3,ou=name"
by peername.ip=100.131.166.211 read
by * none break
access to dn.subtree="ou=tree3,ou=name"
by dn.base="cn=Reader,ou=tree3,ou=name" read
by peername.ip=39.236.93.167 read
by peername.ip=48.145.97.90 read
by peername.ip=143.186.10.231 read
by peername.ip=35.68.19.116 read
by peername.ip=127.0.0.1 read
by anonymous auth
by * none break
syncrepl rid=008
provider=ldap://master:389
type=refreshAndPersist
bindmethod=simple
binddn=cn=syncrepl,ou=tree3,ou=name
credentials=syncrepl-password
searchbase="ou=tree3,ou=name"
retry="5 10 60 +"
############################################################
# ou=tree4,ou=name database definition
############################################################
database bdb
suffix "ou=tree4,ou=name"
rootdn cn=manager,ou=tree4,ou=name
rootpw root-password
directory /var/lib/ldap/ou=tree4,ou=name
index cn eq
index entryCSN eq
index entryUUID eq
index objectClass eq
shm_key 195
cachesize 100000
idlcachesize 100000
checkpoint 32768 30
idletimeout 3600
writetimeout 90000
access to dn.base="ou=tree4,ou=name"
by peername.ip=26.233.142.132 read
by * none break
access to dn.subtree="ou=tree4,ou=name"
by dn.base="cn=Reader,ou=tree4,ou=name" read
by peername.ip=127.0.0.1 read
by anonymous auth
by * none break
access to dn.subtree=""
by peername.ip=101.156.205.102 read
by peername.ip=136.25.130.235 read
by peername.ip=136.206.49.17 read
by peername.ip=37.21.18.99 read
by * none break
syncrepl rid=002
provider=ldap://master:389
type=refreshAndPersist
bindmethod=simple
binddn=cn=syncrepl,ou=tree4,ou=name
credentials=syncrepl-password
searchbase="ou=tree4,ou=name"
retry="5 10 60 +"
############################################################
# ou=tree5,ou=name database definition
############################################################
database bdb
suffix "ou=tree5,ou=name"
rootdn cn=manager,ou=tree5,ou=name
rootpw root-password
directory /var/lib/ldap/ou=tree5,ou=name
index entryCSN eq
index entryUUID eq
index gsid eq
index objectClass eq
index uid eq
shm_key 626
cachesize 100000
idlcachesize 100000
checkpoint 32768 30
idletimeout 3600
writetimeout 90000
access to dn.base="ou=tree5,ou=name"
by peername.ip=225.143.210.78 read
by * none break
access to dn.subtree="ou=tree5,ou=name"
by dn.base="cn=Reader,ou=tree5,ou=name" read
by peername.ip=106.154.145.84 read
by peername.ip=197.28.75.183 read
by peername.ip=179.151.185.161 read
by peername.ip=4.60.182.12 read
by peername.ip=127.0.0.1 read
by anonymous auth
by * none break
syncrepl rid=011
provider=ldap://master:389
type=refreshAndPersist
bindmethod=simple
binddn=cn=syncrepl,ou=tree5,ou=name
credentials=syncrepl-password
searchbase="ou=tree5,ou=name"
retry="5 10 60 +"
############################################################
# ou=tree6,ou=name database definition
############################################################
database bdb
suffix "ou=tree6,ou=name"
rootdn cn=manager,ou=tree6,ou=name
rootpw root-password
directory /var/lib/ldap/ou=tree6,ou=name
index entryCSN eq
index entryUUID eq
index objectClass eq
index uid eq
index username eq
shm_key 290
cachesize 100000
idlcachesize 100000
checkpoint 32768 30
idletimeout 3600
writetimeout 90000
access to dn.base="ou=tree6,ou=name"
by peername.ip=195.44.90.201 read
by * none break
access to dn.subtree="ou=tree6,ou=name"
by dn.base="cn=Reader,ou=tree6,ou=name" read
by peername.ip=131.55.25.176 read
by peername.ip=52.151.227.147 read
by peername.ip=144.91.87.53 read
by peername.ip=51.236.131.115 read
by peername.ip=127.0.0.1 read
by anonymous auth
by * none break
syncrepl rid=009
provider=ldap://master:389
type=refreshAndPersist
bindmethod=simple
binddn=cn=syncrepl,ou=tree6,ou=name
credentials=syncrepl-password
searchbase="ou=tree6,ou=name"
retry="5 10 60 +"
############################################################
# ou=tree7,ou=name database definition
############################################################
database bdb
suffix "ou=tree7,ou=name"
rootdn cn=manager,ou=tree7,ou=name
rootpw root-password
directory /var/lib/ldap/ou=tree7,ou=name
index entryCSN eq
index entryUUID eq
index objectClass eq
index uid eq
index username eq
shm_key 105
cachesize 100000
idlcachesize 100000
checkpoint 32768 30
idletimeout 3600
writetimeout 90000
access to dn.base="ou=tree7,ou=name"
by peername.ip=82.36.151.29 read
by peername.ip=69.183.15.150 read
by * none break
access to dn.subtree="ou=tree7,ou=name"
by peername.ip=81.44.61.5 read
by peername.ip=75.34.88.223 read
by peername.ip=40.106.122.233 read
by dn.base="cn=Reader,ou=tree7,ou=name" read
by peername.ip=127.0.0.1 read
by anonymous auth
by * none break
syncrepl rid=003
provider=ldap://master:389
type=refreshAndPersist
bindmethod=simple
binddn=cn=syncrepl,ou=tree7,ou=name
credentials=syncrepl-password
searchbase="ou=tree7,ou=name"
retry="5 10 60 +"
############################################################
# ou=tree8,ou=name database definition
############################################################
database bdb
suffix "ou=tree8,ou=name"
rootdn cn=manager,ou=tree8,ou=name
rootpw root-password
directory /var/lib/ldap/ou=tree8,ou=name
index entryCSN eq
index entryUUID eq
index objectClass eq
index uid eq
index username eq
shm_key 280
cachesize 100000
idlcachesize 100000
checkpoint 32768 30
idletimeout 3600
writetimeout 90000
access to dn.base="ou=tree8,ou=name"
by peername.ip=221.195.40.138 read
by * none break
access to dn.subtree="ou=tree8,ou=name"
by dn.base="cn=Reader,ou=tree8,ou=name" read
by peername.ip=211.28.110.6 read
by peername.ip=4.134.128.66 read
by peername.ip=194.183.122.54 read
by peername.ip=89.223.206.194 read
by peername.ip=28.88.175.182 read
by peername.ip=209.169.46.101 read
by peername.ip=230.21.178.118 read
by peername.ip=41.55.202.55 read
by peername.ip=127.0.0.1 read
by anonymous auth
by * none break
syncrepl rid=004
provider=ldap://master:389
type=refreshAndPersist
bindmethod=simple
binddn=cn=syncrepl,ou=tree8,ou=name
credentials=syncrepl-password
searchbase="ou=tree8,ou=name"
retry="5 10 60 +"
############################################################
# ou=tree9,ou=name database definition
############################################################
database bdb
suffix "ou=tree9,ou=name"
rootdn cn=manager,ou=tree9,ou=name
rootpw root-password
directory /var/lib/ldap/ou=tree9,ou=name
index entryCSN eq
index entryUUID eq
index objectClass eq
index uid eq
index username eq
shm_key 122
cachesize 100000
idlcachesize 100000
checkpoint 32768 30
idletimeout 3600
writetimeout 90000
access to dn.base="ou=tree9,ou=name"
by peername.ip=153.54.1.23 read
by * none break
access to dn.subtree="ou=tree9,ou=name"
by dn.base="cn=Reader,ou=tree9,ou=name" read
by peername.ip=164.215.79.230 read
by peername.ip=52.205.194.57 read
by peername.ip=69.215.8.144 read
by peername.ip=240.46.54.48 read
by peername.ip=127.0.0.1 read
by anonymous auth
by * none break
syncrepl rid=006
provider=ldap://master:389
type=refreshAndPersist
bindmethod=simple
binddn=cn=syncrepl,ou=tree9,ou=name
credentials=syncrepl-password
searchbase="ou=tree9,ou=name"
retry="5 10 60 +"
############################################################
# ou=tree10,ou=name database definition
############################################################
database bdb
suffix "ou=tree10,ou=name"
rootdn cn=manager,ou=tree10,ou=name
rootpw root-password
directory /var/lib/ldap/ou=tree10,ou=name
index entryCSN eq
index entryUUID eq
index mtaMacAddress eq
index mtaSubcriberKey eq
index objectClass eq
shm_key 548
cachesize 100000
idlcachesize 100000
checkpoint 32768 30
idletimeout 3600
writetimeout 90000
access to dn.base="ou=tree10,ou=name"
by peername.ip=111.64.19.131 read
by * none break
access to dn.subtree="ou=tree10,ou=name"
by dn.base="cn=Reader,ou=tree10,ou=name" read
by peername.ip=49.225.102.91 read
by peername.ip=169.2.225.154 read
by peername.ip=177.202.224.166 read
by peername.ip=56.152.182.238 read
by peername.ip=157.83.196.154 read
by peername.ip=66.220.12.152 read
by peername.ip=132.204.57.43 read
by peername.ip=222.142.242.198 read
by peername.ip=153.130.78.144 read
by peername.ip=166.31.243.77 read
by peername.ip=226.40.169.1 read
by peername.ip=224.110.119.208 read
by peername.ip=15.227.192.210 read
by peername.ip=45.56.216.152 read
by peername.ip=127.0.0.1 read
by anonymous auth
by * none break
syncrepl rid=000
provider=ldap://master:389
type=refreshAndPersist
bindmethod=simple
binddn=cn=syncrepl,ou=tree10,ou=name
credentials=syncrepl-password
searchbase="ou=tree10,ou=name"
retry="5 10 60 +"
############################################################
# ou=tree11,ou=name database definition
############################################################
database bdb
suffix "ou=tree11,ou=name"
rootdn cn=manager,ou=tree11,ou=name
rootpw root-password
directory /var/lib/ldap/ou=tree11,ou=name
index entryCSN eq
index entryUUID eq
index objectClass eq
index uid eq
index username eq
shm_key 215
cachesize 100000
idlcachesize 100000
checkpoint 32768 30
idletimeout 3600
writetimeout 90000
access to dn.base="ou=tree11,ou=name"
by peername.ip=51.114.241.35 read
by * none break
access to dn.subtree="ou=tree11,ou=name"
by dn.base="cn=Reader,ou=tree11,ou=name" read
by peername.ip=17.32.79.33 read
by peername.ip=140.205.127.168 read
by peername.ip=190.147.122.157 read
by peername.ip=170.66.104.2 read
by peername.ip=45.154.226.85 read
by peername.ip=116.172.183.88 read
by peername.ip=96.51.58.70 read
by peername.ip=85.240.27.171 read
by peername.ip=127.0.0.1 read
by anonymous auth
by * none break
syncrepl rid=005
provider=ldap://master:389
type=refreshAndPersist
bindmethod=simple
binddn=cn=syncrepl,ou=tree11,ou=name
credentials=syncrepl-password
searchbase="ou=tree11,ou=name"
retry="5 10 60 +"
############################################################
# ou=tree12,ou=name database definition
############################################################
database monitor
rootdn cn=manager,ou=tree12,ou=name
rootpw root-password
access to dn.subtree="ou=tree12,ou=name"
by peername.ip=127.0.0.1 read
by * none
--
Nick Urbanik http://nicku.org 808-71011 nick.urbanik(a)optusnet.com.au
GPG: 7FFA CDC7 5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24 ID: BB9D2C24
I disclaim, therefore I am.
8 years, 12 months
MDB_MAP_FULL: Environment mapsize limit reached
by Aleksander Dzierżanowski
Hello OpenLDAP guru & fans.
Recently I was trying to migrate from 'bdb' to 'mdb' backend by adding
temporary additional instance of OpenLDAP. Unfortunately I'm unable to
import database both using 'slapadd' or regular replication mechanism.
What I got is exact same error:
slapadd -b o=mysuffix < /tmp/mysuffix.ldif
5332ec95 => mdb_idl_insert_keys: c_put id failed: MDB_MAP_FULL:
Environment mapsize limit reached (-30792)
5332ec95 => mdb_tool_entry_put: index_entry_add failed: err=80
5332ec95 => mdb_tool_entry_put: txn_aborted! Internal error (80)
slapadd: could not add entry
dn="uid=myuser,ou=People,ou=developers,o=suffix" (line=2080):
txn_aborted! Internal error (80)
_# 9.26% eta none elapsed none spd
2.3 M/s
Closing DB...
My bdb 'maxsize' argument is set to 1GB. Database is really small, it
contain just few hundred of small entries. My OpenLDAP version is 2.4.38
from OpenLTB project (I'm unable to use 2.4.39 because I need to use
CentOS 6.4 version, latest one is for 6.5).
Changing only backend to 'bdb' in configuration make import succesfull.
Any advices?
regards,
--
Aleksander
8 years, 12 months
Not adding attributes
by espeake＠oreillyauto.com
I have just started getting this error in the past 10 days. There has not
been any configuration changes that we can find. In googleing this error I
am not finding anything that matches it. If I create an ldif file to add
these for the user, that works fine.
Mar 25 16:42:21 tn-ldap-1 slapd[14976]: conn=33594 op=17:
memberof_value_modify DN="uid=dsmith174,ou=users,dc=oreillyauto,dc=com" add
locationEntry="ou=Store4351,ou=Locations,dc=oreillyauto,dc=com" failed
err=32
Mar 25 16:42:22 tn-ldap-1 slapd[14976]: conn=33594 op=19:
memberof_value_modify DN="uid=dsmith174,ou=users,dc=oreillyauto,dc=com" add
oreillyGroup="cn=Store Non-Management,ou=Groups,dc=oreillyauto,dc=com"
failed err=32
Mar 25 16:42:22 tn-ldap-1 slapd[14976]: conn=33594 op=21:
memberof_value_modify DN="uid=dsmith174,ou=users,dc=oreillyauto,dc=com" add
oreillyGroup="cn=Store,ou=Groups,dc=oreillyauto,dc=com" failed err=32
What I do wonder about though in my olcDatabase={1}hdb folder I have two
memberOf overlays.
This is the first one.
# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 a078db21
dn: olcOverlay={0}memberof
objectClass: olcOverlayConfig
objectClass: olcMemberOf
olcOverlay: {0}memberof
olcMemberOfDangling: ignore
olcMemberOfRefInt: TRUE
olcMemberOfGroupOC: groupOfUniqueNames
olcMemberOfMemberAD: uniqueMember
olcMemberOfMemberOfAD: oreillyGroup
structuralObjectClass: olcMemberOf
creatorsName: cn=config
entryUUID: 91cea156-9e13-1032-84c3-0151b658a842
createTimestamp: 20130820183919Z
entryCSN: 20130820183919.833799Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20130820183919Z
This is the second one.
# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 fe8a4925
dn: olcOverlay={1}memberof
objectClass: olcOverlayConfig
objectClass: olcMemberOf
olcOverlay: {1}memberof
olcMemberOfDangling: ignore
olcMemberOfRefInt: TRUE
olcMemberOfGroupOC: oreillyOrgUnit
olcMemberOfMemberAD: uniqueMember
olcMemberOfMemberOfAD: locationEntry
structuralObjectClass: olcMemberOf
creatorsName: cn=config
entryUUID: 91ceb650-9e13-1032-84c4-0151b658a842
createTimestamp: 20130820183919Z
entryCSN: 20130820183919.834337Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20130820183919Z
I have am looking through the application to see if something could have
changed in the way it is presenting the data. I haven't found anything
yet. Am I correct in that an error 32 means that it couldn't find the uid
to add the group to?
Thanks,
Eric Speake
Web Systems Administrator
O'Reilly Auto Parts
(417) 862-2674 Ext. 1975
This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS � 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.
8 years, 12 months
question about openldap restore with command sldapadd
by xiaoming zhao
All,
I got one question, when doing openldap restore, in our script, we tried to remove the openldap/data directory, then restore the backup openldap files.
but since we have other data added in openldap database after backup. then if we doing backup, it will remove the data newly added after backup.
I tried to sldapadd with "-c" option, but the sldapadd command retrun value is 1. so we can't know if this is a error because of existing entry or some other error.
Do you have any idea how to handle this case? ignore the existing entry when doing sldapadd.
Thanks,
Eric.
9 years
Denying access to syncrepl consumere during initial DIT content load
by Christian Kratzer
Hi,
I remember a discussion some time ago about the possibility of delaying access to a syncrepl. consumer during the intial DIT load.
I have setup my servers to authenticate replication via sasl method external and the servers respective certificates which is nice.
I have also setup limits and acl to the DIT as using a groupOfNames:
olcLimits:
group/groupOfNames/member="cn=replicators,ou=serviceaccounts,dc=cksoft,dc=net"
size.soft=unlimited size.hard=unlimited time.soft=unlimited time.hard=unlimited
olcAccess: to *
by group/groupOfNames/member="cn=replicators,ou=serviceaccounts,dc=cksoft,dc=net" read
This is all nice and shiny and I like having my ldap consumers configured without cleartext credentials (apart from the cert private key of course) ;)
The fun starts when I delete the DIT from multiple consumers and allow them to resync from masters. If they also resync from each other they could possibly authenticate using sasl external but they would not be allowed access to all of the DIT, all of the attributes or be unlimited using olcLimits as the group might not yet have been replicated.
I also had major fun just reseeding a single server out of a set of 4 causing data loss on the servers that connected to the not yet full synced up server.
This is another situation in which it would be nice to be able to disallow any ldap connections to a consumere while it is in the initial sync phase.
I seem to recall there was discussion in possibly addiing such a feature but my google foo is lacking and I cannot find the discussion.
In case there is not yet such a feauture I am considering firewalling access to slapd during the initial sync phase. Is there any ldap way of reliably detecting that initial sync has completed apart from tailing syslog and looking for csn commit messages ...
Greetings
Christian
--
Christian Kratzer CK Software GmbH
Email: ck(a)cksoft.de Wildberger Weg 24/2
Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden
Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart
Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer
Web: http://www.cksoft.de/
9 years
RE: Slave not able to update master pwdFailureTime via chain.
by Brad dameron
>From what I read I need to setup authzTo. But having problems understanding what I need to set in the slaps.conf and on the allowed user.
-------- Original message --------
From: Esteban Pereira <esteban.pereira(a)gepsit.fr>
Date:03/20/2014 10:55 AM (GMT-08:00)
To: Brad dameron <serpent6877(a)hotmail.com>,openldap-technical(a)openldap.org
Subject: Re: Slave not able to update master pwdFailureTime via chain.
I've never configured this kind of architecture, but as far as I know the
ppolicy, I think my first thought configuring this would have been to not
rebind as user because the attribute modified is an operational one which
need the manage right (not sure about that)
So I should have configured this with the replication user with manage
right and without rebinding as a user when chaining to the master.
Hope this help
On Thu, Mar 20, 2014 at 6:14 PM, Brad dameron <serpent6877(a)hotmail.com>wrote:
> I understand what you are saying. But this is what the
> ppolicy_forward_updates says:
>
> ppolicy_forward_updates
> Specify that policy state changes that result from Bind operations (such as recording
> failures, lockout, etc.) on a consumer should be forwarded to a master instead of
> being written directly into the consumer’s local database. This setting is only use‐
> ful on a replication consumer, and also requires the updateref setting and chain
> overlay to be appropriately configured.
>
> So when a password failure occurs "pwdFailureTime" it relays it to the master as the user doing a MOD
> from what I have seen in my logs. And thus the user doesn't have access to modify this attribute.
>
> Brad
>
>
>
> ------------------------------
> Date: Thu, 20 Mar 2014 12:13:02 +0100
> Subject: Re: Slave not able to update master pwdFailureTime via chain.
> From: esteban.pereira(a)gepsit.fr
> To: serpent6877(a)hotmail.com
> CC: openldap-technical(a)openldap.org
>
>
> Hi Brad,
>
> pwdFailureTime is an operational attribute, I don't think any user can
> modify it on any instance. May be you should try to modify it on the master
> to see if it comes from this assumption.
>
> Esteban
>
>
> On Thu, Mar 20, 2014 at 11:33 AM, Brad dameron <serpent6877(a)hotmail.com>wrote:
>
> OpenLDAP 2.4.23-26 on CentOS 5. I am trying to get the pwdFailureTime
> updated on the master when the slave recieves a password failure. Here is
> my config. It's pretty simple and basic. No TLS.
>
> Master:
>
> access to attrs=userPassword
> by group.exact="cn=ldapadmins,ou=Groups,dc=test,dc=net" write
> by dn.exact="cn=replication,dc=test,dc=net" read
> by self write
> by anonymous auth
> by * none
> access to *
> by group.exact="cn=ldapadmins,ou=Groups,dc=test,dc=net" write
> by dn.exact="cn=replication,dc=test,dc=net" write
> by self write
> by users read
> by anonymous read
> by * none
>
>
>
> Slave:
>
> overlay chain
> chain-uri ldap://172.16.0.84:389
> chain-rebind-as-user TRUE
> chain-idassert-bind bindmethod=simple
> binddn="cn=replication,dc=test,dc=net"
> credentials="MyPasswd"
> mode="self"
> chain-return-error TRUE
>
> # Password Policy
> overlay ppolicy
> ppolicy_default "cn=default,ou=Policies,dc=test,dc=net
> ppolicy_use_lockout
> ppolicy_forward_updates
>
>
> # Slave Replication
> syncrepl rid=101
> provider=ldap://172.16.0.84:389
> type=refreshAndPersist
> interval=00:00:01:00
> retry="60 10 300 +"
> searchbase="dc=test,dc=net"
> schemachecking=off
> bindmethod=simple
> binddn="cn=replication,dc=test,dc=net"
> credentials="MyPasswd"
> updateref "ldap://172.16.0.84:389"
>
>
>
> I see the connection on the master but it gives a permission error:
>
>
> Mar 20 09:47:46 LDAP-RADIUS-1 slapd[14288]: conn=1124 op=3 MOD
> dn="cn=testuser,ou=People,dc=test,dc=net"
> Mar 20 09:47:46 LDAP-RADIUS-1 slapd[14288]: conn=1124 op=3 MOD
> attr=pwdFailureTime
> Mar 20 09:47:46 LDAP-RADIUS-1 slapd[14288]: conn=1124 op=3 RESULT tag=103
> err=50 text=
>
>
> I read that you maybe need authzTo added to the binddn for the chain? Or
> is this only for TLS?
>
> I tried adding this ldif:
>
> dn: cn=replication,dc=test,dc=net
> changetype: modify
> add: authzTo
> authzTo: *
>
> And even set the:
>
> chain-idassert-authzFrom "*"
>
> in the chain. But it always gives me the error code 50 not enough
> permissions. I believe it is supposed to give access to the user to MOD the
> pwdFailureTime tribute knowing it is coming from a relay. But I can't find
> very specific docs on this or see what is wrong. Any help apreciated.
>
> Thanks,
> Brad
>
>
>
9 years
