slapd daemon stop issue
by Technology Server
Dears
We were trying to stop slapd daemon but after some time it is coming up on
its own. We have provision and replication daemon.
We tried it by killing pid also but unfortunately its coming up on its own.
We have active - active set up for openldap.
what could be the reason that pointing daemon to come up after shut
manually.
Please suggest on this ?
note - We don't have any script which could bring it up when it goes down
Thank you in advance for suggestions.
3 years, 2 months
RE24 testing call #1 (OpenLDAP 2.4.50, LMDB 0.9.26)
by Quanah Gibson-Mount
This is the first testing call for OpenLDAP 2.4.51. Depending on the
results, this may be the only testing call.
Generally, get the code for RE24:
<https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_4...>
Extract, configure, and build.
Execute the test suite (via make test) after it is built. Optionally, cd
tests && make its to run through the regression suite.
Thanks!
OpenLDAP 2.4.51 Engineering
Added slapo-ppolicy implement Netscape password policy controls
(ITS#9279)
Fixed libldap retry loop in ldap_int_tls_connect (ITS#8650)
Fixed libldap to use getaddrinfo in ldap_pvt_get_fqdn (ITS#9287)
Fixed slapd syncrepl to not delete non-replicated attrs (ITS#9227)
Fixed slapd syncrepl to correctly delete entries on resync (ITS#9282)
Fixed slapd-perl dynamic config with threaded slapd (ITS#7573)
Fixed slapo-ppolicy to expose the ppolicy control (ITS#9285)
Fixed slapo-chain to check referral (ITS#9262)
Contrib
Fix default prefix value for pw-argon2, pw-pbkdf2 modules (ITS#9248)
Documentation
ldap_parse_result(3) - Document ldap_parse_intermediate (ITS#9271)
LMDB 0.9.26 Engineering
ITS#9278 fix robust mutex cleanup for FreeBSD
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
3 years, 2 months
LDAP error, server says:,(8) Strong(er) authentication required
by Lothar Schilling
Hi everybody,
I am completely new to this group - and to OpenLDAP as well. Trying to get rid of our Windows SBS domain controller I am building a new Samba 4 server dedicated only to domain controlling, Debian 10.4, Samba 4.9.5. I'm doing this from scratch, following the textbooks. I've also setup LAM as graphical interface for administration.
But once I try logging into the server's profile via that LAM interface as Administrator, I get this: "LDAP error, server says: (8) Strong(er) authentication required".
(1) "ldbsearch -H ldap://ldap.[my].[domain] "cn=Administrator" -k yes": is working with the same password I would use in LAM
(2) Server profile settings in LAM
- TLS is deactivated
- Login: Fixed list, cn=Administrator,cn=users,dc=[my],dc=[domain]
(3) ldap.conf
#
# LDAP Defaults
#
# See ldap.conf(5) for details
# This file should be world readable but not world writable.
BASE dc=[my],dc=[domain]
URI ldap://ldap.[my].[domain] ldap://ldap-master.[my].[domain]:666
#SIZELIMIT 12
#TIMELIMIT 15
#DEREF never
# TLS certificates (needed for GnuTLS)
#TLS_CACERT /etc/ssl/certs/ca-certificates.crt
What am I doing wrong?
Help appreciated, thank you!
Lothar Schilling
3 years, 2 months
Re: RE24 testing call #1 (OpenLDAP 2.4.51, LMDB 0.9.26)
by Nick Folino
No issues on Fedora 32 - 5.7.8-200.fc32.x86_64
3 different computers with the following processors:
AMD Ryzen 5 2500U with Radeon Vega Mobile Gfx
Intel(R) Xeon(R) CPU E5630 @ 2.53GHz
Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz
On Thu, Jul 23, 2020 at 6:14 PM Quanah Gibson-Mount <quanah(a)symas.com>
wrote:
> Subject correction -- 2.4.51. ;)
>
> --Quanah
>
> --On Thursday, July 23, 2020 4:02 PM -0700 Quanah Gibson-Mount
> <quanah(a)symas.com> wrote:
>
> > This is the first testing call for OpenLDAP 2.4.51. Depending on the
> > results, this may be the only testing call.
> >
> > Generally, get the code for RE24:
> >
> > <
> https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_
> > 4/openldap-OPENLDAP_REL_ENG_2_4.tar.gz>
> >
> > Extract, configure, and build.
> >
> > Execute the test suite (via make test) after it is built. Optionally, cd
> > tests && make its to run through the regression suite.
> >
> > Thanks!
> >
> > OpenLDAP 2.4.51 Engineering
> > Added slapo-ppolicy implement Netscape password policy controls
> > (ITS#9279)
> > Fixed libldap retry loop in ldap_int_tls_connect (ITS#8650)
> > Fixed libldap to use getaddrinfo in ldap_pvt_get_fqdn (ITS#9287)
> > Fixed slapd syncrepl to not delete non-replicated attrs (ITS#9227)
> > Fixed slapd syncrepl to correctly delete entries on resync (ITS#9282)
> > Fixed slapd-perl dynamic config with threaded slapd (ITS#7573)
> > Fixed slapo-ppolicy to expose the ppolicy control (ITS#9285)
> > Fixed slapo-chain to check referral (ITS#9262)
> > Contrib
> > Fix default prefix value for pw-argon2, pw-pbkdf2 modules
> > (ITS#9248)
> > Documentation
> > ldap_parse_result(3) - Document ldap_parse_intermediate
> (ITS#9271)
> >
> > LMDB 0.9.26 Engineering
> > ITS#9278 fix robust mutex cleanup for FreeBSD
> >
> > --
> >
> > Quanah Gibson-Mount
> > Product Architect
> > Symas Corporation
> > Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> > <http://www.symas.com>
>
>
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>
3 years, 2 months
Questions regarding certain ACL constructs
by Michal Soltys
Hi,
Just wanted to ask/clarify about few things related to ACLs:
1) @extensibleObject
In one of the faq entries, namely:
https://www.openldap.org/faq/data/cache/1140.html
there is a construct that looks superfluous:
access to dn.onelevel="cn=bar,ou=Stuff,dc=example,dc=com"
attrs=entry,@extensibleObject
Doesn't @extensibleObject include everything - entry, children and
regular attributes - by default ?
That's what I'd imply from the official documentation that states that
not explicitly specifying attrs= is equivalent to attrs=@extensibleObject
If so, then the above is equivalent to just:
access to dn.onelevel="cn=bar,ou=Stuff,dc=example,dc=com"
2) entry pseudo-attribute vs writing to regular attributes
This is one thing that somewhat surprises me - as the read/search access
explicitly requires relevant access to entry pseudo-attribute (as per
OPERATION REQUIREMENTS from slapd.access manpage).
The write access on the other hand doesn't mention any requirements
besides add/delete/write to the attribute itself. This actually holds
true right ?
3) attr based access
In one of the examples (8.4.5. Granting access to a subset of
attributes), question regarding:
# immediate children: only self can add/delete entries under this entry
access to attrs=children
by self write
# entry itself: self may write, all may read
access to attrs=entry
by self write
by * read
They still do require other ACLs, as "selfs" in both cases are
different, right ? E.g. if self matches parent, it won't match children
being created and vice-versa (and as per the manual page - 'add' is
required both for parent's 'children' as well as new entry's 'entry').
ITOW if we bind as the entity wanting to create new entry underneath,
the above is not enough - and we need something more elaborate like in
e.g. address book example.
4) access rights required for deeper searches
suppose we have structure like:
ou=A, dc=example, dc=com
ou=B, ou=A, dc=example, dc=com
uid=msl, ou=B, ou=A, dc=example, dc=com
If we do search for uid using 'ou=A, dc=example, dc=com' as a search
base (with subtree scope), what (if any) access rights do we need on
'ou=B, ou=A, dc=example, dc=com' ?
5) sets
Is this feature assumed safe to use ? As - it's still formally
undocumented (man pages), but there are examples on the website and
syntax explanation in the faq.
3 years, 2 months
Q about add accesslog entry
by Ulrich Windl
Hi!
I found this accesslog entry, caused by a server-sync it seems (some strings replaced consistently for privacy):
---
dn: reqStart=20200722085045.000019Z,cn=audit
objectClass: auditModify
structuralObjectClass: auditModify
reqStart: 20200722085045.000019Z
reqEnd: 20200722085045.000060Z
reqType: modify
reqSession: 6
reqAuthzID: cn=Admin,dc=example,dc=org
reqDN: uid=username,ou=people,dc=example,dc=org
reqResult: 0
reqMod: entryCSN:= 20200722082119.640611Z#000000#003#000000
reqMod: modifiersName:= cn=Admin,dc=example,dc=org
reqMod: modifyTimestamp:= 20200722082119Z
reqOld: entryCSN: 20200722082119.640611Z#000000#003#000000
reqOld: modifiersName: cn=Admin,dc=example,dc=org
reqOld: modifyTimestamp: 20200722082119Z
reqEntryUUID: 2d063f78-7ced-1032-948d-cf46530da60d
entryUUID: 2cefa3e8-6044-103a-8b01-193e5edbb211
creatorsName: cn=audit
createTimestamp: 20200722082119Z
entryCSN: 20200722082119.640611Z#000000#003#000000
modifiersName: cn=audit
modifyTimestamp: 20200722082119Z
---
So if I see it correctly, only the entryUUID changed? Actually I wouldn't expect the entryUUID to change. Obviously the entry could not have been recreated after being deleted, because otherwise some other field would have changed, right? Or could this be a late consequence of improper slapadd (entryUUIDs not taken from slapcat) long time ago?
Regards,
Ulrich
3 years, 2 months
Q: UNKNOWN attributeDescription "AUDITCONTEXT" inserted.
by Ulrich Windl
Hi!
After systemd tearing down one of our LDAP servers I noticed the following message when the server was restarted:
slapd[10525]: UNKNOWN attributeDescription "AUDITCONTEXT" inserted.
The next line logged was:
slapd[10525]: olcServerID: value #1: SID=0x002 (listener=ldap://...:389)
(the server is that of SLES12 SP4, 2.4.41 from opensuse-buildservice)
The server is one of three MM servers that all have the same configuration and the same version.
The schema knows in olcAttributeTypes (olcSchemaConfig):
( 1.3.6.1.4.1.4203.666.11.5.1.30 NAME 'auditContext' DESC 'DN of auditContainer' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )
What I'l like to know: Is there any thing I could fix in the configuration to make the message go away, or is it some software issue in slapd?
Regards,
Ulrich
3 years, 2 months
Q: Stable output of slapcat?
by Ulrich Windl
Hi!
I wonder: Is the output of slapcat expected to be stable (assuming the database did not change)? I know that LDAP attributes are considered to be sets that have no implicit ordering, but diff-wise it would be rather nice to have a stable output ordering.
Here is an example of non-stable output ordering (sdiff output, only first 18 columns for confidentiality):
# sdiff b0 b1
dn: olcDatabase={1 dn: olcDatabase={1
objectClass: olcDa objectClass: olcDa
objectClass: olcHd objectClass: olcHd
olcDatabase: {1}hd olcDatabase: {1}hd
olcDbDirectory: /v olcDbDirectory: /v
olcSuffix: dc=sap, olcSuffix: dc=sap,
olcAccess: {0}to * <
olcAccess: {1}to d <
olcAccess: {2}to a <
olcAccess: {3}to a <
olcAccess: {4}to a <
olcAccess: {5}to * <
olcLimits: {0}dn.e olcLimits: {0}dn.e
olcRootDN: cn=Admi olcRootDN: cn=Admi
olcRootPW: {SSHA}y olcRootPW: {SSHA}y
olcSecurity: ssf=1 olcSecurity: ssf=1
olcSyncrepl: {0}ri olcSyncrepl: {0}ri
olcSyncrepl: {1}ri olcSyncrepl: {1}ri
olcSyncrepl: {2}ri olcSyncrepl: {2}ri
olcUpdateRef: ldap olcUpdateRef: ldap
olcUpdateRef: ldap olcUpdateRef: ldap
olcUpdateRef: ldap olcUpdateRef: ldap
olcMirrorMode: TRU olcMirrorMode: TRU
olcDbCacheSize: 10 olcDbCacheSize: 10
olcDbCheckpoint: 1 olcDbCheckpoint: 1
olcDbConfig: {0}se olcDbConfig: {0}se
olcDbConfig: {1}se olcDbConfig: {1}se
olcDbConfig: {2}se olcDbConfig: {2}se
olcDbConfig: {3}se olcDbConfig: {3}se
olcDbConfig: {4}se olcDbConfig: {4}se
olcDbConfig: {5}se olcDbConfig: {5}se
olcDbIDLcacheSize: olcDbIDLcacheSize:
olcDbIndex: object olcDbIndex: object
olcDbIndex: uidNum olcDbIndex: uidNum
olcDbIndex: gidNum olcDbIndex: gidNum
olcDbIndex: member olcDbIndex: member
olcDbIndex: member olcDbIndex: member
olcDbIndex: cn eq, olcDbIndex: cn eq,
olcDbIndex: uid eq olcDbIndex: uid eq
olcDbIndex: sn eq, olcDbIndex: sn eq,
olcDbIndex: givenN olcDbIndex: givenN
olcDbIndex: entryU olcDbIndex: entryU
olcDbIndex: entryC olcDbIndex: entryC
olcDbIndex: ipServ olcDbIndex: ipServ
olcDbIndex: ipServ olcDbIndex: ipServ
olcDbIndex: roleOc olcDbIndex: roleOc
olcDbIndex: mail e olcDbIndex: mail e
olcDbIndex: displa olcDbIndex: displa
olcDbIndex: modify olcDbIndex: modify
structuralObjectCl structuralObjectCl
entryUUID: db3ffe4 entryUUID: db3ffe4
creatorsName: cn=c creatorsName: cn=c
createTimestamp: 2 createTimestamp: 2
entryCSN: 20170706 | olcAccess: {0}to *
> olcAccess: {1}to d
> olcAccess: {2}to a
> olcAccess: {3}to a
> olcAccess: {4}to a
> olcAccess: {5}to *
> entryCSN: 20200114
modifiersName: cn= modifiersName: cn=
modifyTimestamp: 2 modifyTimestamp: 2
So is the order of output given by some hash functions in slapcat, or is it the order in which the database returns the attributes?
What would I have to do to sort the attribute types in the same order as they are listed in the schema (one possible stable output)?
Regards,
Ulrich
3 years, 2 months
anonymize data
by Olivier -
Hi all,
I have a question anonymizing data.
My openldap have some confidential data inside and I would like this : if a person has a flag confidentiality set to 1 (or is in a special ou), openldap will replace or answer a different data.
For example :
if we request "sn" on this record , it will reply "Smith"
dn: cn=Smith,ou=public,c=com
confidentiality: 0
sn: Smith
if we request "sn" on this record , it will reply "XXX"
dn: cn=Bond,ou=public,c=com
confidentiality: 1
sn: Bond
I'm not sur Openldap can offer this kind of functionnality.
Thanks for your help !
3 years, 2 months
Re: Upgrade from 2.4.44 to 2.4.45+
by Quanah Gibson-Mount
--On Monday, July 20, 2020 11:26 PM -0700 rammohan ganapavarapu
<rammohanganap(a)gmail.com> wrote:
> What is the upgrade process from 2.4.44 to 2.4.45 or above? Are there any
> breaking changes that I need to take care before and/or after upgrading?
a) You need to be upgrading to 2.4.50, 2.4.45 has a few CVEs.
b) If you use ppolicy, you will want to reload your database after
upgrading to 2.4.50 due to a database format change for the pwdChangedTime
attribute (I.e., slapcat your db, then slapadd it back in after you're done
with the upgrade).
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
3 years, 2 months
