Problem with "force user to password reset at first login
by Rajagopal Rc
Hi,
I am trying to force users to change their password at first login or
after
password reset by administrator.
Tried following:
1)Password policy 'pwdMustChange TRUE' doesn't seems to be working as non
of the
users get prompt to change their password at first login.
2) used the 'pwdReset TRUE' attribute in users attributes, and it won't
prompt
to change the password and didn't allow to login
i observe below messages in log
"slapd[12684]: connection restricted to password changing only
slapd[12684]: send_ldap_result: err=50 matched="" text="Operations are
restricted to bind/unbind/abandon/StartTLS/modify password"
slapd[12684]: conn=1053 op=1 SEARCH RESULT tag=101 err=50 nentries=0
text=Operations are restricted to bind/unbind/abandon/StartTLS/modify
password"
Please help me configure the option to force all users to change their
password
at first login or after pwd reset by administrator.
Thanks & Regards
Raj
Tata Consultancy Services
Mailto: rajagopal.rc(a)tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty. IT Services
Business Solutions
Consulting
____________________________________________
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you
4 weeks, 1 day
mdb_env_close, mdb_dbi_close, mdb_dbi_open
by Sam Dave
Hi,
I'm interested in understanding these functions better. These are not criticisms.. since these functions are called rarely, I have no problem synchronizing them. I ask only for curiosity's sake.
* mdb_env_close: "Only a single thread may call this function." Why can't different environments (separate files/dirs on disk) be closed from different threads?
* mdb_dbi_close: "Handles should only be closed by a single thread." Why can't at least databases on different environments (separate files/dirs on disk) be closed from different threads?
* mdb_dbi_open: "This function must not be called from multiple concurrent transactions in the same process." Why can't this function be called from different threads to open at least databases on different environments (separate files/dirs on disk)?
What are the reasons for these limitations, under the hood? Could these functions have been designed in a different way, to allow for more multithreading (again, I'm not asking for this, I'm just curious).
- Sam
3 months, 1 week
ACL with filter memberOf
by Carsten Jäckel
Dear experts,
an accessUser account used for application access has to be granted read access to member accounts of a group (groupOfNames). The list of attributes to be read by the accessUser is limited.
The accessUser has to search in the limited attribute list (e. g. uid=abcd).
Using OpenLDAP 2.4.49 (with configured overlay 'memberOf') we achieved this goal by configuring the following ACLs in olcAcces of olcDatabase={1}mdb,cn=config:
{0}to * by self read by anonymous auth by * break
{1}to dn.subtree="dc=example,dc=com" filter="(|(dc=example)(dc=users))" attrs="entry,Objectclass,dc" by dn.exact="cn=accessUser,dc=accessUsers,dc=example,dc=com" read by * break
{2}to dn.subtree="dc=users,dc=example,dc=com" filter="(memberOf=cn=group1,dc=groups,dc=example,dc=com)" attrs="entry,objectclass,uid,cn,displayName,telephoneNumber,ou,mail,memberOf,entryDN" by dn.exact="cn=accessUser,dc=accessUsers,dc=example,dc=com" read by * break
During migration to OpenLDAP 2.5 we eliminated the overlay 'memberOf' and replaced it's functionality by the overlay 'dynlist'.
As a consequence we experienced that the filter statement in ACL {2} doesn't work any longer in OpenLDAP 2.5.
Result of
ldapsearch -x -W -D "cn=accessUser,dc=accessUsers,dc=example,dc=com" -b "dc=users,dc=example,dc=com" -s sub "(memberOf=cn=group1,dc=groups,dc=example,dc=com)" "entry objectclass uid cn displayName telephoneNumber ou mail memberOf entryDN"
doesn't return any results alhough the group object contains members.
We suppose that it has something to to with memberOf becoming some kind of 'virtual' attribute which may be only calculated when explicitly asked for. (Please correct this assumtion if it's incorrect.)
These are the relevant parts of our configuration in OpenLDAP 2.5:
Frontend:
dn: olcDatabase={-1}frontend,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {-1}frontend
olcAccess: {0}to dn.base="" by * read
olcAccess: {1}to dn.base="cn=subschema" by * read
mdb:
dn: olcDatabase={1}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {1}mdb
olcDbDirectory: /var/symas/openldap-data
olcAccess: {0}to * by self read by anonymous auth by * break
olcAccess: {1}to dn.subtree="dc=example,dc=com" filter="(|(dc=example)(dc=us
ers))" attrs="entry,Objectclass,dc" by dn.exact="cn=accessUser,dc=accessUse
rs,dc=example,dc=com" read by * break
olcAccess: {3}to dn.subtree="dc=users,dc=example,dc=com" filter="(|(dc=examp
le)(dc=users))" attrs="entry,Objectclass,dc" by dn.exact="cn=accessUser,dc=
accessUsers,dc=example,dc=com" read by * break"
olcDbIndex: cn
olcDbIndex: default eq,sub
olcDbIndex: departmentNumber pres,eq,sub
olcDbIndex: displayName
olcDbIndex: entryCSN eq
olcDbIndex: entryUUID eq
olcDbIndex: gidNumber eq
olcDbIndex: givenName
olcDbIndex: host eq
olcDbIndex: inetUserStatus
olcDbIndex: mail eq
olcDbIndex: mailLocalAddress eq
olcDbIndex: member eq
olcDbIndex: memberOf eq
olcDbIndex: memberUid eq
olcDbIndex: objectclass eq
olcDbIndex: sn
olcDbIndex: sudoHost eq,sub
olcDbIndex: sudoUser eq,sub
olcDbIndex: uid
olcDbIndex: uidNumber eq
olcDbIndex: uniqueMember eq
olcDbMaxReaders: 126
olcDbMaxSize: 10000000000
olcReadOnly: FALSE
olcRootDN: cn=manager,dc=example,dc=com
olcRootPW:: <abcd1234>
olcSuffix: dc=example,dc=com
dn: olcOverlay={0}refint,olcDatabase={1}mdb,cn=config
objectClass: olcConfig
objectClass: olcOverlayConfig
objectClass: olcRefintConfig
objectClass: top
olcOverlay: {0}refint
olcRefintAttribute: member
olcRefintNothing: cn=someone,dc=example,dc=com
dn: olcOverlay={1}ppolicy,olcDatabase={1}mdb,cn=config
objectClass: olcConfig
objectClass: olcOverlayConfig
objectClass: olcPPolicyConfig
objectClass: top
olcOverlay: {1}ppolicy
olcPPolicyDefault: cn=passwordDefault,ou=password_policies,ou=configurations
,dc=example,dc=com
olcPPolicyHashCleartext: TRUE
dn: olcOverlay={2}dynlist,olcDatabase={1}mdb,cn=config
objectClass: olcConfig
objectClass: olcDynListConfig
objectClass: olcOverlayConfig
objectClass: top
olcOverlay: {2}dynlist
olcDynListAttrSet: {0}groupOfURLs memberURL member+memberOf@groupOfNames
dn: olcOverlay={3}syncprov,olcDatabase={1}mdb,cn=config
objectClass: olcSyncProvConfig
olcOverlay: {3}syncprov
olcSpCheckpoint: 10 1
olcSpSessionlog: 20000
dn: olcOverlay={4}dds,olcDatabase={1}mdb,cn=config
objectClass: olcDDSConfig
objectClass: olcOverlayConfig
olcOverlay: {4}dds
olcDDSinterval: 1h
olcDDSmaxTtl: 10d
olcDDSminTtl: 10s
olcDDSstate: TRUE
olcDDStolerance: 5s
dn: olcOverlay={5}otp,olcDatabase={1}mdb,cn=config
objectClass: olcConfig
objectClass: olcOverlayConfig
objectClass: top
olcOverlay: {5}otp
My question now is:
what is the correct ACL configuration/filter statement to ask for a user's group memberships to achieve our goal in OpenLDAP 2.5?
Any help would be greatly appreciated!
--Carsten
3 months, 3 weeks
Feature Request: slapd: expose SASL EXTERNAL identity to olcAccess rules
by Sean Gallagher
Hi All,
This is loosely related to issue 10065
https://bugs.openldap.org/show_bug.cgi?id=10065, but can be read
independently.
I have devised a work-around to slapd's inability to check client names
on Client certificates and am in the process of removing a proxy
(haproxy) I had in front of my slapd server. I have however come across
an annoying compromise and I'm offering here a suggestion on how to
remove it.
In particular, with the proxy, I could write rules targeting particular
clients that worked, even before their initial "bind" operation by using
the "sockname=" pattern in the access control rules. This does not seem
possible when slapd talks directly to the clients. before the initial
"bind" operation, only the IP address is available to tell clients
apart, which are not very reliable. IP addresses are easily spoofed.
It would be much better to use the client certificate to match against
the particular client. Currently the client ID on the certificate is
passed to the SASL layer with the
sasl_setprop(...,SASL_AUTH_EXTERNAL,...) call. There it remains until
the client performs a "bind" using the SASL EXTERNAL mechanism. At this
point, the EXTERNAL client ID is used to derive a distinguished name by
filtering it through the "olcAuthzRegexp". It should be noted that LDAP
v3 does not require the client to perform such a bind operation.
My Proposal is to expose the EXTERNAL identity to the ACL rules in a
similar way to how the "real" prefix exposes the authentication identity
- by creating an "external" prefix.
As such, the matching rules
externalanonymous
externalusers
externalself
externaldn
externaldnattr
Could be used to restrict access to clients, even before or without a
bind operation.
To maintain naming consistency, The name passed to SASL could have the
"olcAuthzRegexp" mapping applied before the ACL rule is applied. In this
case, the "external" identity would be the same as the unprefixed
identity, after a bind using SASL EXTERNAL mechanism had occured.
This arrangement would have several advantages including:
*) only exposing the userPassword to the particular client that needs it.
*) enforcing client/IP address associations in a rigorous manner.
*) general ACL rules for operations that do not need a "bind" operation.
*) restricting SIMPLE binds to particular clients.
Any Thoughts ?
--
This email has been checked for viruses by AVG antivirus software.
www.avg.com
3 months, 4 weeks
updating from el7 to alpine openldap 2.6
by Marc
I am updating my ldap container and migrate from el7 to alpine. While running some test queries I noticed that the new 2.6 alpine has probably different defaults, I am getting "Size limit exceeded (4)". However this does not show in the ldap error log.
What would be good loglevel config to see quickly if there is an issue with client queries? I am a little worried that if MTA's are getting incomplete results and dropping mail.
3 months, 4 weeks
OpenLDAP with DANE
by John Scott
Hello,
Thanks to the TLS callback support, I discovered that using DANE with libldap is actually really easy. OpenSSL has DANE support built-in, so all you have to do is turn it on and get the DNS records. As a proof-of-concept, I've written an example that disables the use of certificate authorities and uses DANE alone, in accordance with their preference in the TLSA record, to connect to Debian's LDAP instance.
Note that Debian currently uses GnuTLS for OpenLDAP which has, in my opinion, not so good DANE support, so this code won't work. I'm offering my help to the Debian maintainers though to change that.
Code is at https://salsa.debian.org/-/snippets/649
4 months
lmdb and alignment clarification
by bach＠bullno1.com
I have read a few threads on lmdb alignment but I am still not clear on what kind of padding should be done.
Use case: I want to store aligned SIMD vectors in the value and operate on them directly with SIMD instructions without copying.
As I understand it, lmdb guarantees 2-byte alignment.
However, it can also move nodes around for tree rebalancing or page reclaiming.
Thus, merely aligning the key and value might not be enough.
Right now, based on my reading of the code, I'm assuming that the data layout in a leaf page is like this:
[page_header][mp_ptrs]...[node_header][key][value][node_header][key][value]
Basically, nodes are stored contiguously in memory with `node_header` and `key` always aligned to 2-byte.
New nodes are allocated from the bottom of the page and offsets are stored/allocated into MDB_page.mp_ptrs from the top.
Is this correct?
If so, to ensure that `value` has a certain alignment, even when accounting for nodes being moved around, one would also have to ensure that `sizeof(node_header) + sizeof(key) + sizeof(value)` is a multiple of the alignment.
Is this reasoning correct?
For the overflow page, is the structure similar? Just that one single page header is used for a number of contiguous pages.
4 months
Slapd migrate from hdb to lmdb on 2.5.13
by Richard Rosner
Hi,
I just upgraded our servers from Debian 11 to 12. I'm not sure if this
is an upstream change, but slapd 2.5 on Debian 12 doesn't support the
HDB and BDB backends, so the database needs to be migrated to LMDB.
Unfortunately I neglected to check the backend in use for all instances.
Our main slapd instance already used LMDB, but another instance, that's
just getting a copy of that database through sync replication, was still
using HDB. At first I only noticed an error during upgrade. I found a
guide
(https://sources.debian.org/src/openldap/2.5.13%2Bdfsg-5/debian/slapd.READ...
line 255 following) to do the upgrade to 2.5.x if it fails, which showed
me the error.
lt_dlopenext failed: (back_hdb) file not foundslapadd: could not add
entry dn="cn=module{0},cn=config" (line=16): <olcModuleLoad> handler
exited with 1
Closing DB...
So I followed the setps under "BDB/HDB backends removed: migrating to
LMDB backend". But upon trying to restore the backup again, it just told me
slapadd: could not add entry dn="cn=config" (line=1):
Closing DB...
The first set of lines in cn\=config.ldif reads
dn: cn=config
objectClass: olcGlobal
cn: config
olcArgsFile: /var/run/slapd/slapd.args
olcLogLevel: none
olcPidFile: /var/run/slapd/slapd.pid
olcToolThreads: 1
structuralObjectClass: olcGlobal
entryUUID: 71b384b4-aca9-1032-883a-d9850217023f
creatorsName: cn=config
createTimestamp: 20130908080726Z
entryCSN: 20130908080726.757296Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20130908080726Z
So I'm not sure what it wants to tell me now. I already checked against
the config of the main instance, made a few modifications, but the error
message is the same. Here the modifications:
dn: cn=config
objectClass: olcGlobal
cn: config
olcArgsFile: /var/run/slapd/slapd.args
olcLogLevel: none
olcPidFile: /var/run/slapd/slapd.pid
olcToolThreads: 1
structuralObjectClass: olcGlobal
entryUUID: 71b384b4-aca9-1032-883a-d9850217023f
creatorsName: cn=config
createTimestamp: 20130908080726Z
olcTLSCACertificateFile: /etc/ssl/certs/xyz-chain.pem
olcTLSCertificateFile: /etc/ssl/certs/mail.domain.de.cert.pem
olcTLSCertificateKeyFile: /etc/ssl/private/mail.domain.de.private.pem
entryCSN: 20130908080726.757296Z#000000#000#000000
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=mail
modifyTimestamp: 20130908080726Z
Could anybody tell me what exactly the problem is?
Richard
4 months, 1 week
SASL DIGEST-MD5 users/radius?
by Quanah Gibson-Mount
Hello,
There is work underway for a new release of cyrus-sasl 2.1 series that
offiicially supports OpenSSL 3.0. One issue that has been encountered is
that there is no remaining supported cipher algorithms in the cyrus-sasl
DIGEST-MD5 implementation, which used the historic rc4/des or 3des, when
compiling against OpenSSL3.
The general question for this list is, is there anyone who is still using
the historic SASL DIGEST-MD5 mechanism and would not be able to move to a
secure SASL mechanism such as SCRAM?
Thanks!
--Quanah
4 months, 1 week
slapindex a 60GB mdb in reasonable time
by maud.parratt＠bjss.com
Hi,
I have an openldap instance that I'd like to migrate to arm64, just loading a mdb from an amd64 instance results in all filtered queries returning empty results, which is resolved by running slapindex. I've managed to get this to complete in reasonable time using an arm64 mac and a tmpfs volume to hold a smaller test mdb in memory, but I can't replicate this performance in the cloud and I can't fit the prod mdb into tmpfs and have enough memory to work with left over.
I've noticed that despite setting olcToolThreads high, it only ever pins one CPU, so I wonder if it's the difference in single threaded performance of my m1max mac vs a graviton2 instance?
Is there any way to get slapindexing to use more than one cpu, or are there any other performance improvements you can suggest? I need it to complete within 6 hours maximum to fit into a change window. I'd prefer not to resort to running a parallel instance out of service and then swap the two over if it can be helped.
It doesn't go at a consistent rate, but right now it looks like it'd take 2-3 days to complete. I'm passing -t and -q to slapindex.
I'd appreciate any advice you could give.
4 months, 1 week
