I’ve run into an interesting situatuion with the sudoers tree in 389-ds. All the nodes in the 389-ds cluster have it, but one doesn’t. I’ve tried dumping the database on a good node with db2ldif and reloading on the bad node with ldif2db, but the situation is not changing. I’ve also tried db2index on the bad node without much luck.
If memory serves correctly ... there are some un-resolved issues between dirsrv-admin + fips. I remember discussing this with Mark as something that may fall into the "fix when someone runs into it" because that combination we thought would be rare.
But I'm not sure that this issue here is a fips one? I've seen another issue lately where the dirsrv-admin used a different pin.txt to the dirsrvinstances, but I'm not sure of the details.
Are there fresh installs of ds? Or upgrades?
> On 28 Aug 2019, at 05:51, Paul Whitney <paul.whitney(a)chesapeake-it.com> wrote:
> Hi guys,
> I have SSL enabled both slapd instances and dirsrv-admin on FIPS enabled CentOS 7. The instances seem to start up no problem. However, the admin console (dirsrv-admin) is complaining the password credentials are not valid for the NSS FIPS 140-2 DB even through the exact same credentials are presented to the SLAPD instances. I am using a pin.txt file in the correct format for both SLAPD and DIRSRV-ADMIN.
> Are there compatibility issues with FIPS and 389-DS admin-serv?
> Paul M. Whitney
> 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://firstname.lastname@example.org...
Senior Software Engineer, 389 Directory Server
I need a little help with two topics:
1. users should be able to use a simple web frontend to change ldap
password and manage ssh pubkeys.
We evaluated Fusion Directory (https://www.fusiondirectory.org/) for this.
In Fusion Directory group membership is using groupofnames rather than
groupofuniquenames used in 389. I played around but can't find a
solution to fix this. I tried to modify
preferences,ou=genua.de,o=netscaperoot -> nsDefaultObjectClass from
groupofuniquenames to groupofnames
but in 389-console it shows me message: uniqueMember is not allowed.
Is it possible to change the default object class of the group? How to
to do it?
Otherwise could you point me to a simple webgui to edit values?
2. When creating a user object under I want to trigger some post actions
(create directories, copy files, etc.)
As I understand this should be possible with the plugins. I'm asking
myself if there's already such a plugin or could you provide me some
Thanks in advance,
On 9/5/19, 18:11, "Iain Morgan" <Iain.Morgan(a)nasa.gov> wrote:
While testing 389-ds 184.108.40.206 on RHEL 7.7, I noticed the the errors
listed below. The actual LDAP operations all succeed, but I find the
[28/Aug/2019:10:42:13.446609256 -0700] - ERR - conn=44 op=5 - urp_fixup_add_cenotaph - failed to add cenotaph, err= 21
[28/Aug/2019:10:42:14.202854398 -0700] - ERR - conn=52 op=5 - urp_fixup_add_cenotaph - failed to add cenotaph, err= 21
[28/Aug/2019:10:42:18.504412946 -0700] - ERR - conn=95 op=3 - urp_fixup_add_cenotaph - failed to add cenotaph, err= 21
[28/Aug/2019:10:42:24.412896470 -0700] - ERR - conn=160 op=8 - urp_fixup_add_cenotaph - failed to add cenotaph, err= 21
These all appear to be related to modrdn operations.
I'm back on this topic,
Can you tell me with the docker image how to create the root suffix ?
I tried this step but othing appears on Apache Directory server IDE
ldapmodify -a -D "cn=Directory manager" -w mypass -p 3389 -h 10.109.139.63
dn: cn="dc=domain,dc=net",cn=mapping tree,cn=config
How can I sync account state from Windows AD to 389ds
1. account disabled
2. account lockout
3. password expired
I want to sync these attributes from Windows AD to 389ds, would you please tell me? Thanks in advance.