Hi,
I think we can explain it.
Is it possible that you were running
389-ds-base-1.3.4.0-33.el7_2.x86_64.rpm release ?
>From the string: 389-Directory/1.3.4.0 B2016.215.1556
it seems to me that corresponds to
rpm -qi -p 389-ds-base-1.3.4.0-33.el7_2.x86_64.rpm | grep -i ^signature
Signature :
HI Jim,
it's normal to have an entry "cn=replica" under your mapping tree. That
does not mean that you are replicating.
It means the database is "enabled" for replication. And as it enabled, it
needs a "replicaid" in the topology that in your case is 40. You cannot
clean this id.
In ipa, main dat
Hi John
you could add a particular ACI to allow any groupdn or userdn to read/search
userPassword under the required tree. Something like:
aci: (targetattr = "userPassword") (target =
"ldap:///cn=users,cn=accounts,dc=,dc=") (version 3.0;acl "Allow
password read";allow (read,compare,search)(gr
Hi Torsten,
is it possible to provide a core or stacktrace ?
http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes
Thanks and regards,
German.
- Original Message -
> From: "Torsten Harenberg"
> To: freeipa-users@redhat.com
> Sent: Friday, November 13, 2015 1:53:13 PM
> Su
Hi Danielle,
I think you could recreate the entry. The information can be found in "o=ipaca"
database.
ldapsearch -D "cn=directory manager" -W -b
"ou=certificateRepository,ou=ca,o=ipaca" "(subjectname=CN=Certificate
Authority,o=example.test)" usercertificate
(remember that in RHEL6 you will n
Hi Fraser,
thanks for the workaround. As I have a customer who hit this bug, I have
created BZ 1313207 to trace this issue in the case.
Regards,
German.
- Original Message -
> From: "Fraser Tweedale"
> To: "Ian Pilcher" , "Natxo Asenjo"
>
> Cc: freeipa-users@redhat.com
> Sent: Tuesd
