On 3.3.2016 22:05, de...@pabstatencio.com wrote:
> 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@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@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@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@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" <rcrit...@redhat.com> wrote:
>> de...@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.
Hmm, I'm not sure if realm name "myinc.LOCAL" is a obfuscation artifact or
real configuration. As usual, attempts to obfuscate things make debugging
harder :-)
Generally it is not a good idea to have realm != uppercase primary IPA DNS
domain.
It seems that for some reason client is failing to find KDC's addresses.
Try to run kinit in debug mode. Before you try that you might need to replace
krb5.conf on the client with following values (taken form client install log):
[libdefaults]
default_realm = myinc.LOCAL
dns_lookup_realm = true
dns_lookup_kdc = true
rdns = false
ticket_lifetime = 24h
forwardable = yes
udp_preference_limit = 0
default_ccache_name = KEYRING:persistent:%{uid}
[realms]
myinc.LOCAL = {
pkinit_anchors = FILE:/etc/ipa/ca.crt
}
[domain_realm]
.prod.cloud.myinc.local = myinc.LOCAL
prod.cloud.myinc.local = myinc.LOCAL
Then you might try following command on the not-yet-enrolled host:
KRB5_TRACE=/dev/stdout kinit
'host/beanstalk01-ore.prod.cloud.myinc.local@myinc.LOCAL'
and see what it prints into the stdout.
Very important is to follow recommendations about DNS in the official docs:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/prerequisites.html#dns-reqs
and
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Securing_DNS_Traffic_with_DNSSEC.html#sec-Recommended_Naming_Practices
(In short: do *not* invent your own names like myinc.LOCAL, ever. Just a DNS
domain you actually own, always.)
Also, section "â Verifying the DNS Configuration" might get handy:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/trust-requirements.html#dns-realm-settings
(just skip the Active Directory parts and test only IPA)
I hope this will help.
Petr^2 Spacek
>>> 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
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
