search inconsistencies
by Morgan Jones
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
1 year, 6 months
Disable attribute encryption
by Grant Byers
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
1 year, 6 months
OneWaySync AD to 389ds issue.
by Dhivagar A
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.
1 year, 6 months
Re: Issues with passwordmustchange in a local policy on 389-ds 1.4
by Simon Pichugin
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...
> >> >
> >> > 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.fedoraproje...
> >> >> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
> >>
>
>
1 year, 6 months
Re: Issues with passwordmustchange in a local policy on 389-ds 1.4
by Simon Pichugin
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...
> >
> > 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.fedoraproje...
> >> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
>
1 year, 6 months
389-DS Internal unindexed search
by Ciber dgtnt
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
1 year, 6 months
Issues with passwordmustchange in a local policy on 389-ds 1.4
by Brian Collins
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
1 year, 6 months
389 1.3 vs 1.4, CentOS 7
by Morgan Jones
Hello!
Is it advisable to run 389 1.3 in production?
If not is there a suggested way to install 1.4 in CentOS 7? On first blush to install 389 from source it’s looking like I’m going to need to install libicu from source, the version that ships is an older version:
> checking for ICU... no
> configure: error: Package requirements (icu-i18n >= 60.2) were not met:
>
> Requested 'icu-i18n >= 60.2' but version of icu-i18n is 50.2
thank you,
-morgan
1 year, 6 months
