389-users November 2021

389-users@lists.fedoraproject.org

13 participants
13 discussions

ERR - slapi_ldap_bind - Could not send bind request for id [(anon)] authentication mechanism [EXTERNAL]: error -1 (Can't contact LDAP server), system error 0 (no error), network error 0
by Graham Leggett 11 Dec '23

11 Dec '23

Hi all, We have a long standing 389ds master LDAP server that was found to be unable to contact it’s slaves. Most specifically, the slaves show nothing in their logs about any kind of connection, while the master is logging this: [12/Nov/2019:21:39:47.212715697 +0000] - ERR - slapi_ldap_bind - Could not send bind request for id [(anon)] authentication mechanism [EXTERNAL]: error -1 (Can't contact LDAP server), system error 0 (no error), network error 0 (Unknown error, host “ldap01:636”) Key is "system error 0 (no error)”, which leaves us stumped. The error is obviously “success”. Has anyone seen this kind of thing before? This is 389ds running on CentOS7 as follows: 389-ds-base-1.3.9.1-10.el7.x86_64 Regards, Graham —

3 9

Plugin development licensing
by DUVERT Vincent 09 May '23

09 May '23

Hello, I have a question regarding the licensing of developed 389-ds plugins. The FAQ (https://directory.fedoraproject.org/docs/389ds/FAQ/licensing.html#directory…) indicates that the Directory Server core code is licensed under a GPL + Exception license that allows non-GPL 389-ds plugins to link to 389-ds and to use specific header files. However, the LICENSE file in the current 389-ds-base source does not contain this exception. It was apparently removed by the following commit, when the license was changed to GPLv3+: https://pagure.io/389-ds-base/c/88cae401aee39a19ac6b07c3c36ee8daa07192e7 Does that means that the license exception does not apply to the current version of 389-ds? Regards, Vincent Duvert

2 2

search inconsistencies
by Morgan Jones 30 Nov '21

30 Nov '21

Can anyone provide insight on why the below might be happening, my best guess is a corrupt uniquemember index?? I initially tried it as a user which also fails but switched to Directory Manager to rule out an access control issue. We have identical prod, dev, and test environments and I only see this behavior in our production environment. mmacbook:~ morgan$ ldapsearch -LLL -H ldaps://prdds22.domain.org -x -y pass -D cn=directory\ manager -b 'cn=admin,ou=fwmgmt,ou=groups,dc=domain,dc=org' '(&(objectClass=groupofuniquenames)(uniqueMember=*))' mmacbook:~ morgan$ ldapsearch -LLL -H ldaps://prdds22.domain.org -x -y pass -D cn=directory\ manager -b 'cn=admin,ou=fwmgmt,ou=groups,dc=domain,dc=org' '(uniqueMember= groupofuniquenames)' mmacbook:~ morgan$ ldapsearch -LLL -H ldaps://prdds22.domain.org -x -y pass -D cn=directory\ manager -b 'cn=admin,ou=fwmgmt,ou=groups,dc=domain,dc=org' '(objectclass=*)' dn: cn=admin,ou=fwmgmt,ou=groups,dc=domain,dc=org objectClass: top objectClass: groupOfUniqueNames cn: admin uniqueMember: uid=u1,ou=employees,dc=domain,dc=org uniqueMember: uid=u2,ou=employees,dc=domain,dc=org uniqueMember: uid=u3,ou=employees,dc=domain,dc=org description: FW Mgmt group mmacbook:~ morgan$ mmacbook:~ morgan$ ldapsearch -x -y ~/Docs/.pass4 -D cn=directory\ manager -LLLb cn=config '(&(objectclass=nsindex)(cn=uniquemember))' dn: cn=uniquemember,cn=default indexes,cn=config,cn=ldbm database,cn=plugins,c n=config objectClass: top objectClass: nsIndex cn: uniquemember nsSystemIndex: false nsIndexType: eq dn: cn=uniquemember,cn=index,cn=NetscapeRoot,cn=ldbm database,cn=plugins,cn=co nfig objectClass: top objectClass: nsIndex cn: uniquemember nsSystemIndex: false nsIndexType: eq dn: cn=uniqueMember,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config cn: uniqueMember objectClass: top objectClass: nsIndex nsIndexType: eq nsIndexType: sub nsIndexType: pres nsSystemIndex: false mmacbook:~ morgan$ thank you! -morgan

2 2

Disable attribute encryption
by Grant Byers 29 Nov '21

29 Nov '21

Hi all, Is there a way to either permanently disable attribute encryption, or to have the symmetric keys generated from an alternate RSA private key to that used for TLS (given by cn=RSA,cn=encryption,cn=config)? I may be missing something, but this seems to be completely tied to TLS. We don't use attribute encryption at all presently, and the process we use for rolling certtificates is basically a re-key. This results in the following error messages; [25/Nov/2021:06:32:33.562508644 +0000] - ERR - attrcrypt_unwrap_key - Failed to unwrap key for cipher AES [25/Nov/2021:06:32:33.564813203 +0000] - ERR - attrcrypt_cipher_init - Symmetric key failed to unwrap with the private key; Cert might have been renewed since the key is wrapped. To recover the encrypted contents, keep the wrapped symmetric key value. [25/Nov/2021:06:32:33.931422579 +0000] - ERR - attrcrypt_unwrap_key - Failed to unwrap key for cipher 3DES [25/Nov/2021:06:32:33.935241033 +0000] - ERR - attrcrypt_cipher_init - Symmetric key failed to unwrap with the private key; Cert might have been renewed since the key is wrapped. To recover the encrypted contents, keep the wrapped symmetric key value. [25/Nov/2021:06:32:33.937228742 +0000] - ERR - attrcrypt_init - All prepared ciphers are not available. Please disable attribute encryption. I realise we could delete the encrypted attribute keys entries as part of our renewal process & have them regenerated, but that seems pretty hackish. The message implies attribute encryption can be disabled ("Please disable attribute encryption."), yet the only way I see to do this is to disable TLS via nsslapd- security. Can someone confirm? Thanks, Grant

2 3

OneWaySync AD to 389ds issue.
by Dhivagar A 28 Nov '21

28 Nov '21

Hi team, I want to sync user and password from Windows 2019 to 389ds one way sync, I have configured the OnewaySync. But not working. This is the error log for your reference. Error log: WARN - NSMMReplicationPlugin - windows sync - windows_inc_run - agmt="cn=winsync" (172:389): Replica has no update vector. It has never been initialized. ERR - NSMMReplicationPlugin - windows sync - windows_tot_run - Beginning total update of replica "agmt="cn=winsync" (172:389)". ERR - NSMMReplicationPlugin - windows sync - windows_tot_run - Finished total update of replica "agmt="cn=winsync" (172:389)". Sent 0 entries.

3 11

Announcing 389 Directory Server 2.0.11
by Mark Reynolds 22 Nov '21

22 Nov '21

389 Directory Server 2.0.11 The 389 Directory Server team is proud to announce 389-ds-base version 2.0.11 Fedora packages are available on Fedora 34 and Rawhide Rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=79178995 <https://koji.fedoraproject.org/koji/taskinfo?taskID=79178995>- Koji Fedora 35: https://koji.fedoraproject.org/koji/taskinfo?taskID=79181056 <https://koji.fedoraproject.org/koji/taskinfo?taskID=79181056>- Koji https://bodhi.fedoraproject.org/updates/FEDORA-2021-dcccb24c55 <https://bodhi.fedoraproject.org/updates/FEDORA-2021-dcccb24c55>- Bodhi Fedora 34: https://koji.fedoraproject.org/koji/taskinfo?taskID=79181078 <https://koji.fedoraproject.org/koji/taskinfo?taskID=79181078>- Koji https://bodhi.fedoraproject.org/updates/FEDORA-2021-fd5fe50a28 <https://bodhi.fedoraproject.org/updates/FEDORA-2021-fd5fe50a28>- Bodhi The new packages and versions are: * 389-ds-base-2.0.11-1 Source tarballs are available for download atDownload 389-ds-base Source <https://github.com/389ds/389-ds-base/archive/389-ds-base-2.0.11.tar.gz> Highlights in 2.0.11 * Bug fixes * CockpitUI-LDAPeditor (database editor) has been started, but it is far from complete. Please do not file any issues against it yet as it’s a WIP. Installation and Upgrade SeeDownload <https://www.port389.org/docs/389ds/download.html>for information about setting up your yum repositories. To install the server use*dnf install 389-ds-base* To install the CockpitUIplugin use*dnf install cockpit-389-ds* After rpm install completes, run*dscreate interactive* For upgrades, simply install the package. There are no further steps required. There are no upgrade steps besides installing the new rpms SeeInstall_Guide <https://www.port389.org/docs/389ds/howto/howto-install-389.html>for more information about the initial installation and setup SeeSource <https://www.port389.org/docs/389ds/development/source.html>for information about source tarballs andSCM(git) access. Feedback We are very interested in your feedback! Please provide feedback and comments to the 389-users mailing list:https://lists.fedoraproject.org/admin/lists/389-users.lists.fedoraproj… If you find a bug, or would like to see a new feature, file it in our GitHub project:https://github.com/389ds/389-ds-base * Bump version to 2.0.11 * Issue 4962 - Fix variousUIbugs - Settings and Monitor (#5016) * Issue 5014 -UI- Add group creation toLDAP editor * Issue 5006 -UI-LDAPeditor tree not being properly updated * Issue 5001 - UpdateCItest for new availableSASLMechs attribute * Issue 4959 - Invalid /etc/hosts setup can cause isLocalHost to fail. * Issue 5001 - Fix next round ofUI bugs: * Issue 4962 - Fix variousUIbugs - dsctl and ciphers (#5000) * Issue 4978 - use more portable python command for checking containers * Issue 4678 -RFEautomatique disable of virtual attribute checking (#4918) * Issue 4972 - gecos withIA5introduces a compatibility issue with previous (#4981) * Issue 4978 - make installer robust * Issue 4976 - Failure in suites/import/import_test.py::test_fast_slow_import * Issue 4973 - update snmp to use /run/dirsrv forPID file * Issue 4962 - Fix variousUIbugs - Plugins (#4969) * Issue 4973 - installer changes permissions on /run * Issue 4092 - systemd-tmpfiles warnings * Issue 4956 - Automember allows invalid regex, and does not log proper error * Issue 4731 - Promoting/demoting a replica can crash the server * Issue 4962 - Fix variousUIbugs part 1 * Issue 3584 - Fix PBKDF2_SHA256hashing inFIPSmode (#4949) * Issue 4943 - Fix csn generator to limit time skew drift (#4946) * Issue 2790 - Set db home directory by default * Issue 4299 - MergeLDAPeditor code into Cockpit UI * Issue 4938 - max_failure_count can be reached in dscontainer on slow machine with missing debug exception trace * Issue 4921 - logconv.pl -j: Use of uninitialized value (#4922) * Issue 4847 -BUG- potential deadlock in replica (#4936) * Issue 4513 - fixACICItests involving ip/hostname rules * Issue 4925 - PerformanceACI: targetfilter evaluation result can be reused (#4926) * Issue 4916 - Memory leak in ldap-agent -- Directory Server Development Team

1 0

Re: Issues with passwordmustchange in a local policy on 389-ds 1.4
by Simon Pichugin 16 Nov '21

16 Nov '21

On Tue, Nov 16, 2021 at 7:29 AM Brian Collins <rbriancollins(a)gmail.com> wrote: > Hi Simon, > > Yes, that worked! Thanks. > > Feel like I should've caught that one myself. Thanks for the quick > response and help! > Hi Brian, Glad to help! Have fun! :) Simon > > --Brian > > On Tue, Nov 16, 2021 at 9:57 AM Simon Pichugin <spichugi(a)redhat.com> > wrote: > > > > Hi Brian, > > Thank you! > > > > For some reason, you have 'nsslapd-pwpolicy-local: off'. > > If this attribute has a value of off, all entries (except for > cn=Directory Manager) in the directory are subjected to the global password > policy; the server ignores any defined subtree/user level password policy. > > If this attribute has a value of on, the server checks for password > policies at the subtree- and user-level and enforces those policies. > > > > Could you please enable it and try to test your issue again? > > > > Hope that helps, > > Simon > > > > > > On Tue, Nov 16, 2021 at 6:37 AM Brian Collins <rbriancollins(a)gmail.com> > wrote: > >> > >> Sure thing, Simon. I believe the queries I did below gave me what > >> you're requested. Please let me know if you need more information. > >> Thanks! > >> > >> > >> Global: > >> # dsconf -y dirman.txt -D "cn=Directory Manager" pro02 pwpolicy get > >> Global Password Policy: cn=config > >> ------------------------------------ > >> nsslapd-pwpolicy-local: off > >> passwordstoragescheme: PBKDF2_SHA256 > >> passwordchange: on > >> passwordmustchange: off > >> passwordhistory: off > >> passwordinhistory: 6 > >> passwordadmindn: > >> passwordtrackupdatetime: off > >> passwordwarning: 86400 > >> passwordisglobalpolicy: on > >> passwordexp: off > >> passwordmaxage: 8640000 > >> passwordminage: 0 > >> passwordgracelimit: 0 > >> passwordsendexpiringtime: off > >> passwordlockout: off > >> passwordunlock: on > >> passwordlockoutduration: 3600 > >> passwordmaxfailure: 3 > >> passwordresetfailurecount: 600 > >> passwordchecksyntax: off > >> passwordminlength: 8 > >> passwordmindigits: 0 > >> passwordminalphas: 0 > >> passwordminuppers: 0 > >> passwordminlowers: 0 > >> passwordminspecials: 0 > >> passwordmin8bit: 0 > >> passwordmaxrepeats: 0 > >> passwordpalindrome: off > >> passwordmaxsequence: 0 > >> passwordmaxseqsets: 0 > >> passwordmaxclasschars: 0 > >> passwordmincategories: 3 > >> passwordmintokenlength: 3 > >> passwordbadwords: > >> passworduserattributes: > >> passworddictcheck: off > >> passworddictpath: > >> nsslapd-allow-hashed-passwords: off > >> nsslapd-pwpolicy-inherit-global: off > >> > >> Local: > >> # dsconf -y ~/dirman.txt -D "cn=Directory Manager" pro02 localpwp get > >> ou=People,dc=example,dc=com > >> Local User Policy Policy for "ou=People,dc=example,dc=com": > >> > cn=cn\3DnsPwPolicyEntry\2Cou\3DPeople\2Cdc\3Dexample\2Cdc\3Dcom,cn=nsPwPolicyContainer,ou=People,dc=example,dc=com > >> ------------------------------------ > >> passwordstoragescheme: ssha512 > >> passwordchange: on > >> passwordmustchange: on > >> passwordhistory: off > >> passwordadmindn: cn=siteops sa,ou=sa groups,dc=example,dc=com > >> passwordexp: off > >> passwordminage: 0 > >> > >> On Tue, Nov 16, 2021 at 12:36 AM Simon Pichugin <spichugi(a)redhat.com> > wrote: > >> > > >> > Hi Brian, > >> > could you please provide your full Password Policy setup (but global > and local, entries and attributes)? > >> > > >> > Please, check this chapter for the details: > >> > > https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/h… > >> > > >> > Sincerely, > >> > Simon > >> > > >> > On Mon, Nov 15, 2021 at 8:37 AM Brian Collins < > rbriancollins(a)gmail.com> wrote: > >> >> > >> >> Good day all. > >> >> > >> >> We recently updated our 389-ds infrastructure from 1.3.8.4 on RHEL 7 > >> >> to 1.4.4.16, installed via epel-modular, on RHEL 8. > >> >> > >> >> Since that time, it appears that our local password policy setting of > >> >> "pwdmustchange" is not working. If I apply a global policy, it does > >> >> seem to work, but we prefer to keep it as a local policy applied to a > >> >> subtree (ou=People,dc=example,dc=com). > >> >> > >> >> # dsconf -y ~/dirman.txt -D "cn=Directory Manager" pro02 localpwp get > >> >> ou=People,dc=example,dc=com > >> >> > >> >> Local User Policy Policy for "ou=People,dc=example,dc=com": > >> >> > cn=cn\3DnsPwPolicyEntry\2Cou\3DPeople\2Cdc\3Dexample\2Cdc\3Dcom,cn=nsPwPolicyContainer,ou=People,dc=example,dc=com > >> >> ------------------------------------ > >> >> passwordstoragescheme: ssha512 > >> >> passwordchange: on > >> >> passwordmustchange: on > >> >> passwordhistory: off > >> >> passwordadmindn: cn=siteops sa,ou=sa groups,dc=example,dc=com > >> >> passwordexp: off > >> >> passwordminage: 0 > >> >> > >> >> With the above settings, but the global policy for passwordmustchange > >> >> set to "off", an administratively-changed password (done by Directory > >> >> Manager) does not require a change on first login. If I change the > >> >> global policy to on and reset the user's password again, it does > >> >> require a change. > >> >> > >> >> Again, time-wise, this seems to have begun with our move from 1.3 to > >> >> 1.4. To do the upgrade, we introduced 1.4 servers then created > >> >> replication agreements with them. Then we removed the 1.3 servers (I > >> >> hope that was the right way to do it; didn't think much about it at > >> >> the time). > >> >> > >> >> It would not surprise me if I am doing (or have done) something wrong > >> >> here, but I'm unable to pinpoint what. > >> >> > >> >> Thank you in advance, > >> >> Brian > >> >> _______________________________________________ > >> >> 389-users mailing list -- 389-users(a)lists.fedoraproject.org > >> >> To unsubscribe send an email to > 389-users-leave(a)lists.fedoraproject.org > >> >> Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > >> >> List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > >> >> List Archives: > https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject… > >> >> Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > >> > >

1 0

Re: Issues with passwordmustchange in a local policy on 389-ds 1.4
by Simon Pichugin 16 Nov '21

16 Nov '21

Hi Brian, Thank you! For some reason, you have 'nsslapd-pwpolicy-local: off'. If this attribute has a value of off, all entries (except for cn=Directory Manager) in the directory are subjected to the global password policy; the server ignores any defined subtree/user level password policy. If this attribute has a value of on, the server checks for password policies at the subtree- and user-level and enforces those policies. Could you please enable it and try to test your issue again? Hope that helps, Simon On Tue, Nov 16, 2021 at 6:37 AM Brian Collins <rbriancollins(a)gmail.com> wrote: > Sure thing, Simon. I believe the queries I did below gave me what > you're requested. Please let me know if you need more information. > Thanks! > > > Global: > # dsconf -y dirman.txt -D "cn=Directory Manager" pro02 pwpolicy get > Global Password Policy: cn=config > ------------------------------------ > nsslapd-pwpolicy-local: off > passwordstoragescheme: PBKDF2_SHA256 > passwordchange: on > passwordmustchange: off > passwordhistory: off > passwordinhistory: 6 > passwordadmindn: > passwordtrackupdatetime: off > passwordwarning: 86400 > passwordisglobalpolicy: on > passwordexp: off > passwordmaxage: 8640000 > passwordminage: 0 > passwordgracelimit: 0 > passwordsendexpiringtime: off > passwordlockout: off > passwordunlock: on > passwordlockoutduration: 3600 > passwordmaxfailure: 3 > passwordresetfailurecount: 600 > passwordchecksyntax: off > passwordminlength: 8 > passwordmindigits: 0 > passwordminalphas: 0 > passwordminuppers: 0 > passwordminlowers: 0 > passwordminspecials: 0 > passwordmin8bit: 0 > passwordmaxrepeats: 0 > passwordpalindrome: off > passwordmaxsequence: 0 > passwordmaxseqsets: 0 > passwordmaxclasschars: 0 > passwordmincategories: 3 > passwordmintokenlength: 3 > passwordbadwords: > passworduserattributes: > passworddictcheck: off > passworddictpath: > nsslapd-allow-hashed-passwords: off > nsslapd-pwpolicy-inherit-global: off > > Local: > # dsconf -y ~/dirman.txt -D "cn=Directory Manager" pro02 localpwp get > ou=People,dc=example,dc=com > Local User Policy Policy for "ou=People,dc=example,dc=com": > > cn=cn\3DnsPwPolicyEntry\2Cou\3DPeople\2Cdc\3Dexample\2Cdc\3Dcom,cn=nsPwPolicyContainer,ou=People,dc=example,dc=com > ------------------------------------ > passwordstoragescheme: ssha512 > passwordchange: on > passwordmustchange: on > passwordhistory: off > passwordadmindn: cn=siteops sa,ou=sa groups,dc=example,dc=com > passwordexp: off > passwordminage: 0 > > On Tue, Nov 16, 2021 at 12:36 AM Simon Pichugin <spichugi(a)redhat.com> > wrote: > > > > Hi Brian, > > could you please provide your full Password Policy setup (but global and > local, entries and attributes)? > > > > Please, check this chapter for the details: > > > https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/h… > > > > Sincerely, > > Simon > > > > On Mon, Nov 15, 2021 at 8:37 AM Brian Collins <rbriancollins(a)gmail.com> > wrote: > >> > >> Good day all. > >> > >> We recently updated our 389-ds infrastructure from 1.3.8.4 on RHEL 7 > >> to 1.4.4.16, installed via epel-modular, on RHEL 8. > >> > >> Since that time, it appears that our local password policy setting of > >> "pwdmustchange" is not working. If I apply a global policy, it does > >> seem to work, but we prefer to keep it as a local policy applied to a > >> subtree (ou=People,dc=example,dc=com). > >> > >> # dsconf -y ~/dirman.txt -D "cn=Directory Manager" pro02 localpwp get > >> ou=People,dc=example,dc=com > >> > >> Local User Policy Policy for "ou=People,dc=example,dc=com": > >> > cn=cn\3DnsPwPolicyEntry\2Cou\3DPeople\2Cdc\3Dexample\2Cdc\3Dcom,cn=nsPwPolicyContainer,ou=People,dc=example,dc=com > >> ------------------------------------ > >> passwordstoragescheme: ssha512 > >> passwordchange: on > >> passwordmustchange: on > >> passwordhistory: off > >> passwordadmindn: cn=siteops sa,ou=sa groups,dc=example,dc=com > >> passwordexp: off > >> passwordminage: 0 > >> > >> With the above settings, but the global policy for passwordmustchange > >> set to "off", an administratively-changed password (done by Directory > >> Manager) does not require a change on first login. If I change the > >> global policy to on and reset the user's password again, it does > >> require a change. > >> > >> Again, time-wise, this seems to have begun with our move from 1.3 to > >> 1.4. To do the upgrade, we introduced 1.4 servers then created > >> replication agreements with them. Then we removed the 1.3 servers (I > >> hope that was the right way to do it; didn't think much about it at > >> the time). > >> > >> It would not surprise me if I am doing (or have done) something wrong > >> here, but I'm unable to pinpoint what. > >> > >> Thank you in advance, > >> Brian > >> _______________________________________________ > >> 389-users mailing list -- 389-users(a)lists.fedoraproject.org > >> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org > >> Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > >> List Archives: > https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject… > >> Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > >

1 0

389-DS Internal unindexed search
by Ciber dgtnt 15 Nov '21

15 Nov '21

Hi, I have a problem in 389-ds version 1.3.10.2-10 intalled on Centos7 , we have a multimaster enviroment with consumers and suppliers, we have referential integrity plugin to control the group members. In the master node where we have the referential integrity pluggin enabled, ocasionally we get this message in the error log : NOTICE - ldbm_back_search - Internal unindexed search: source (cn=referential integrity postoperation,cn=plugins,cn=config) search base="c=es" scope=2 filter="(member=*uid=dmarmedr,ou=Baja de cuentas,c=es)" conn=0 op=0 NOTICE - ldbm_back_search - Internal unindexed search: source (cn=referential integrity postoperation,cn=plugins,cn=config) search base="c=es" scope=2 filter="(uniquemember=*uid=dmarmedr,ou=Baja de cuentas,c=es)" conn=0 op=0 NOTICE - ldbm_back_search - Internal unindexed search: source (cn=referential integrity postoperation,cn=plugins,cn=config) search base="c=es" scope=2 filter="(owner=*uid=dmarmedr,ou=Baja de cuentas,c=es)" conn=0 op=0 NOTICE - ldbm_back_search - Internal unindexed search: source (cn=referential integrity postoperation,cn=plugins,cn=config) search base="c=es" scope=2 filter="(seeAlso=*uid=dmarmedr,ou=Baja de cuentas,c=es)" conn=0 op=0 And when it happends the slapd proccess takes up to 100% CPU usage and we see the message you can see bellow, because this master node begins to avoid replication sessions from other master nodes: ERR - NSMMReplicationPlugin - process_postop - Failed to apply update (615f51ea000000230000) error (51). Aborting replication session(conn=1145 op=4) All those internal unindexed searchs have filters with the attributes configured in the referential integrity plugin, member=*, uniquemember=*, owner=* and seealso=*. Those attributes has equality and presence indexes, we don't understand why the log says "internal unindexed search". Can anyone help me with this problem?, maby is it necessary other type of index? Thanks & Regards

5 7

Issues with passwordmustchange in a local policy on 389-ds 1.4
by Brian Collins 15 Nov '21

15 Nov '21

Good day all. We recently updated our 389-ds infrastructure from 1.3.8.4 on RHEL 7 to 1.4.4.16, installed via epel-modular, on RHEL 8. Since that time, it appears that our local password policy setting of "pwdmustchange" is not working. If I apply a global policy, it does seem to work, but we prefer to keep it as a local policy applied to a subtree (ou=People,dc=example,dc=com). # dsconf -y ~/dirman.txt -D "cn=Directory Manager" pro02 localpwp get ou=People,dc=example,dc=com Local User Policy Policy for "ou=People,dc=example,dc=com": cn=cn\3DnsPwPolicyEntry\2Cou\3DPeople\2Cdc\3Dexample\2Cdc\3Dcom,cn=nsPwPolicyContainer,ou=People,dc=example,dc=com ------------------------------------ passwordstoragescheme: ssha512 passwordchange: on passwordmustchange: on passwordhistory: off passwordadmindn: cn=siteops sa,ou=sa groups,dc=example,dc=com passwordexp: off passwordminage: 0 With the above settings, but the global policy for passwordmustchange set to "off", an administratively-changed password (done by Directory Manager) does not require a change on first login. If I change the global policy to on and reset the user's password again, it does require a change. Again, time-wise, this seems to have begun with our move from 1.3 to 1.4. To do the upgrade, we introduced 1.4 servers then created replication agreements with them. Then we removed the 1.3 servers (I hope that was the right way to do it; didn't think much about it at the time). It would not surprise me if I am doing (or have done) something wrong here, but I'm unable to pinpoint what. Thank you in advance, Brian

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users November 2021