Hi, On Mon, Jun 16, 2025 at 5:28 PM Kroon PC, Peter via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote:
> > Hi Flo, > > >> [server1]# ldapsearch -Y GSSAPI -h server2.ipa.test -b "" -s base > >This one fails > >What is the error/output? > Sorry, should've mentioned that immediately: > ``` > SASL/GSSAPI authentication started > ldap_sasl_interactive_bind: Invalid credentials (49) > ``` > The logs on server2: > ``` > [server2]# grep conn=94717 access > [16/Jun/2025:15:06:02.209765786 +0000] conn=94717 fd=340 slot=340 > connection from 192.168.12.58 to 192.168.13.128 > [16/Jun/2025:15:06:02.226498460 +0000] conn=94717 op=0 BIND dn="" > method=sasl version=3 mech=GSSAPI > [16/Jun/2025:15:06:02.227725823 +0000] conn=94717 op=0 RESULT err=49 > tag=97 nentries=0 wtime=0.000429934 optime=0.001229939 etime=0.001657378 - > SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context > My last idea would be to check if you see any S4U2PROXY_EVIDENCE_TKT_WITHOUT_PAC error in /var/log/krb5kdc.log on server1/server2. This may be related to missing SID, and if that's the case you need to run # kinit admin # ipa config-mod --enable-sid --add-sids Since replication is broken I would run the command on both machines. Then check if there are any error related to sid in /var/log/dirsrv/slapd-XXX/errors flo [16/Jun/2025:15:06:02.477199855 +0000] conn=94717 op=1 UNBIND > [16/Jun/2025:15:06:02.477239120 +0000] conn=94717 op=1 fd=340 Disconnect - > Cleanly Closed Connection - U1 > [server2]# grep conn=94720 access > [16/Jun/2025:15:06:03.438152386 +0000] conn=94720 fd=384 slot=384 > connection from 192.168.12.58 to 192.168.13.128 > [16/Jun/2025:15:06:03.470403124 +0000] conn=94720 op=0 BIND dn="" > method=sasl version=3 mech=GSSAPI > [16/Jun/2025:15:06:03.471510086 +0000] conn=94720 op=0 RESULT err=49 > tag=97 nentries=0 wtime=0.000427299 optime=0.001123074 etime=0.001548149 - > SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context > [16/Jun/2025:15:06:03.473239612 +0000] conn=94720 op=1 UNBIND > [16/Jun/2025:15:06:03.473268077 +0000] conn=94720 op=1 fd=384 Disconnect - > Cleanly Closed Connection - U1 > [server2]# grep conn=94721 access > [16/Jun/2025:15:06:03.472944276 +0000] conn=94721 fd=386 slot=386 > connection from 192.168.12.58 to 192.168.13.128 > [16/Jun/2025:15:06:03.499428848 +0000] conn=94721 op=0 BIND dn="" > method=sasl version=3 mech=GSSAPI > [16/Jun/2025:15:06:03.500455145 +0000] conn=94721 op=0 RESULT err=49 > tag=97 nentries=0 wtime=0.000313752 optime=0.001027941 etime=0.001339388 - > SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context > [16/Jun/2025:15:06:03.750092421 +0000] conn=94721 op=1 UNBIND > [16/Jun/2025:15:06:03.750133630 +0000] conn=94721 op=1 fd=386 Disconnect - > Cleanly Closed Connection - U1 > ``` > > I diffed the service-show output; it's almost identical. I've marked the > places where it differs: > ``` > [server1]# ipa service-show ldap/server1.ipa.t...@ipa.test --all --raw > dn: krbprincipalname=ldap/server1.ipa.t...@ipa.test > ,cn=services,cn=accounts,<redacted> > krbcanonicalname: ldap/server1.ipa.t...@ipa.test > krbprincipalname: ldap/server1.ipa.t...@ipa.test > usercertificate: <redacted, identical on server2> > subject: CN=server1.ipa.t...@ipa.test > serial_number: 268369921 > serial_number_hex: 0xFFF0001 > issuer: CN=Certificate Authority,O=IPA.TEST > valid_not_before: Tue Apr 30 09:02:26 2024 UTC > valid_not_after: Fri May 01 09:02:26 2026 UTC > sha1_fingerprint: > 67:f5:4c:bd:df:a1:af:1f:45:b5:ce:1e:36:0b:1d:64:41:46:ae:44 > sha256_fingerprint: > da:0c:22:12:6a:41:11:ea:09:e7:2a:aa:89:cd:09:66:23:cd:95:a4:77:21:34:5c:21:82:6e:01:77:ae:9a:9b > has_keytab: TRUE > managedby: fqdn=server1.ipa.test,cn=computers,cn=accounts,<redacted> > ipaKrbPrincipalAlias: ldap/server1.ipa.t...@ipa.test > ipaUniqueID: 4d3c9622-06d0-11ef-be74-a60b6cb71064 > krbExtraData: <redacted, identical on server2> > krbLastFailedAuth: 20250616150511Z # This is absent on server2 > krbLastPwdChange: 20240430090159Z > krbLastSuccessfulAuth: 20250616150512Z # This is different on server2 > krbLoginFailedCount: 0 # This is absent on server2 > krbPwdPolicyReference: cn=Default Service Password > Policy,cn=services,cn=accounts,<redacted> > memberof: cn=replication managers,cn=sysaccounts,cn=etc,<redacted> > objectClass: krbprincipal > objectClass: krbprincipalaux > objectClass: krbticketpolicyaux > objectClass: ipaobject > objectClass: ipaservice > objectClass: pkiuser > objectClass: ipakrbprincipal > objectClass: top > > [server2]# ipa service-show ldap/server1.ipa.t...@ipa.test --all --raw > dn: krbprincipalname=ldap/server1.ipa.t...@ipa.test > ,cn=services,cn=accounts,<redacted> > krbcanonicalname: ldap/server1.ipa.t...@ipa.test > krbprincipalname: ldap/server1.ipa.t...@ipa.test > usercertificate: <redacted, identical on server1> > subject: CN=server1.ipa.t...@ipa.test > serial_number: 268369921 > serial_number_hex: 0xFFF0001 > issuer: CN=Certificate Authority,O=IPA.TEST > valid_not_before: Tue Apr 30 09:02:26 2024 UTC > valid_not_after: Fri May 01 09:02:26 2026 UTC > sha1_fingerprint: > 67:f5:4c:bd:df:a1:af:1f:45:b5:ce:1e:36:0b:1d:64:41:46:ae:44 > sha256_fingerprint: > da:0c:22:12:6a:41:11:ea:09:e7:2a:aa:89:cd:09:66:23:cd:95:a4:77:21:34:5c:21:82:6e:01:77:ae:9a:9b > has_keytab: TRUE > managedby: fqdn=server1.ipa.test,cn=computers,cn=accounts,<redacted> > ipaKrbPrincipalAlias: ldap/server1.ipa.t...@ipa.test > ipaUniqueID: 4d3c9622-06d0-11ef-be74-a60b6cb71064 > krbExtraData: <redacted, identical on server1> > krbLastPwdChange: 20240430090159Z > krbLastSuccessfulAuth: 20250530124646Z # This is different on server1 > krbPwdPolicyReference: cn=Default Service Password > Policy,cn=services,cn=accounts,<redacted> > memberof: cn=replication managers,cn=sysaccounts,cn=etc,<redacted> > objectClass: krbprincipal > objectClass: krbprincipalaux > objectClass: krbticketpolicyaux > objectClass: ipaobject > objectClass: ipaservice > objectClass: pkiuser > objectClass: ipakrbprincipal > objectClass: top > ``` > > Many thanks for thinking along! > Peter > ________________________________________ > From: Florence Blanc-Renaud <f...@redhat.com> > Sent: Monday, 16 June 2025 16:57 > To: Kroon PC, Peter > Cc: FreeIPA users list > Subject: Re: [Freeipa-users] Re: Replication issues > > U ontvangt niet vaak e-mail van f...@redhat.com. Ontdek waarom dit > belangrijk is<https://aka.ms/LearnAboutSenderIdentification> > Hi, > > On Mon, Jun 16, 2025 at 10:37 AM Kroon PC, Peter <p.c.kr...@pl.hanze.nl > <mailto:p.c.kr...@pl.hanze.nl>> wrote: > Thanks Flo, > Outlook still hates inline replies, so I'll put it all on top: > > > [server1]# ldapsearch -Y GSSAPI -h server2.ipa.test -b "" -s base > This one fails > What is the error/output? > Do you see a corresponding log on server2 in > /var/log/dirsrv/slapd-XXX/access ? As the access log is buffered, it may > not appear immediately but the lines should look like this: > > [16/Jun/2025:14:19:40.196675396 +0000] conn=4308 fd=91 slot=91 connection > from 10.0.144.249 to 10.0.147.13 > [16/Jun/2025:14:19:40.235073103 +0000] conn=4308 op=0 BIND dn="" > method=sasl version=3 mech=GSSAPI > [16/Jun/2025:14:19:40.238083749 +0000] conn=4308 op=0 RESULT err=14 tag=97 > nentries=0 wtime=0.000239213 optime=0.003014757 etime=0.003253237, SASL > bind in progress > [16/Jun/2025:14:19:40.242142681 +0000] conn=4308 op=1 BIND dn="" > method=sasl version=3 mech=GSSAPI > [16/Jun/2025:14:19:40.243578790 +0000] conn=4308 op=1 RESULT err=14 tag=97 > nentries=0 wtime=0.000043381 optime=0.001435699 etime=0.001478388, SASL > bind in progress > [16/Jun/2025:14:19:40.244527413 +0000] conn=4308 op=2 BIND dn="" > method=sasl version=3 mech=GSSAPI > [16/Jun/2025:14:19:40.245078046 +0000] conn=4308 op=2 RESULT err=0 tag=97 > nentries=0 wtime=0.000030979 optime=0.000556235 etime=0.000586594 > dn="krbprincipalname=ldap/server1.ipa.t...@ipa.test > ,cn=services,cn=accounts,dc=ipa,dc=test" > [16/Jun/2025:14:19:40.245470809 +0000] conn=4308 op=3 SRCH base="" scope=0 > filter="(objectClass=*)" attrs=ALL > [16/Jun/2025:14:19:40.246272148 +0000] conn=4308 op=3 RESULT err=0 tag=101 > nentries=1 wtime=0.000101444 optime=0.000801741 etime=0.000902112 > [16/Jun/2025:14:19:40.247713690 +0000] conn=4308 op=4 UNBIND > > If you don't see the first lines, it means the connection is not > established, maybe a DNS issue or firewall issue. > If you see the BIND lines with a corresponding err=49, it means the server > is not able to associate the kerberos principal name with a LDAP entry. Can > you check the content of this ldap entry on both server1 and server2 with > this command: > ipa service-show ldap/server1.ipa.t...@ipa.test --all --raw > > The value for krbprincipalname should be ldap/server1.ipa.t...@ipa.test > > flo > > > > > [server1]# klist -kte /etc/dirsrv/ds.keytab > > [server1]# kvno ldap/server1.ipa.t...@ipa.test > Both of these have kvno 1 > > > [server2]# kadmin.local getprinc ldap/server.ipa.t...@ipa.test > Interesing, this one also has knvo1! > > Screen output for the lot: > [server1]# klist -kte /etc/dirsrv/ds.keytab > Keytab name: FILE:/etc/dirsrv/ds.keytab > KVNO Timestamp Principal > ---- ----------------- > -------------------------------------------------------- > 1 04/30/24 11:01:59 ldap/server1.ipa.t...@ipa.test > (aes256-cts-hmac-sha1-96) > 1 04/30/24 11:01:59 ldap/server1.ipa.t...@ipa.test > (aes128-cts-hmac-sha1-96) > [server1]# kvno ldap/server1.ipa.t...@ipa.test > ldap/server1.ipa.t...@ipa.test: kvno = 1 > > [server2]# kadmin.local getprinc ldap/server1.ipa.t...@ipa.test > Principal: ldap/server1.ipa.t...@ipa.test > Expiration date: [never] > Last password change: Tue Apr 30 09:01:59 UTC 2024 > Password expiration date: [never] > Maximum ticket life: 1 day 00:00:00 > Maximum renewable life: 7 days 00:00:00 > Last modified: Tue Apr 30 09:01:59 UTC 2024 (ldap/server1.ipa.t...@ipa.test > ) > Last successful authentication: Fri May 30 12:46:46 UTC 2025 > Last failed authentication: [never] > Failed password attempts: 0 > Number of keys: 2 > Key: vno 1, aes256-cts-hmac-sha1-96:special > Key: vno 1, aes128-cts-hmac-sha1-96:special > MKey: vno 1 > Attributes: REQUIRES_PRE_AUTH > Policy: [none] > > Many thanks, > Peter > ________________________________________ > From: Florence Blanc-Renaud <f...@redhat.com<mailto:f...@redhat.com>> > Sent: Monday, 16 June 2025 10:01 > To: FreeIPA users list > Cc: Kroon PC, Peter > Subject: Re: [Freeipa-users] Re: Replication issues > > U ontvangt niet vaak e-mail van f...@redhat.com<mailto:f...@redhat.com>. > Ontdek waarom dit belangrijk is< > https://aka.ms/LearnAboutSenderIdentification> > Hi, > > On Mon, Jun 16, 2025 at 9:10 AM Kroon PC, Peter via FreeIPA-users < > freeipa-users@lists.fedorahosted.org<mailto: > freeipa-users@lists.fedorahosted.org><mailto: > freeipa-users@lists.fedorahosted.org<mailto: > freeipa-users@lists.fedorahosted.org>>> wrote: > Hi Mark, > > thanks for chipping in. > Does anyone else have any suggestions before I wipe and reinstall the > replica entirely? > > You need to check if the credentials used for the replication are working. > > On the first server: > [server1]# kinit -kt /etc/dirsrv/ds.keytab ldap/server1.ipa.test > [server1]# ldapsearch -Y GSSAPI -h server1.ipa.test -b "" -s base > [server1]# ldapsearch -Y GSSAPI -h server2.ipa.test -b "" -s base > > The first LDAP search authenticates to the local LDAP server with the > credentials from ds keytab, the 2nd LDAP search authenticates to the other > master. Both should succeed. > If one fails, you need to check the kvno: > [server1]# klist -kte /etc/dirsrv/ds.keytab > [server1]# kvno ldap/server1.ipa.t...@ipa.test > The klist command outputs the kvno stored in the ds.keytab file. It has to > match the kvno returned by the 2nd command (the kvno as seen by the > kerberos server). If they don't match, it means that the key has been > re-generated but there is an inconsistency between the one stored in the > ds.keytab file and the one stored by the kerberos server. > > Also check that you get the same value for the KVNO on the other master > [server2]# kadmin.local getprinc ldap/server.ipa.t...@ipa.test > The above command directly checks in the kerberos server. > > The repair steps depend on which key is the most recent one, and where it > is stored. Please provide the kvnos from all the commands and we'll try to > guide you. > flo > > Peter > > ________________________________________ > From: Mark Reynolds <marey...@redhat.com<mailto:marey...@redhat.com > ><mailto:marey...@redhat.com<mailto:marey...@redhat.com>>> > Sent: Friday, 6 June 2025 17:32 > To: FreeIPA users list > Cc: Kroon PC, Peter > Subject: Re: [Freeipa-users] Re: Replication issues > > [You don't often get email from marey...@redhat.com<mailto: > marey...@redhat.com><mailto:marey...@redhat.com<mailto:marey...@redhat.com>>. > Learn why this is important at > https://aka.ms/LearnAboutSenderIdentification ] > > On 6/6/25 11:01 AM, Kroon PC, Peter via FreeIPA-users wrote: > > Hi Mark, > > > > thanks for the quick reply. > > Server-B has the following in the access log (twice, actually): > > ``` > > [06/Jun/2025:14:55:33.573567003 +0000] conn=8984 fd=372 slot=372 > connection from 192.168.12.58 to 192.168.13.128 > > [06/Jun/2025:14:55:33.613280772 +0000] conn=8984 op=0 BIND dn="" > method=sasl version=3 mech=GSSAPI > > [06/Jun/2025:14:55:33.614444924 +0000] conn=8984 op=0 RESULT err=49 > tag=97 nentries=0 wtime=0.000406209 optime=0.001176425 etime=0.001580230 - > SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context > > [06/Jun/2025:14:55:33.696712718 +0000] conn=8984 op=1 UNBIND > > [06/Jun/2025:14:55:33.696753716 +0000] conn=8984 op=1 fd=372 Disconnect > - Cleanly Closed Connection - U1 > > ``` > > I don't fully understand why it's trying GSSAPI after I entered the > directory manager password. > You authenticated as Directory Manager to the CLI, but it invokes the > replication agreement credentials to do the replication initialization > behind the scenes. > > I'd assume it'd use simple bind. > > In the security log there's the following, nothing about the failed > gssapi bind. > > ``` > > { "date": "[06\/Jun\/2025:14:55:00.776221689 +0000] ", "utc_time": > "1749221700.776221689", "event": "BIND_SUCCESS", "dn": "cn=directory > manager", "bind_method": "SIMPLE", "root_dn": true, "client_ip": > "192.168.12.58", "server_ip": "192.168.13.128", "ldap_version": 3, > "conn_id": 8983, "op_id": 0, "msg": "" } > > ``` > This is a different connection, but the other failed bind should have > been logged. Might have a bug somewhere :-( > > > > I'm about to leave the office for a long weekend, so I probably won't > respond again before Tuesday. > > So you "might" need to do an offline initialization to fix this, but I > suspect there is an official way the IPA team recommends to fix this > (sorry not as familiar with IPA as I am DS). So maybe someone from the > core IPA team and provide their recommendation. > > Mark > > > > > Peter > > > > ________________________________________ > > From: Mark Reynolds <marey...@redhat.com<mailto:marey...@redhat.com > ><mailto:marey...@redhat.com<mailto:marey...@redhat.com>>> > > Sent: Friday, 6 June 2025 15:26 > > To: FreeIPA users list > > Cc: Kroon PC, Peter > > Subject: Re: [Freeipa-users] Replication issues > > > > [You don't often get email from marey...@redhat.com<mailto: > marey...@redhat.com><mailto:marey...@redhat.com<mailto:marey...@redhat.com>>. > Learn why this is important at > https://aka.ms/LearnAboutSenderIdentification ] > > > > Hi Peter, > > > > So the credentials the replication agreement is using are not valid (for > > whatever reason). Please check the directory server access log for > > "err=49" and you should see the bind DN and more details on why the > > authentication failed. > > > > HTH, > > > > Mark > > > > On 6/6/25 6:56 AM, Kroon PC, Peter via FreeIPA-users wrote: > >> Hello world, > >> > >> I have 3 IPA servers that are supposed to all replicate with each > other. For one server this stopped working. On all servers I have > ipa-server 4.12.2-14.el9_6 on Rocky Linux 9.6. > >> I'll call my servers A, B, and C. Server A cannot replicate with > neither server B nor C. B and C can replicate eachother without issues. My > first suspicion was a firewall, but I've already confirmed that that's not > the issue. > >> Here's the sanitized CLI outputs, all from server A: > >> ``` > >> $ ipa-healthcheck > >> { > >> "source": "ipahealthcheck.ds.replication", > >> "check": "ReplicationCheck", > >> "result": "CRITICAL", > >> "uuid": "9c96a61a-d917-44de-907a-d5c7a4df667e", > >> "when": "20250606095130Z", > >> "duration": "1.072988", > >> "kw": { > >> "key": "DSREPLLE0001", > >> "items": [ > >> "Replication", > >> "Agreement" > >> ], > >> "msg": "The replication agreement ( > server-A.example.com-to-server-C.example.com< > http://server-a.example.com-to-server-c.example.com/>< > http://server-a.example.com-to-server-c.example.com/< > http://server-a.example.com-to-server-c.example.com/>>) under > \"dc=example,dc=com\" is not in synchronization." > >> } > >> }, > >> { > >> "source": "ipahealthcheck.ds.replication", > >> "check": "ReplicationCheck", > >> "result": "CRITICAL", > >> "uuid": "6c29d38e-a216-414e-b47a-d9302f38da67", > >> "when": "20250606095131Z", > >> "duration": "1.073047", > >> "kw": { > >> "key": "DSREPLLE0001", > >> "items": [ > >> "Replication", > >> "Agreement" > >> ], > >> "msg": "The replication agreement (metoserver-B.example.com< > http://metoserver-b.example.com/><http://metoserver-b.example.com/< > http://metoserver-b.example.com/>>) under \"dc=example,dc=com\" is not in > synchronization." > >> } > >> }, > >> { > >> "source": "ipahealthcheck.ds.replication", > >> "check": "ReplicationCheck", > >> "result": "CRITICAL", > >> "uuid": "445f686b-27d9-47e0-aaa8-bb8d5f3416d4", > >> "when": "20250606095131Z", > >> "duration": "1.073054", > >> "kw": { > >> "key": "DSREPLLE0001", > >> "items": [ > >> "Replication", > >> "Agreement" > >> ], > >> "msg": "The replication agreement (catoserver-B.example.com< > http://catoserver-b.example.com/><http://catoserver-b.example.com/< > http://catoserver-b.example.com/>>) under \"o=ipaca\" is not in > synchronization." > >> } > >> }, > >> { > >> "source": "ipahealthcheck.ds.replication", > >> "check": "ReplicationCheck", > >> "result": "CRITICAL", > >> "uuid": "bb6fb4b1-54fc-45dc-bb33-c8c3562f5765", > >> "when": "20250606095131Z", > >> "duration": "1.073058", > >> "kw": { > >> "key": "DSREPLLE0001", > >> "items": [ > >> "Replication", > >> "Agreement" > >> ], > >> "msg": "The replication agreement ( > server-A.example.com-to-server-C.example.com< > http://server-a.example.com-to-server-c.example.com/>< > http://server-a.example.com-to-server-c.example.com/< > http://server-a.example.com-to-server-c.example.com/>>) under \"o=ipaca\" > is not in synchronization." > >> } > >> } > >> ``` > >> ``` > >> $ ipa-replica-manage list > >> ipa-replica-manage list > >> Directory Manager password: > >> > >> server-A.example.com<http://server-a.example.com/>< > http://server-a.example.com/<http://server-a.example.com/>>: master > >> server-B.example.com<http://server-b.example.com/>< > http://server-b.example.com/<http://server-b.example.com/>>: master > >> server-C.example.com<http://server-c.example.com/>< > http://server-c.example.com/<http://server-c.example.com/>>: master > >> ``` > >> Ok, things are broken, let's try force-sync. > >> ``` > >> $ ipa-replica-manage force-sync --from server-B.example.com< > http://server-b.example.com/><http://server-b.example.com/< > http://server-b.example.com/>> --verbose --debug > >> <snip imports> > >> ipa: DEBUG: found 1 A records for server-A.example.com< > http://server-a.example.com/><http://server-a.example.com/< > http://server-a.example.com/>>.: 192.168.12.58 > >> ipa: DEBUG: The DNS response does not contain an answer to the > question: server-A.example.com<http://server-a.example.com/>< > http://server-a.example.com/<http://server-a.example.com/>>. IN AAAA > >> Directory Manager password: > >> > >> ipa: DEBUG: Created connection context.ldap2_139632322538896 > >> ipa: DEBUG: found 1 A records for server-A.example.com< > http://server-a.example.com/><http://server-a.example.com/< > http://server-a.example.com/>>.: 192.168.12.58 > >> ipa: DEBUG: The DNS response does not contain an answer to the > question: server-A.example.com<http://server-a.example.com/>< > http://server-a.example.com/<http://server-a.example.com/>>. IN AAAA > >> ipa: DEBUG: found 1 A records for server-B.example.com< > http://server-b.example.com/><http://server-b.example.com/< > http://server-b.example.com/>>.: 192.168.13.128 > >> ipa: DEBUG: The DNS response does not contain an answer to the > question: server-B.example.com<http://server-b.example.com/>< > http://server-b.example.com/<http://server-b.example.com/>>. IN AAAA > >> ipa: DEBUG: retrieving schema for SchemaCache url=ldaps:// > server-A.example.com:636<http://server-a.example.com:636/>< > http://server-a.example.com:636/<http://server-a.example.com:636/>> > conn=<ldap.ldapobject.SimpleLDAPObject object at 0x7efeaefd2460> > >> ipa: DEBUG: Loading StateFile from > '/var/lib/ipa/sysrestore/sysrestore.state' > >> ipa: DEBUG: Loading Index file from > '/var/lib/ipa/sysrestore/sysrestore.index' > >> ipa: DEBUG: retrieving schema for SchemaCache > url=ldapi://%2Frun%2Fslapd-BIN-BIOINF-NL.socket > conn=<ldap.ldapobject.SimpleLDAPObject object at 0x7efeaefd2610> > >> ipa: DEBUG: retrieving schema for SchemaCache url=ldaps:// > server-B.example.com:636<http://server-b.example.com:636/>< > http://server-b.example.com:636/<http://server-b.example.com:636/>> > conn=<ldap.ldapobject.SimpleLDAPObject object at 0x7efeae1ee1f0> > >> ipa: INFO: Setting agreement cn=meToserver-A.example.com< > http://metoserver-a.example.com/><http://metoserver-a.example.com/< > http://metoserver-a.example.com/>>,cn=replica,cn=dc\=example\,dc\=com,cn=mapping > tree,cn=config schedule to 2358-2359 0 to force synch > >> ipa: INFO: Deleting schedule 2358-2359 0 from agreement cn= > meToserver-A.example.com<http://metoserver-a.example.com/>< > http://metoserver-a.example.com/<http://metoserver-a.example.com/>>,cn=replica,cn=dc\=example\,dc\=com,cn=mapping > tree,cn=config > >> ipa: INFO: Replication Update in progress: False: status: Error (49) > Problem connecting to replica - LDAP error: Invalid credentials (connection > error): start: 19700101000000: end: 19700101000000 > >> ipa: DEBUG: Destroyed connection context.ldap2_139632322538896 > >> ``` > >> Maybe I can re-initialize? > >> ``` > >> $ ipa-replica-manage re-initialize --from server-B.example.com< > http://server-b.example.com/><http://server-b.example.com/< > http://server-b.example.com/>> --verbose --debug > >> <snip import> > >> <snip DNS responses, same as above> > >> Directory Manager password: > >> ipa: DEBUG: Created connection context.ldap2_140512488991280 > >> ipa: DEBUG: retrieving schema for SchemaCache url=ldaps:// > server-A.example.com:636<http://server-a.example.com:636/>< > http://server-a.example.com:636/<http://server-a.example.com:636/>> > conn=<ldap.ldapobject.SimpleLDAPObject object at 0x7fcb9c310dc0> > >> ipa: DEBUG: retrieving schema for SchemaCache url=ldaps:// > server-B.example.com:636<http://server-b.example.com:636/>< > http://server-b.example.com:636/<http://server-b.example.com:636/>> > conn=<ldap.ldapobject.SimpleLDAPObject object at 0x7fcb9c1e10a0> > >> ipa: INFO: Setting agreement cn=meToserver-A.example.com< > http://metoserver-a.example.com/><http://metoserver-a.example.com/< > http://metoserver-a.example.com/>>,cn=replica,cn=dc\=example\,dc\=com,cn=mapping > tree,cn=config schedule to 2358-2359 0 to force synch > >> ipa: INFO: Deleting schedule 2358-2359 0 from agreement cn= > meToserver-A.example.com<http://metoserver-a.example.com/>< > http://metoserver-a.example.com/<http://metoserver-a.example.com/>>,cn=replica,cn=dc\=example\,dc\=com,cn=mapping > tree,cn=config > >> Update in progress, 15 seconds elapsed > >> [ldaps://server-B.example.com:636<http://server-b.example.com:636/>< > http://server-b.example.com:636/<http://server-b.example.com:636/>>] > reports: Update failed! Status: [Error (49) - LDAP error: Invalid > credentials - no response received] > >> ipa: DEBUG: Destroyed connection context.ldap2_140512488991280 > >> ``` > >> Is it a firewall or password issue? No: > >> ``` > >> $ ldapwhoami -H ldaps://server-B.example.com< > http://server-b.example.com/><http://server-b.example.com/< > http://server-b.example.com/>> -D 'cn=directory manager' -W > >> Enter LDAP Password: > >> dn: cn=directory manager > >> ``` > >> From server-B: > >> ``` > >> server-B $ ldapwhoami -H ldaps://server-A.example.com< > http://server-a.example.com/><http://server-a.example.com/< > http://server-a.example.com/>> -D 'cn=directory manager' -W > >> Enter LDAP Password: > >> dn: cn=directory manager > >> ``` > >> I also checked that `ipa-replica-manage list-ruv` produces the same > output for all 3 servers. > >> Does anyone have any more ideas I could explore? > >> > >> Many thanks in advance! > >> Peter > > -- > > Identity Management Development Team > > > -- > Identity Management Development Team > > -- > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org<mailto: > freeipa-users@lists.fedorahosted.org><mailto: > freeipa-users@lists.fedorahosted.org<mailto: > freeipa-users@lists.fedorahosted.org>> > To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org > <mailto:freeipa-users-le...@lists.fedorahosted.org><mailto: > freeipa-users-le...@lists.fedorahosted.org<mailto: > freeipa-users-le...@lists.fedorahosted.org>> > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/< > https://docs.fedoraproject.org/en-US/project/code-of-conduct/>< > https://docs.fedoraproject.org/en-US/project/code-of-conduct/< > https://docs.fedoraproject.org/en-US/project/code-of-conduct/>> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines< > https://fedoraproject.org/wiki/Mailing_list_guidelines>< > https://fedoraproject.org/wiki/Mailing_list_guidelines< > https://fedoraproject.org/wiki/Mailing_list_guidelines>> > List Archives: > https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org > < > https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org > >< > https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org > < > https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org > >> > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue< > https://pagure.io/fedora-infrastructure/new_issue>< > https://pagure.io/fedora-infrastructure/new_issue< > https://pagure.io/fedora-infrastructure/new_issue>> > -- > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue >
-- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
