[Freeipa-users] FreeIPA 4.2.0 / Replica / Join Issue

Thu Mar 3 21:05:50 UTC 2016

Rob,

Yeah i forgot to attach the file when I initially sent. I also attached the output from all the nodes. I guess what i realized is that my agreements are a little different than i originally thought. What is also strange is on a few hosts that initially did enroll from AWS, when I look at the host via the GUI the host shows:

Kerberos Key Present, Host Provisioned
One-Time-Password Not Present
Host Certificate, No Valid Certificate

So the few that enrolled, they don't show having any Host certificates but they show Kerberos Key present and Host provisioned. Is there a problem with the way I provisioned the Replicas? I'm just using subdomains for human clarification but they all use the same Kerberos domain, etc.

[root at ipa02-ore ~]# ipa-replica-manage list -v `hostname`
Directory Manager password:

ipa01-ore.prod.cloud.myinc.local: replica
  last init status: None
  last init ended: 1970-01-01 00:00:00+00:00
  last update status: 0 Replica acquired successfully: Incremental update succeeded
  last update ended: 2016-03-03 20:39:30+00:00

[root at ipa01-ore ~]# ipa-replica-manage list -v `hostname`
ipa02-ore.prod.cloud.myinc.local: replica
  last init status: None
  last init ended: 1970-01-01 00:00:00+00:00
  last update status: 0 Replica acquired successfully: Incremental update succeeded
  last update ended: 2016-03-03 20:41:20+00:00
rspsna-ipa01.prod.i2x.myinc.local: replica
  last init status: None
  last init ended: 1970-01-01 00:00:00+00:00
  last update status: 0 Replica acquired successfully: Incremental update succeeded
  last update ended: 2016-03-03 20:41:29+00:00

[root at rspsna-ipa01 ~]# ipa-replica-manage list -v `hostname`

ipa01-ore.prod.cloud.myinc.local: replica
  last init status: None
  last init ended: 1970-01-01 00:00:00+00:00
  last update status: 0 Replica acquired successfully: Incremental update succeeded
  last update ended: 2016-03-03 20:43:35+00:00
rspsna-ipa02.prod.i2x.myinc.local: replica
  last init status: None
  last init ended: 1970-01-01 00:00:00+00:00
  last update status: 0 Replica acquired successfully: Incremental update succeeded
  last update ended: 2016-03-03 20:43:35+00:00

[root at rspsna-ipa02 ~]# ipa-replica-manage list -v `hostname`

rspsna-ipa01.prod.i2x.myinc.local: replica
  last init status: None
  last init ended: 1970-01-01 00:00:00+00:00
  last update status: 0 Replica acquired successfully: Incremental update succeeded
  last update ended: 2016-03-03 20:44:14+00:00

See attached file for the initial fail. Thanks very much for your help.

Devin Acosta

arch 3 2016 1:34 PM, "Rob Crittenden" <rcritten at redhat.com> wrote:
> devin at pabstatencio.com wrote:
> 
>> I am running the latest patched CentOS 7.2, with FreeIPA 4.2.0, and I
>> the Master node in the Data Center, then i created 3 replica's, one in
>> the DC for High Availability, and then 2 Replica's in the AWS Cloud. I'm
>> having major issues with the Replica's in the AWS Cloud. I am trying to
>> have it so it auto-discovers the servers automatically so the failover
>> is dynamic. I created the replica's as well to have a Certificate
>> Authority. When I attempt to join a virtual machine in AWS to the domain
>> it fails half way thru the process. I have attached a full debug of my
>> ipa-client-install, hoping someone can assist me. I know prior to
>> joining the 2 replicas in AWS I had absolutely no issues with joining
>> servers in the DC to IDM. I built all my replica's from the Master
>> server (rspsna-ipa01), so rspsna-ipa02, ipa01-ore, ipa02-ore were built
>> from rspsna-ipa01.
>> 
>> The main part that seems to fail during the (client) join is:
> 
> The important bits are needed. This part of the log is just trying to
> clean things up (so failures are expected and ok). We'd really need to
> see a full ipaclient-install.log.
> 
>> When I look at the slapd error log on one of the replica's i see this:
>> 
>> [02/Mar/2016:23:40:09 +0000] - Listening on All Interfaces port 636 for
>> LDAPS requests
>> [02/Mar/2016:23:40:09 +0000] - Listening on
>> /var/run/slapd-MYINC-LOCAL.socket for LDAPI requests
>> [02/Mar/2016:23:40:09 +0000] slapd_ldap_sasl_interactive_bind - Error:
>> could not perform interactive bind for id [] mech [GSSAPI]: LDAP error
>> -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified
>> GSS failure. Minor code may provide more information (No Kerberos
>> credentials available)) errno 0 (Success)
>> [02/Mar/2016:23:40:09 +0000] slapi_ldap_bind - Error: could not perform
>> interactive bind for id [] authentication mechanism [GSSAPI]: error -2
>> (Local error)
>> [02/Mar/2016:23:40:09 +0000] NSMMReplicationPlugin -
>> agmt="cn=meTorspsna-ipa01.prod.i2x.myinc.local" (rspsna-ipa01:389):
>> Replication bind with GSSAPI auth failed: LDAP error -2 (Local error)
>> (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.
>> Minor code may provide more information (No Kerberos credentials available))
>> [02/Mar/2016:23:40:12 +0000] NSMMReplicationPlugin -
>> agmt="cn=meToipa02-ore.prod.cloud.myinc.local" (ipa02-ore:389):
>> Replication bind with GSSAPI auth resumed
>> [02/Mar/2016:23:40:12 +0000] NSMMReplicationPlugin -
>> agmt="cn=meTorspsna-ipa01.prod.i2x.myinc.local" (rspsna-ipa01:389):
>> Replication bind with GSSAPI auth resumed
> 
> Up to here is ok and expected, this is just 389-ds realizing it doesn't
> have Kerberos credentials yet and obtaining them.
> 
>> [03/Mar/2016:00:07:00 +0000] slapd_ldap_sasl_interactive_bind - Error:
>> could not perform interactive bind for id [] mech [GSSAPI]: LDAP error
>> -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is
>> not connected)
> 
> For these I'd run:
> 
> $ ipa-replica-manage list -v `hostname` to see the status of the
> agreements. It seems that one is unable to connect.
> 
> rob
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ipa-issue.txt
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20160303/8f3cb9da/attachment.txt>