[389-users] Re: replication question

dn: cn=replica,cn=dc\3Dnorthshore\2Cdc\3Dedu,cn=mapping tree,cn=config objectClass: nsDS5Replica objectClass: top nsDS5ReplicaRoot: dc=northshore,dc=edu nsDS5ReplicaType: 2 nsDS5Flags: 0 nsds5ReplicaPurgeDelay: 604800 nsDS5ReplicaBindDN:*cn=replication manager,cn=config* cn: replica creatorsName:

[389-users] Re: a replication problem

I think the real command is: kinit -k -t /etc/dirsrv/ds.keytab ldap/h...@cnvr.net That does work > On Mar 23, 2018, at 9:51 AM, Mark Reynolds wrote: > > I must admit I don't know too much about troubleshooting kerberos, I > just know that in

[389-users] Re: error moving an user

Simon, I was able to reproduce the problem in a new fresh install (I just imported my database), and It's related to "Referential Integrity Postoperation Plugin" that I use in my environment. When I disable it, the moving works just fine. I have a single master, replication to one AD. I changed

[389-users] Re: a replication problem

I must admit I don't know too much about troubleshooting kerberos, I just know that in your case its broken.  Perhaps ask for help on on the FreeIPA users list as they are much more familiar with this than I am: freeipa-us...@lists.fedorahosted.org On 03/23/2018 10:40 AM, Sergei Gerasenko wrote:

[389-users] Re: a replication problem

Also, and I don’t know if it’s strange, but I get that kinit error on any IPA host. I have a 2-master VM environment and trying kinit -k -t /etc/dirsrv/ds.keytab gives the same error back — but they are replicating without issues. ___ 389-users

[389-users] Re: a replication problem

Yes, there’s something there. Should I follow this and everything should be ok? http://directory.fedoraproject.org/docs/389ds/howto/howto-kerberos.html > On Mar 23, 2018, at 9:10 AM, Mark Reynolds

[389-users] Re: a replication problem

On 03/23/2018 10:01 AM, Sergei Gerasenko wrote: > > >> On Mar 23, 2018, at 8:58 AM, Mark Reynolds > > wrote: >> >> kinit -k -t /etc/dirsrv/ds.keytab > > kinit: Keytab contains no suitable keys for > host/ipa204.iad.cnvr@cnvr.net >

[389-users] Re: a replication problem

> On Mar 23, 2018, at 8:58 AM, Mark Reynolds wrote: > > kinit -k -t /etc/dirsrv/ds.keytab kinit: Keytab contains no suitable keys for host/ipa204.iad.cnvr@cnvr.net while getting initial credentials___ 389-users mailing

[389-users] Re: replication question

Looks like I have a replication conflict but I’m not sure if it’s really the cause of the problem. ldapsearch -xLLL -o ldif-wrap=no -D cn='directory manager' -w PWD -h ipa102.cnvr.net -b 'dc=CNVR,dc=NET' nsDS5ReplConflict=* dn cn=System: Read Certmap

[389-users] Re: a replication problem

On 03/23/2018 09:25 AM, Sergei Gerasenko wrote: > So here’s a more complete snippet from the host (ipa204) that can’t > push to its partner (ipa203): > > [23/Mar/2018:04:09:43.460073218 +] - ERR - NSACLPlugin - acl_parse > - The ACL target cn=vaults,cn=kra,dc=XXX,dc=net does not exist >

[389-users] Re: replication question

On 03/23/2018 09:05 AM, JESSE LUNT wrote: > Here is the dse.ldif on 389ds2 (strange that it is in a slapd-389ds1 > directory, I thought it was supposed to create a directory named > slapd-hostname. Could this server be a clone? ) Perhaps, but you can name an instance anything you want. I see a

[389-users] Re: a replication problem

So here’s a more complete snippet from the host (ipa204) that can’t push to its partner (ipa203): [23/Mar/2018:04:09:43.460073218 +] - ERR - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=XXX,dc=net does not exist [23/Mar/2018:04:09:43.460238115 +] - ERR - NSACLPlugin -

[389-users] Re: a replication problem

The only other message before that is suspcious: set_krb5_creds - Could not get initial credentials for principal ... in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328203 (Key table entry not found) I might get more when I get to work, but I think that’s all the errors I found. The resume

[389-users] Re: a replication problem

On 03/23/2018 12:07 AM, Sergei Gerasenko wrote: > The error I’m basically getting is: > > [23/Mar/2018:03:23:29.461074995 +] - ERR - NSMMReplicationPlugin - > bind_and_check_pwp - agmt=“cn=HOST1-to-HOST2" (ipa203:389) - Replication bind > with GSSAPI auth failed: LDAP error 49 (Invalid