Openldap (specifically version 2.4) stores transaction history in log files by default in the ldap data directory (so /var/lib/ldap/log.###########). Currently these log files take up a lot of space, are never removed automatically, and grow infinitely. Manual removal for old logs works fine, but I'd like to limit the amount of logs slapd keeps automatically. # MY SCENARIO # I know that these transaction logs are used to recover ldap in case of a catastrophic failure. In my scenario ldap is regularly wiped and populated via a script (this isn't used for system login accounts). Because of this I don't need to concern myself with recovery, in case of a failure it's acceptable to run the script again. On the other hand, the regular wipe/population of ldap includes a lot of transactions, so these transaction logs build up pretty quickly. # LOGROTATE # logrotate has potential here, but if the most recent transaction log is ever removed then slapd will fail to start (it will complain about needing to perform recovery). Because I can't rely on the log names (because slapd keeps many small logs, incrementing the log file number as it goes) I'd like to use the Berkeley DB settings which creates these logs. I can count on the access/creation dates (most recent modify date is the most recent transaction log), but I'd still prefer to use Berkeley if possible. # DB_CONFIG # The settings for the transactions logs are said to be controlled by the Berkeley DB settings in /var/lib/ldap/DB_CONFIG. The example DB_CONFIG that comes with openldap specifies some transaction log settings: set_lg_regionmax 262144 set_lg_bsize 2097152 According to the Oracle documentation on Berkeley: set_lg_regionmax: Set the size of the underlying logging area of the Berkeley DB environment, in bytes. The log region is used to store filenames, and so may need to be increased in size if a large number of files will be opened and registered with the specified Berkeley DB environment's log manager. So this seems to just set the size of the file that tracks the transaction log files. set_lg_bsize: Set the size of the in-memory log buffer, in bytes. This seems to control how much RAM is allotted to the transaction buffer. The log.########### files in the ldap data directory are all 10485760 bytes which seems to correspond closely to set_lg_bsize (10485760 / 5 = 2097152 = set_lg_bsize) though I'm not sure if this is a coincidence. My interpretation of this is that $lg_bsize amount of transaction history is stored in memory at a time. When this limit is exceeded it pushes some of the transaction history to the most recent log file, and creates a new log if the current log reaches a certain size. # DB_LOG_AUTOREMOVE # According to the Berkeley documentation transaction logs can be removed by setting the flag DB_LOG_AUTOREMOVE in the DB_CONFIG. DB_LOG_AUTOREMOVE: If set, Berkeley DB will automatically remove log files that are no longer needed. However when I added this to the DB_CONFIG: set_flags DB_LOG_AUTOREMOVE and restarted slapd I didn't notice a difference. I removed the old transaction logs and ran the ldap population script that I have, and was able to rack up 290MB in transaction logs. It still doesn't seem to be limiting the logs at all. The reason for this may be related to the phrase: that are no longer needed # Actual Question # How does one configure the automatic removal of slapd's transaction logs using the Berkeley DB DB_CONFIG file?

Is it possible to change password for logged in LDAP user using passwd command? I have logged in to server1 using testuser. Trying to change password for itself (testuser) and got the below error. [testuser@server1 ~]$ passwd Changing password for user testuser. (current) LDAP Password: New password: Retype new password: password change failed: Insufficient access passwd: Authentication token manipulation error

I have a bunch of AlmaLinux machines with SSSD configured to allow LDAP auth and it's working fine. We have a very huge LDAP directory and some users got multiple entries following this schema. dn: cn=John Dow,ou=randomgrp,ou=something,o=bla,c=xyz ou: RANDOMGRP uid: jdow@RANDOMGRP uniqueidentifier: 123456 AccredOrder: 3 memberOf: special_group dn: cn=John Dow,ou=primarygrp,ou=somewhere,o=bla,c=xyz ou: PRIMARYGRP uid: jdow uid: jdow@PRIMARYGRP uniqueidentifier: 123456 AccredOrder: 1 memberOf: special_group dn: cn=John Dow,ou=anothergrp,ou=somehow,o=bla,c=xyz ou: ANOTHERGRP uid: jdow@ANOTHERGRP uniqueidentifier: 123456 AccredOrder: 2 memberOf: special_group This is the result of a ldapsearch query filtered with uniqueIdentifier attribute. OU names can be different obviously, depending of the user. The first problem I faced is that LDAP is returning the info of those 3 accounts in random order, letting in sometimes jdow, sometimes jdow@ANOTHERGRP or sometimes jdow@RANDOMGRP. I fixed the problem using this filter in my sssd.conf file ldap_access_filter = (&(memberof=special_group)(accredorder=1)) That only let in users with accredorder set to 1 and it's working fine. The problem I have now is when the system is querying the LDAP for it's own business. Most of the time it's working fine but as the LDAP is randomly returning one of the 3 accounts, the tool running on the machines got sometimes jdow@ANOTHERGRP as an answer for the UID of the connected user when it was jdow one jour before and it messes up the software. I don't know if my explanation is clear but is there a way to filter "automatic" queries the system is making? Like a ldapsearch.conf where I could add default filters? To resume, I need to only get information for account with accredorder attribute set to 1 for all the queries the system would make. Thanks for your help

Ive followed all the steps in https://help.ubuntu.com/community/Postfix/DovecotLDAP but I am getting a > localhost postfix/smtpd: fatal: no SASL authentication > mechanisms in my **/var/log/mail.err** Is there a way to find out more specific root cause? Note: I have verified saslauthd is running properly using **testsaslauthd**. SASLAuthd is running fine. I'm struggling in trying to get deeper logs and exact cause on the postfix-sasl side, since I assume the issue will be there.

I would like to perform ldap queries using an alternate file (which is intended to be used with pam.d and so have the same format as /etc/ldap.conf) I think of using ldapsearch. In the manual, I cannot find any help for this purpose. Is it possible to perform ldap queries using an alternate *conf* file? My /etc/pam.d/myservice use the module pam_ldap with option config=/etc/myservice.ldap.conf.

Since a few time with OpenLDAP 2.6.2 on AlpineLinux 3.15, running the slapcat command generates this warning: Supplying multiple names in a single olcRefintAttribute value is unsupported and will be disallowed in a future version The olcRefintAttribute attribute from the refint overlay has the value memberof member owner. How can I fix this warning? I a migration required?

Background info: Redhat 9.5, openldap-servers.x86_64 2.6.6-3.el9 sudo systemctl status slapd output:

× slapd.service - OpenLDAP Server Daemon
     Loaded: loaded (/usr/lib/systemd/system/slapd.service; enabled; preset: disabled)
     Active: failed (Result: exit-code) since Thu 2025-04-17 15:57:54 UTC; 1h 29min ago
       Docs: man:slapd
             man:slapd-config
             man:slapd-mdb
             file:///usr/share/doc/openldap-servers/guide.html
        CPU: 85ms

Apr 17 15:57:54 machine-name: slapd.service: Failed with result 'exit-code'.
Apr 17 15:57:54 machine-name systemd: Failed to start OpenLDAP Server Daemon.

If I try to start it using sudo systemctl start slapd, I get this result. If I do the second option here, I just get the message that it failed.

Job for slapd.service failed because the control process exited with error code. See "systemctl status slapd.service" and "journalctl -xeu slapd.service" for details.

When I run sudo journalctl -xeu slapd.service, I see the following output:

Apr 21 12:18:40 machine-name systemd: Failed to start OpenLDAP Server Daemon.
░░ Subject: A start job for unit slapd.service has failed
░░ Defined-By: systemd
░░ Support: https://access.redhat.com/support 
░░
░░ A start job for unit slapd.service has finished with a failure.
░░
░░ The job identifier is 83527 and the job result is failed.

Lastly, looking at the var/log messages I see:

Apr 15 16:32:13 mon3-srv-redhat systemd: Failed to acquire watch file descriptor: Permission denied
Apr 16 12:57:02 mon3-srv-redhat systemd: Failed to acquire watch file descriptor: Permission denied
Apr 16 13:57:03 mon3-srv-redhat systemd: slapd.service: Failed with result 'exit-code'.
Apr 16 13:57:03 mon3-srv-redhat systemd: Failed to start OpenLDAP Server Daemon.
Apr 16 16:42:51 mon3-srv-redhat systemd: Failed to acquire watch file descriptor: Permission denied
Apr 16 16:50:45 mon3-srv-redhat systemd: slapd.service: Failed with result 'exit-code'.
Apr 16 16:50:45 mon3-srv-redhat systemd: Failed to start OpenLDAP Server Daemon.
Apr 17 13:09:59 mon3-srv-redhat systemd: Failed to acquire watch file descriptor: Permission denied
Apr 17 13:50:02 mon3-srv-redhat systemd: slapd.service: Failed with result 'exit-code'.
Apr 17 13:50:02 mon3-srv-redhat systemd: Failed to start OpenLDAP Server Daemon.
Apr 17 15:57:54 mon3-srv-redhat systemd: slapd.service: Failed with result 'exit-code'.
Apr 17 15:57:54 mon3-srv-redhat systemd: Failed to start OpenLDAP Server Daemon.
Apr 17 16:59:28 mon3-srv-redhat kernel: device-mapper: core: CONFIG_IMA_DISABLE_HTABLE is disabled. Duplicate IMA measurements will not be recorded in the IMA log.
Apr 17 17:00:27 mon3-srv-redhat microcode_ctl: After installation of a new version of microcode_ctl package,
Apr 17 17:00:27 mon3-srv-redhat journal: After installation of a new version of microcode_ctl package,
Apr 17 17:00:27 mon3-srv-redhat journal: initramfs hasn't been re-generated for all the installed kernel packages.
Apr 17 17:00:27 mon3-srv-redhat journal: The following kernel packages have been skipped: kernel-core-5.14.0-503.14.1.el9_5.x86_64.
Apr 17 17:00:27 mon3-srv-redhat journal: Please re-generate initramfs manually for these kernel packages with the
Apr 17 17:00:27 mon3-srv-redhat journal: "dracut -f --kver KERNEL_VERSION" command in order to get the latest
Apr 17 17:00:27 mon3-srv-redhat journal: Intel CPU microcode included into early initramfs image for it, if needed.
Apr 17 17:00:27 mon3-srv-redhat microcode_ctl: initramfs hasn't been re-generated for all the installed kernel packages.
Apr 17 17:00:27 mon3-srv-redhat microcode_ctl: The following kernel packages have been skipped: kernel-core-5.14.0-503.14.1.el9_5.x86_64.
Apr 17 17:00:27 mon3-srv-redhat microcode_ctl: Please re-generate initramfs manually for these kernel packages with the
Apr 17 17:00:27 mon3-srv-redhat microcode_ctl: "dracut -f --kver KERNEL_VERSION" command in order to get the latest
Apr 17 17:00:27 mon3-srv-redhat microcode_ctl: Intel CPU microcode included into early initramfs image for it, if needed.
Apr 17 17:00:27 mon3-srv-redhat systemd-journald: Journal stopped
Apr 17 17:00:27 mon3-srv-redhat systemd-journald: Journal started
Apr 17 17:00:27 mon3-srv-redhat systemd-journald: System Journal (/var/log/journal/425aebe6dda3c33d23239b2a67473698) is 19.6M, max 4.0G, 3.9G free.
Apr 17 17:28:21 mon3-srv-redhat systemd: slapd.service: Failed with result 'exit-code'.
Apr 17 17:28:21 mon3-srv-redhat systemd: Failed to start OpenLDAP Server Daemon.

I have configured my openldap server in ldaps mode. But after configuring I am not able to connect it on 636 port where as I am able to connect on 389 port [root@testldap certs]# ldapsearch -x -LLL -h testldap.india.airwave.com -p 636 -D cn=Manager,dc=india,dc=airwave,dc=com -w whopee -b "ou=Users,dc=india,dc=airwave,dc=com" ldap_result: Can't contact LDAP server (-1) [root@testldap certs]# ldapsearch -x -LLL -h testldap.india.airwave.com -p 389 -D cn=Manager,dc=india,dc=airwave,dc=com -w whopee -b "ou=Users,dc=india,dc=airwave,dc=com" dn: ou=users,dc=india,dc=airwave,dc=com objectClass: organizationalUnit ou: users dn: cn=Sandeep Lade,ou=users,dc=india,dc=airwave,dc=com cn: Sandeep Lade sn: Lade objectClass: inetOrgPerson userPassword:: d2hvcGVl uid: vlade dn: cn=Engineering,ou=users,dc=india,dc=airwave,dc=com cn: Engineering objectClass: groupOfNames member: cn=Sandeep Lade,ou=users,dc=india,dc=airwave,dc=com Both 389 and 636 are listening [root@testldap certs]# netstat -an | grep 389 tcp 0 0 0.0.0.0:389 0.0.0.0:* LISTEN tcp 0 0 :::389 :::* LISTEN unix 2 [ ] DGRAM 19389 [root@testldap certs]# netstat -an | grep 636 tcp 0 0 0.0.0.0:636 0.0.0.0:* LISTEN tcp 0 0 :::636 :::* LISTEN unix 3 [ ] STREAM CONNECTED 13636 [root@testldap certs]# Able to connect to 636 port using openssl connect [root@localhost sandeeplade]# openssl s_client -connect 10.22.156.157:636 -showcerts -CAfile cacert.pem CONNECTED(00000003) write:errno=104 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 307 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None Start Time: 1516769274 Timeout : 300 (sec) Verify return code: 0 (ok) --- [root@localhost sandeeplade]# ldap.conf file [root@testldap certs]# cat /etc/openldap/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 PORT 636 #TLS_CACERTDIR /etc/openldap/certs TLS_CACERTDIR /etc/openldap/certs TLS_REQCERT allow ssl start_tls tls_checkpeer yes tls_cacertfile /etc/openldap/certs/cacert.pem [root@testldap certs]# slapd.conf file [root@testldap certs]# cat /etc/openldap/slapd.conf TLSCACertificateFile /etc/openldap/certs/cacert.pem TLSCertificateFile /etc/openldap/certs/server.crt TLSCertificateKeyFile /etc/openldap/certs/server.key # Use the following if client authentication is required #TLSVerifyClient demand # ... or not desired at all TLSVerifyClient never [root@testldap certs]# certificates are available in /etc/openldap/certs and they are generated using openssl [root@testldap certs]# cd /etc/openldap/certs/ [root@testldap certs]# ls -lrt total 96 -r--------. 1 root root 45 Jan 23 21:59 password -rw-r--r--. 1 root root 16384 Jan 23 21:59 secmod.db -rw-r--r--. 1 root root 65536 Jan 23 21:59 cert8.db -rw-r--r--. 1 root root 16384 Jan 23 21:59 key3.db -rw-------. 1 ldap ldap 1743 Jan 23 23:57 server.key.pass -rw-r--r--. 1 root root 1094 Jan 23 23:59 server.csr -rw-r--r--. 1 root root 4718 Jan 24 00:02 server.crt -rw-r--r--. 1 root root 1675 Jan 24 00:38 server.key -rw-r--r--. 1 root root 4537 Jan 24 05:18 cacert.pem [root@testldap certs]# ldaps enabled in /etc/sysconfig/ldap [root@testldap certs]# cat /etc/sysconfig/ldap # Options of slapd (see man slapd) #SLAPD_OPTIONS= # At least one of SLAPD_LDAP, SLAPD_LDAPI and SLAPD_LDAPS must be set to 'yes'! # # Run slapd with -h "... ldap:/// ..." # yes/no, default: yes SLAPD_LDAP=yes # Run slapd with -h "... ldapi:/// ..." # yes/no, default: yes SLAPD_LDAPI=yes # Run slapd with -h "... ldaps:/// ..." # yes/no, default: no SLAPD_LDAPS=yes # Run slapd with -h "... $SLAPD_URLS ..." # This option could be used instead of previous three ones, but: # - it doesn't overwrite settings of $SLAPD_LDAP, $SLAPD_LDAPS and $SLAPD_LDAPI options # - it isn't overwritten by settings of $SLAPD_LDAP, $SLAPD_LDAPS and $SLAPD_LDAPI options # example: SLAPD_URLS="ldapi:///var/lib/ldap_root/ldapi ldapi:/// ldaps:///" # default: empty #SLAPD_URLS="" # Maximum allowed time to wait for slapd shutdown on 'service ldap stop' (in seconds) #SLAPD_SHUTDOWN_TIMEOUT=3 # Parameters to ulimit, use to change system limits for slapd #SLAPD_ULIMIT_SETTINGS="" [root@testldap certs]# I am struggling to get the openldap worked from past two days. Any help is highly appreciated

For a test, I created a testing password policy for OpenLDAP 2.4, and when a user with an expired password logs in, they get a message like: > Your password has expired. You have 2 grace login(s) remaining. However the user was not able to change the password using passwd with sssd being the LDAP client. As it turned out, the number of grace logins after user log-in was only "one left", and that one was not enough to change the password; it seems that either passwd or sssd need **two** grace logins to change the password. However when using the classic (PAM) LDAP client, the user was able to change the password. Is that correct, and can anybody explain?

I have the following ldapsearch: root@debian:~/ldif# ldapsearch -LLLQ -Y EXTERNAL -H ldapi:/// -b dc=nodomain -D cn=admin,dc=nodomain,cn=Pahlevanzadeh,ou=People,uid=mohsen,loginShell=/usr/bin/csh dn: dc=nodomain objectClass: top objectClass: dcObject objectClass: organization o: nodomain dc: nodomain dn: ou=People,dc=nodomain objectClass: organizationalUnit ou: People description: Organizational Unit for Sales Department dn: uid=mohsen,ou=People,dc=nodomain uid: mohsen cn: Pahlevanzadeh objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount shadowLastChange: 20121 loginShell: /usr/sbin/csh uidNumber: 130 gidNumber: 137 homeDirectory: /home/mohsen gecos: A good boy,,, But when I using the following ldapsearch, I don't have above result: root@debian:~/ldif# ldapsearch -Y EXTERNAL -H ldapi:/// -b dc=nodomain,cn=Pahlevanzadeh -D cn=admin,dc=nodomain,cn=Pahlevanzadeh SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # search result search: 2 result: 32 No such object # numResponses: 1 How can I create query with '-b' that I have the first result?

I am trying to configure ldap.conf for openldap. I am trying to do simple authentication like you can do with the -x in the ldapsearch command. We currently have a script that uses a complex ldapsearch command and we want to default many of the configuration settings in the ldap.conf file. We can't seem to find an alternative to -x. Our config is currently set for URI and BASE which when we do an ldapsearch with the -x option works correctly. However we want any client applications that use the ldap.conf config file to use simple authentication and so we cannot rely on the -x all the time. Is there a way to specify this in ldap.conf file? Currently when we run the command without the -x we get the following error: ldap_sasl_interactive_bind_s: Unknown authentication method (-6) additional info: SASL(-4): no mechanism available: No worthy mechs found

I have the two OU: 1.People 2.newOU . My dc is nodomain. I have the following search and every thing is ok: root@debian:~/ldif# ldapsearch -c -Y EXTERNAL -H ldapi:/// -b dc=nodomain -D cn=admin,dc=nodomain -LLLQ dn: dc=nodomain objectClass: top objectClass: dcObject objectClass: organization o: nodomain dc: nodomain dn: uid=mohsen,ou=People,dc=nodomain uid: mohsen cn: Pahlevanzadeh objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount shadowLastChange: 20121 loginShell: /usr/sbin/csh uidNumber: 130 gidNumber: 137 homeDirectory: /home/mohsen gecos: A good boy,,, dn: ou=newOU,dc=nodomain objectClass: organizationalUnit ou: newOU description: Organizational Unit for Sales Department dn: uid=naghmeh,ou=newOU,dc=nodomain uid: naghmeh cn: maleki objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount shadowLastChange: 20121 loginShell: /usr/sbin/csh uidNumber: 130 gidNumber: 137 homeDirectory: /home/mohsen gecos: A good boy,,, I have two uid: 1.mohsen under People. 2. naghmeh under newOU
When I search suc as above, but add "ou=newOU" such as below: ldapsearch -c -Y EXTERNAL "ou=newOU" -H ldapi:/// -b dc=nodomain -D cn=admin,dc=nodomain -LLLQ I get the following result: dn: ou=newOU,dc=nodomain objectClass: organizationalUnit ou: newOU description: Organizational Unit for Sales Department Unfortunately , I didn't get uid and other information.
How can I access to other info via my OU ?

I have successfully added the recipe openldap to my yocto-base Linux distribution, by the instruction:

IMAGE_INSTALL += "openldap"

After that I've created a path/to/my-layer/recipes-support/openldap/openldap_%.bbappend file and put in it the instruction:

INSANE_SKIP_${PN} += "already-stripped"

The previous setting specifies to the Quality Assurance (QA) checks what to skip and in this case (see [Yocto manual](https://docs.yoctoproject.org/1.8/ref-manual/ref-manual.html#ref-classes-insane) about insane.bbclass) we ask to skip: > **already-stripped**: Checks that produced binaries have not already been stripped prior to the build system extracting debug symbols. It is common for upstream software projects to default to stripping debug symbols for output binaries. In order for debugging to work on the target using -dbg packages, this stripping must be disabled. Without the previous instruction the compilation of openldap fails with this error:

ERROR: openldap-2.4.50-r0 do_package: QA Issue: File '/usr/bin/ldapcompare' from openldap was already stripped, this will prevent future debugging! [already-stripped]
ERROR: openldap-2.4.50-r0 do_package: QA Issue: File '/usr/bin/ldapdelete' from openldap was already stripped, this will prevent future debugging! [already-stripped]
ERROR: openldap-2.4.50-r0 do_package: QA Issue: File '/usr/bin/ldapexop' from openldap was already stripped, this will prevent future debugging! [already-stripped]
ERROR: openldap-2.4.50-r0 do_package: QA Issue: File '/usr/bin/ldapmodify' from openldap was already stripped, this will prevent future debugging! [already-stripped]
ERROR: openldap-2.4.50-r0 do_package: QA Issue: File '/usr/bin/ldapmodrdn' from openldap was already stripped, this will prevent future debugging! [already-stripped]
ERROR: openldap-2.4.50-r0 do_package: QA Issue: File '/usr/bin/ldappasswd' from openldap was already stripped, this will prevent future debugging! [already-stripped]
ERROR: openldap-2.4.50-r0 do_package: QA Issue: File '/usr/bin/ldapsearch' from openldap was already stripped, this will prevent future debugging! [already-stripped]
ERROR: openldap-2.4.50-r0 do_package: QA Issue: File '/usr/bin/ldapurl' from openldap was already stripped, this will prevent future debugging! [already-stripped]
ERROR: openldap-2.4.50-r0 do_package: QA Issue: File '/usr/bin/ldapwhoami' from openldap was already stripped, this will prevent future debugging! [already-stripped]
ERROR: openldap-2.4.50-r0 do_package: QA Issue: File '/usr/sbin/slapd' from openldap was already stripped, this will prevent future debugging! [already-stripped]
ERROR: openldap-2.4.50-r0 do_package: Fatal QA errors found, failing task.

The compilation process produces the binary for the utility ldapsearch but this binary isn't installed into the image. Instead I'm sure that openldap results correctly installed into the distribution. I don't find any method to add ldapsearch (and other utilities correctly compiled) to the image. Could someone help me?

**Information:**
I installed ldap-utils and slapd, during installation of slapd, with ncurses dialog, I imported password of administrator.
Then I changed it via ldapmodify -Q -Y EXTERNAL -H ldapi:/// How can I authenticate via ldap programs? **UPDATE:**
root@debian:~# cat /etc/ldap/slapd.d/cn\=config/olcDatabase\=\{1\}mdb.ldif # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 73bfb3a8 dn: olcDatabase={1}mdb objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=nodomain olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * none olcAccess: {1}to attrs=shadowLastChange by self write by * read olcAccess: {2}to * by * read olcLastMod: TRUE olcRootDN: cn=admin,dc=nodomain olcDbCheckpoint: 512 30 olcDbIndex: objectClass eq olcDbIndex: cn,uid eq olcDbIndex: uidNumber,gidNumber eq olcDbIndex: member,memberUid eq olcDbMaxSize: 1073741824 structuralObjectClass: olcMdbConfig entryUUID: 10bd0d0a-82d1-103f-92a4-058be6d2a441 creatorsName: cn=admin,cn=config createTimestamp: 20250219054944Z olcRootPW:: MTIzMTIzMTIz entryCSN: 20250219060430.002303Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20250219060430Z

I have users in OpenLDAP server. They are manually managed. dn: cn=alice,ou=contoso,dc=combined,dc=internal mail: alice@contoso.com dn: cn=bob,ou=fabrikam,dc=combined,dc=internal mail: bob@fabrikam.com It's DN says that user is from company fabrikam or contoso. When user makes simple bind to OpenLDAP server, I want OpenLDAP to * select backend server for this user based on his DN: * * ou=contoso,... => backend ldap server is 192.168.1.11 * * ou=fabrikam,... => backend ldap server is 192.168.1.12 * search for user within backend server by mail attribute: (&(mail={orig.mail})(objectClass=user)) to get DN of this user from backend server (back_dn) * try to bind as back_dn to backend server using password provided by user and return success or error I can't find any working example of this, or even something around it, please, help me...

What I have are a large number of servers (all FreeBSD). I need to build a common user access management for it (as new developers are joining, want to add their access details on 1 server, and no where else). I am thinking (like LDAP) that there is a common server where I have a user access management system (like LDAP). When a new user who has not yet logged in on a server, comes to login, and that point the system on which the users wants to login, checks in the common user access system, and does the authentication, and then allows the user to login. Features needed: 1. Support of public/private key for login (to be controlled/validated by the common user access system) 2. Support of 2FA (Google Authenticator) (to be controlled/validated by the common user access system) 3. Access to a user, to be controlled at 2 level. 1. User does not exist in the common server → login attempt to be failed. 2. User exists, but does not have login rights to a particular → login attempt on the blocked server to be failed. 4. If I create a new server, without me personally going and adding all the users, the user authentication should work from the common server (even their directory creation should be automatic, somehow) 5. If I add a new user to the common server then that user should be able to login to any of the servers. Please suggest how do I go about. I am trying to setup OpenLDAP but not able to as no proper step by step guide present for the same. Any other suggestion is also welcomed. I have listed down my requirement, would like to see this fulfilled in one way or other. I have tried to setup OpenLDAP client in FreeBSD with OpenLDAP Docker image (setup on a Ubuntu server, as Docker has some more limitations to be run on FreeBSD) as the common server, but no guide found for step by step process. Also I did not find any guide on adding the 2FA to be a part of OpenLDAP.

How to get my ldap/pam/nss stack to accept usernames beginning with a number? I am installing LDAP/NSS/PAM with the instructions provided by debian . I have tried both libnss-ldap, and libnss-ldapd They both work...as long as a user's username does not start with a number (or in libnss-ldap case, usernames also can't have a period in them). Unfortunately, all of the usernames in my organization are seven digit numbers! Here is the error when trying to log in with username 9999999: ...gdm-password]: pam_unix(gdm-password:session): session opened for user 9999999 by (uid=0) ...gdm-password]: pam_systemd(gdm-password:session): Failed to get user record: Invalid argument Where as here are the same logs when trying to log in with the username test ...gdm-password]: pam_unix(gdm-password:session): session opened for user test by (uid=0) I am using the version of the libnss-ldap package that is installed with Ubuntu 20.04, which is version 0.9.11-1

I have created an LDAP (OpenLDAP and LAM) server with a structure, I solved the remote configuration of using sudo. I configured the client stations (will be exclusively Linux Ubuntu) to use LDAP with SSSD and the connections are encrypted (ldaps). Now I need to resolve remote shared home directories for users that are created in the LDAP database. A sufficiently large disk with set appropriate quotas is connected to the server where the LDAP server is running. The user from the client PC logs into the system after successful authentication using LDAP and SSSD. At this point I would need to: - After logging in via SSSD and LDAP, the user gets access to his remote home directory (on the server where LDAP is running). - The remote directory will be automatically mounted to /home/user_name-from_LDAP after login. I have read several tutorials, how-to's and tried deploying Samba. However, many instructions are outdated, incomplete and often focus only on a certain part. I'm just a beginner in LDAP, Samba, Kerberos. With Samba, I read about a problem with connecting Samba-LDAP user databases, where maintaining and managing users is difficult. I ran into this problem when trying to configure and also failed to connect Samba to LDAPS with constant errors with TLS, while all test steps with ldapsearch and openssl went OK. I also read about the possibility of using Kerberos in addition to LDAP and Samba. Compatibility with Windows clients was also often addressed, which will not be my case. I'm honestly confused and I'm looking for the most efficient, easiest to manage, and easiest to implement solution with some clear instructions. So my question is: What alternative choose for using remote home directories please? So that LDAP is used, the user database is created in OpenLDAP and the client stations will be Linux Ubuntu operating systems with SSSD only. The goal is also to automatically mount remote home directories after client login. Thanks for all advices and guidance.

I'm looking for a way to create an empty LDAP dictionary with the rfc2307bis schema. On Debian when installing slapd or when reconfiguring with dpkg the nis schema is used by default. How do I remove it or replace it with rfc2307bis ? At initialization or after.

I need to decode base64 embedded in ldif (openldap) backups. I found here a way to join lines starting with a blank. Then, based on this question about "How to decode base64 text in xml file in Linux?" I want to decode the base64 strings, but I'm not being able to get it to work. My Script is: #Join lines starting with space sed -n 'H; ${ x; s/\n//; s/\n //g; p}' "$FILE" > "$FILE_JOINED" #Decode lines containing base64 (those with double colon) sed -r 's/(:: )([[:graph:]]+)/\1 '"grep -oP ':: [[:graph:]]+' "$FILE_JOINED" |cut -c 4- | base64 -d"'/g' "$FILE_JOINED" When I execute this, I get the following error: sed: -e expression #1, char 297: unknown option to `s' Here I add an example of the "$FILE_JOINED" contents: dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=proxy,dc=ldap olcAccess:: b25lIHZhbHVlCg== olcAccess: {1}to filter=(&(objectClass=securityPrincipal)(!(pwdAccountLockedTime=*))) attrs=userPassword,shadowLastChange by dn="cn=Man1,ou=local,dc=proxy,dc=ldap" write by anonymous auth by self write by * none olcAccess: {2} to * by * read olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=Man1,ou=local,dc=proxy,dc=ldap olcRootPW:: dmFsdWUgdHdvCg== olcSyncUseSubentry: FALSE olcSyncrepl:: dmFsdWUgdGhyZWUK olcMirrorMode: TRUE dn: olcOverlay={0}unique,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcUniqueConfig (NOTE that the second command leaves the double colon (::) instead of leaving only one. I did it on purpose to be able to easily grep the output. I'll fix that later) The second command has a grep in it: How does it "select" the correct line to decode in all the file contents? Here is the result of the grep command alone: # grep -oP ':: [[:graph:]]+' x |cut -c 4- | base64 -d one value value two value three Could anybody please give me any pointers on how to decode the base64 values contained in a ldif file?