replica of schema info
by Francesco Malvezzi
good morning,
I would like to be able to replicate the schema info only from cn=config.
I tried to add the olcSyncrepl to cn=schema
dn: cn=schema,cn=config
changetype: modify
add: olcSyncrepl
olcSyncrepl: ....
but doesn't work:
<olcSyncrepl> only allowed within database declaration
I tried to push a whole new olcDatabase={0}config (next step would be to
add glue overlay to olcDatabase={1}config,cn=config)
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to * by
dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external
,cn=auth manage by * break
olcAccess: {1}to dn.base="cn=config" by * none
olcSuffix: cn=schema,cn=config
olcRootDN: cn=admin,cn=schema,cn=config
olcRootPW:: e1NTSEF9bnNNYkxIMFhFTm0zaXA5N0JXaHRVb3RwTlRsRXRxNTA=
olcMonitoring: FALSE
olcSyncrepl: ....
but it doesn't work:
olcSuffix: value #0: suffix <cn=schema,cn=config> not allowed in config
database.
It does work to add olcSyncrepl to olcDatabase={0}config,cn=config with
a filter like:
olcSyncrepl: {0}rid=001 provider=... binddn=... bindmethod=simple
search base="cn=schema,cn=config" filter="(!(cn=core))"
but then the whole olcDatabase={0}config,cn=config becomes a shadow
context and I'm unable to ldapmodify anything (olcLoglevel for example).
What am I missing?
thank you for reading me,
Francesco
8 years, 10 months
Need Schema for aci attribute
by neel
Hi,
I have compiled and configured OpenLDAP 2.4.39 with ACI.
I am trying to integrate one application with LDAP. I have entered all
settings. Authentication is working fine. Only thing when it tries to add
some entries to ldap, it says that "err=17 text=aci: attribute type
undefined"
Can you please provide schema for aci attribute?
Regards
Neelesh
8 years, 10 months
[LMDB] Choosing right environment flags
by Alain
I need to better understand the best way to configure the various
environment flags related to sync and map.
When we converted from BDB to LMDB, we instinctively kept #MDB_NOSYNC true.
This proved to make the database subject to corruption if it was killed or
stopped too harshly. It also had the effect on Windows at least to make
Windows gradually use up all available RAM for the memory mapped file and
to bring the server to its knees.
After carefully reading the documentation about leaving "the system with no
hint for when to write transactions to disk" when MDB_NOSYNC was turned on,
we completely went without setting any options. The results were that we
can't corrupt the database, but the speed degradation makes this approach
unusable, as we are very heavily write focused (at least in this part of
our process, where we perform analysis and load the database with 100's
millions of records).
In looking at the documentation I'm tempted to try MDB_WRITEMAP with
MDB_MAPASYNC but do I then need to also issue some manual mdb_env_sync and
if so at what frequency and what should trigger this?
What are best practices combinations of those flags here. We absolutely
can't afford database corruption, but we can deal with one (or maybe more
with some re-design) transactions that are lost.
Please guide us.
Thanks
Alain
8 years, 10 months
password policy module memory leaks / excessive replication?
by Paul B. Henson
I've been testing the password policy module lately. I updated our
development LDAP infrastructure Monday, basically loading and enabling the
module, adding a default policy:
dn: cn=default,ou=ppolicy,dc=csupomona,dc=edu
cn: default
objectClass: organizationalRole
objectClass: pwdPolicy
pwdAttribute: userPassword
pwdLockout: TRUE
pwdLockoutDuration: 1800
pwdMaxFailure: 100
pwdFailureCountInterval: 300
And a policy specific for service accounts:
dn: cn=serviceaccount,ou=ppolicy,dc=csupomona,dc=edu
cn: serviceaccount
objectClass: organizationalRole
objectClass: pwdPolicy
pwdAttribute: userPassword
After some initial testing and determining that the current implementation
is not suitable for account lockouts, I haven't touched it since Monday.
Yesterday, I started getting alerts that the systems were low on memory, and
upon looking, found extremely bloated slapd processes. Next, I started
getting alerts that the accesslog mdb was running out of space.
Upon investigation, I found that the service account that is used to gather
statistics was generating a considerable amount of churn every time it
authenticated (every 30 seconds). This account was explicitly configured to
use the service account password policy:
dn: cn=slapd-monitor,ou=user,ou=service,dc=csupomona,dc=edu
objectClass: person
cn: slapd-monitor
sn: LDAP monitoring account
pwdPolicySubentry: cn=serviceaccount,ou=ppolicy,dc=csupomona,dc=edu
Which should be pretty much "do nothing". (I realize now that this policy
will actually result in pwdFailureTime entries being created for failed
authentications, and accumulating forever until a successful authentication,
but there are no failed authentications for this service account, only
successful ones, in this case).
There were 1662836 entries in the access log for this dn since Monday that
as far as I can tell solely change the CSN:
dn: reqStart=20140502031556.000000Z,cn=accesslog
objectClass: auditModify
structuralObjectClass: auditModify
reqStart: 20140502031556.000000Z
reqEnd: 20140502031558.000000Z
reqType: modify
reqSession: 2
reqAuthzID: cn=ldaproot,dc=csupomona,dc=edu
reqDN: cn=slapd-monitor,ou=user,ou=service,dc=csupomona,dc=edu
reqResult: 0
reqMod: entryCSN:= 20140501211559.348458Z#000000#003#000000
reqMod: modifiersName:= cn=ldaproot,dc=csupomona,dc=edu
reqMod: modifyTimestamp:= 20140501211559Z
reqEntryUUID: c16729b0-ce1e-4f9d-9123-e0b8f115133c
entryUUID: 240ec245-0bac-4e20-b387-19243f720674
creatorsName: cn=accesslog
createTimestamp: 20140501211559Z
entryCSN: 20140501211559.348458Z#000000#003#000000
modifiersName: cn=accesslog
modifyTimestamp: 20140501211559Z
This explains why the accesslog was running out of space, it was full of
these. It doesn't explain why the slapd process exploded in memory use,
unless I suppose the steady-state memory usage of a slapd this busy
processing replication is higher than one that's not quite so busy.
But I'm confused as to why loading the password policy module, for an
account with a policy configured to pretty much not do anything, results in
a modification of the CSN for every authentication?
I'm going to go peruse the source code to see if I can determine what's
going on, but any expert opinions would be most welcome.
Thanks much.
8 years, 10 months
autoreconf failing with automake errors
by rajesh＠linux.vnet.ibm.com
Hi,
I am trying to build the openldap package from the source following
the release tarball from
ftp://ftp.openldap.org/pub/OpenLDAP/openldap-release/openldap-2.4.39.tgz.
I am building this package in a new architecture ppc64le ( IBM PowerPC
Little endian ). As the config.guess and libtool did not have the
required patches to identify this new architecture, I did autoreconf
-f -i in my build system whose latest automake and libtool has the
patches of ppc64le. but the autoreconf failed with the following error
automake: error: no 'Makefile.am' found for any configure output
autoreconf: automake failed with exit status: 1
As the config.guess and configure scripts were updated with the
ppc64le patches, i went ahead building the package. IT subsequently
failed during 'make' with the following errors
make[2]: Entering directory `/home/rajesh/openldap/openldap/libraries/liblber'
rm -f version.c
../../build/mkversion -v "2.X" liblber.la > version.c
/bin/sh ../../libtool --mode=compile cc -g -O2 -I../../include
-I../../include -DLBER_LIBRARY -c assert.c
../../libtool: 1: eval: base_compile+= cc: not found
../../libtool: 1: eval: base_compile+= -g: not found
../../libtool: 1: eval: base_compile+= -O2: not found
../../libtool: 1: eval: base_compile+= -I../../include: not found
../../libtool: 1: eval: base_compile+= -I../../include: not found
../../libtool: 1: eval: base_compile+= -DLBER_LIBRARY: not found
../../libtool: 1: eval: base_compile+= -c: not found
libtool: compile: you must specify a compilation command
libtool: compile: Try `libtool --help --mode=compile' for more information.
make[2]: *** [assert.lo] Error 1
FYI,
I also tried verified building the package in x86 ( Intel Box ) to get
some clues if it is specific to ppc64le architecture. Without doing a
autoreconf (which I dont require in my x86 laptop), the package
building was sucessful. When I did autoreconf in my x86 laptop, I was
struck with the similar errors as I had mentioned above.
So, can anyone provide any clues how to progress or redirect this mail
to the right person if this is not the right place to discuss this
issue?
Thanks and Regards
Rajeshkumar S
Linux Technology Center, IBM
8 years, 10 months
LDAP_OPT_X_TLS_CACERTDIR not working.
by Seshadri, Anitha
Hi,
I would like to open a discussion with OpenLDAP team. I hope this is the right email address. If not please let me know the correct to which this mail should be directed to.
Issue:
We are currently using OpenLdap 2.4.16 version on Win 64 .We are using RSA and MES Shareadapter internally to build the openldap libs.
I am getting the below error when I use Sha-256 (2048 key length) certificates:
ldap_sasl_bind_s: Can't contact LDAP server (-1) error:14090086:SSL routines: SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
I am using the option LDAP_OPT_X_TLS_CACERTDIR and pass the cert directory which has the certificates. This fails.
But the same passes when I use LDAP_OPT_X_TLS_CACERTFILE and point to the certicate which is of .pem format.
Can you please let me know I am missing something here or is this a bug?
Any help on this is appreciated.
Thanks
Anitha
8 years, 10 months
Moving From Debian 2.4.31/hdb to LTB 2.4.39/mdb
by Andy Dorman
Hi. We have been using OpenLDAP for about 11 years now and have an MMR
set up with 2 masters and 18 delta-syncrepl clients/slaves, all but 3
slaves are currently using back_hdb. Our beta test server and two load
balancers are using back_mdb. The db is not too big with about 50,000
entries, 9 indexes (7 eq & 2 sub) and the slapdump ldif is about 41 MB.
All our servers are Debian "testing" with a few packages from unstable
and even experimental so we have the latest security and feature fixes
for the work we do (email security filtering). Unfortunately, even the
"bleeding edge" debian releases are waaaay behind in OpenLDAP.
Last year we lost our system admin that set all this up, and I have been
on a very steep learning curve since then. At this time I believe we
need to move to a current version of OpenLDAP via ltb-project and switch
to mdb, but I have run into a couple of questions we need to resolve first.
FWIW, I would dearly like to help out the Debian community and compile &
maintain an up-to-date version of OpenLDAP for them, but I need at least
a couple more years of experience before it is even marginally safe to
have other companies depending on my expertise with debian packaging.
Anyway, after reading the OpenLDAP & ltb-project docs I have a couple of
questions for anyone already using the ltb-project debian release,
slapd.d & mdb. I hope the answers will help make our and others'
transition go more smoothly.
So here we go....
Question #1. I see that slapd.conf is deprecated and we should move to a
slapd.d config db.
However, the slapd.conf file (with git & cfengine) meets 3 key
requirements for our service's configuration management: (1) audit
trail, (2) peer review & staff notification, (3) automatic, staggered
release to all servers so our users experience 0 downtime.
I do not yet see an "easy" way to meet the first two requirements using
slapd.d.
To satisfy #3 I hope we can just update our master server slapd.d and
config changes will be replicated to the slaves. Someone please correct
me if I am wrong about that.
To meet the requirement for an audit trail & staff review &
notification, in the absence of someone's experience and/or knowledge
from this group, we currently plan to use our ticket-tracking system
(Request Tracker). Within an RT queue dedicated to our db systems we
will document, review & manage slapd.d changes prior to actually making
a change in the master which will then (I hope) propagate through
delta-syncrepl.
How does anyone else that is using slapd.d with an MMR setup with
multiple client/slaves take care of their needs for an audit trail, peer
review/staff notification, and release to all those servers?
Question #2. This may be a simple one....When reading the latest
OpenLDAP docs at http://www.openldap.org/doc/admin24/slapdconf2.html I
noticed that there are no references to back_mdb in the configuration
documentation...Specifically, "Table 5.2: Database Backends" and "Table
6.2: Database Backends" do not show an "mdb" option. Is this an
oversight or is mdb going away already or am I completely confused? I
suspect the answer is #3 ;-)
Basically I need to know what to use in the "backend" & "database"
directives (slapd.conf) or "olcBackend" attribute (slapd.d) if we want
the mdb backend?
Thank you for your insights and any information you can share.
--
Andy Dorman
Ironic Design, Inc.
AnteSpam.com, ComeHome.net
CONFIDENTIALITY NOTICE: This message is for the named person's use only.
It may contain confidential, proprietary or legally privileged
information. No confidentiality or privilege is waived or lost by any
erroneous transmission. If you receive this message in error, please
immediately destroy it and notify the sender. You must not, directly or
indirectly, use, disclose, distribute, or copy any part of this message
if you are not the intended recipient.
8 years, 10 months
problems in memberof overlay
by goal jeff
hi.
I configured the function of 'memberof overlay' these days.
At first I used the methods on the webpage of
http://www.openldap.org/doc/admin24/overlays.html, I add the codes of "overlay
memeberof" in the file of slapd.conf,then I started the slapd service, the
system give me an error "overlay "memberof" not found" .
second,I googled the internet and found an article on this
webpage:http://www.redmine.org/projects/redmine/wiki/RedmineLDAP,so I create two
LDIF files as follow:
the first file :
dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
olcModulePath: /usr/lib/ldap
olcModuleLoad: memberof
the second file:
dn: olcOverlay=memberof,olcDatabase={1}hdb,cn=config
objectClass: olcMemberOf
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
olcOverlay: memberof
olcMemberOfDangling: ignore
olcMemberOfRefInt: TRUE
olcMemberOfGroupOC: groupOfNames
olcMemberOfMemberAD: member
olcMemberOfMemberOfAD: memberOf
after I entered the command "ldapadd -x -D 'cn=Manager,dc=example,dc=com' -W
-f 1.ldif",the system give an error:"ldap_add: Insufficient access (50)"
please help me ,thanks.
8 years, 10 months
Help with SASL generic GSSAPI error
by Joshua Schaeffer
I'm looking for a little help concerning the below error I get when I do
an ldapsearch:
root@mytest:~# ldapsearch -Y GSSAPI
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Other (e.g., implementation specific)
error (80)
additional info: SASL(-1): generic failure: GSSAPI Error:
Unspecified GSS failure. Minor code may provide more information ()
That error is pretty generic to me and the searching I've done to find a
solution has not yielded anything successful. I have MIT Kerberos and
SASL setup and I'm able to successfully get a TGT from any machine that
can see my KDC. I also can successfully search my ldap directory using
simple authentication. I've run the sasl-sample-client and server
between several machines including: ldap server to krb server, test
server to krb server, test server to ldap server, etc. I can complete
the sasl test on every one. Running slapd in debug mode doesn't provide
me with any additional information:
root@baneling:~# slapd -h "ldap:/// ldapi:///" -d 256
5371865b @(#) $OpenLDAP: slapd (Apr 23 2013 12:16:04) $
root@lupin:/tmp/buildd/openldap-2.4.31/debian/build/servers/slapd
5371865c slapd starting
53718672 conn=1000 fd=13 ACCEPT from IP=10.1.10.10:53839 (IP=0.0.0.0:389)
53718672 conn=1000 op=0 BIND dn="" method=163
53718672 SASL [conn=1000] Failure: GSSAPI Error: Unspecified GSS
failure. Minor code may provide more information ()
53718672 conn=1000 op=0 RESULT tag=97 err=80 text=SASL(-1): generic
failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide
more information ()
53718672 conn=1000 op=1 UNBIND
53718672 conn=1000 fd=13 closed
53718672 connection_read(13): no connection!
I do have the keytab in a non-standard location on the ldap server
(/etc/ldap/ldap.keytab), so I modified /etc/default/slapd and restarted
slapd. I'm not really sure what I can provide from my cn=config that
would help diagnose this issue let me know and I can respond with the
details.
Here is my ldap.conf from the server I'm running the ldapsearch from (my
test server):
root@mytest:~# cat /etc/ldap/ldap.conf
#
# LDAP Defaults
#
# See ldap.conf(5) for details
# This file should be world readable but not world writable.
BASE dc=harmonywave,dc=com
URI ldap://baneling.harmonywave.com
#SIZELIMIT 12
#TIMELIMIT 15
#DEREF never
# TLS certificates (needed for GnuTLS)
TLS_CACERT /etc/ssl/certs/ca.harmonywave.com.pem
TLS_REQCERT demand
TLS_CHECKPEER yes
TLS_CIPHER_SUITE SECURE256
# LDAP sudo settings
sudoers_base ou=SUDOers,dc=harmonywave,dc=com
# SASL Kerberos settings
SASL_MECH GSSAPI
SASL_REALM HARMONYWAVE.COM
Thanks,
Josh
8 years, 10 months
Phantom certificates?
by Andrew D. Arenson
I am trying to understand how a ldap server's certificate is
being verified in the absence of the appropriate CA certificates. I
have openldap 2.4.23-34 installed.
If I set TLS_CACERTDIR to a dummy directory (like /home/aarenson),
ldapsearch tells me, as expected, that the server's certificate is
not verified. If I set TLS_CACERTDIR to a directory where I have placed
the file with my CA certificates, ldapsearch tells me, again as expected,
that the server's certificate _IS_ verified.
The situation that is surprising me, though, is that if I set
TLS_CACERTDIR to /etc/openldap/certs, which has the cert8.db file, but
as far as I can tell has no actuall certificates in that database, ldap
search tells me, surprisingly, that the server's certificate _IS_ verified.
How is openldap verifying my server's certificate?
When I look in /etc/openldap/certs for certificates, I find
none:
===========================================================================
=
[root@in-rtls-dev02 certs]# pwd
/etc/openldap/certs
[root@in-rtls-dev02 certs]# ls
cert8.db key3.db less password secmod.db
[root@in-rtls-dev02 certs]# certutil -d . -L
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
=
===========================================================================
I have put a file with the appropriate chain of signing certificates
in /etc/pki/tls/certs as incommon_chain_2013.pem:
===========================================================================
=
[root@in-rtls-dev02 certs]# pwd
/etc/pki/tls/certs
[root@in-rtls-dev02 certs]# ls
3641f99d.0 Makefile incommon-ie.pem make-dummy-cert
9de8458f.0 ca-bundle.crt incommon_chain_2013.pem renew-dummy-cert
9ef5f911.0 ca-bundle.trust.crt iu-bl-inter-ie.pem
=
===========================================================================
Here's the system ldap configuration I'm using:
===========================================================================
=
[root@in-rtls-dev02 openldap]# pwd
/etc/openldap
[root@in-rtls-dev02 openldap]# cat ldap.conf
#
# LDAP Defaults
#
# See ldap.conf(5) for details
# This file should be world readable but not world writable.
#BASE dc=example,dc=com
#URI ldap://ldap.example.com ldap://ldap-master.example.com:666
#SIZELIMIT 12
#TIMELIMIT 15
#DEREF never
#TLS_REQCERT allow
TLS_REQCERT demand
#TLS_CACERTDIR /etc/openldap/certs
#TLS_CACERTDIR /etc/pki/tls/certs
TLS_CACERTDIR /home/aarenson
=
===========================================================================
Here is the user ldap configuration I'm using. It is all commented
out:
===========================================================================
=
[in-rtls-dev02.uits.iupui.edu:/home/aarenson] bash> cat .ldaprc
# Instruct client to try requesting a server's cert.
#TLS_REQCERT allow
#TLS_REQCERT demand
# Define location of CA Cert
#TLS_CACERTDIR /etc/openldap/certs
#TLS_CACERTDIR /etc/pki/tls/certs
#TLS_CACERTDIR /home/aarenson
=
===========================================================================
Here are the three invocations of ldapsearch:
===========================================================================
=
[in-rtls-dev02.uits.iupui.edu:/home/aarenson] bash> ldapsearch -d 9 -D "aarenson(a)ads.iu.edu" -w "<PASSWORD>" -H ldaps://ads.iu.edu:636 -b "ou=Accounts,dc=ads,dc=iu,dc=edu" -s sub "(sAMAccountName=aarenson)"
...
TLS: certificate [CN=InCommon Server CA,OU=InCommon,O=Internet2,C=US] is not valid - error -8179:Peer's Certificate issuer is not recognized..
...
[in-rtls-dev02.uits.iupui.edu:/home/aarenson] bash> LDAPTLS_CACERTDIR=/etc/pki/tls/certs LDAPTLS_REQCERT=demand ldapsearch -d 9 -D "aarenson(a)ads.iu.edu" -w "<PASSWORD" -H ldaps://ads.iu.edu:636 -b "ou=Accounts,dc=ads,dc=iu,dc=edu" -s sub "(sAMAccountName=aarenson)"
...
distinguishedName: CN=aarenson,OU=Accounts,DC=ads,DC=iu,DC=edu
...
[in-rtls-dev02.uits.iupui.edu:/home/aarenson] bash> LDAPTLS_CACERTDIR=/etc/openldap/certs LDAPTLS_REQCERT=demand ldapsearch -d 9 -D "aarenson(a)ads.iu.edu" -w "<PASSWORD>" -H ldaps://ads.iu.edu:636 -b "ou=Accounts,dc=ads,dc=iu,dc=edu" -s sub "(sAMAccountName=aarenson)"
...
distinguishedName: CN=aarenson,OU=Accounts,DC=ads,DC=iu,DC=edu
...
=
===========================================================================
Andy
--
Andrew D. Arenson | aarenson (@) iu.edu
Advanced Biomedical IT Core, Research Technologies, UITS | W (317) 278-1208
RT is a PTI Cyberinfrastructure & Service Center | C (317) 679-4669
Indiana University Purdue University Indianapolis | F (317) 278-1852
8 years, 10 months
