[Freeipa-users] Could not connect to LDAP server host - IO Error creating JSS SSL Socket:
Michael Plemmons
michael.plemmons at crosschx.com
Thu May 18 15:29:43 UTC 2017
SOLVED!
Thank you Flo! That did the trick. Once I made the change to the
certificate and restarted the IPA services everything came back up like it
was supposed to.
High five!
*Mike Plemmons | Senior DevOps Engineer | CROSSCHX*
614.427.2411
mike.plemmons at crosschx.com
www.crosschx.com
On Thu, May 18, 2017 at 10:28 AM, Florence Blanc-Renaud <flo at redhat.com>
wrote:
> On 05/18/2017 03:49 PM, Michael Plemmons wrote:
>
>>
>>
>>
>>
>> *Mike Plemmons | Senior DevOps Engineer | CROSSCHX
>> *
>> 614.427.2411
>> mike.plemmons at crosschx.com <mailto:mike.plemmons at crosschx.com>
>> www.crosschx.com <http://www.crosschx.com/>
>>
>> On Thu, May 18, 2017 at 8:02 AM, Florence Blanc-Renaud <flo at redhat.com
>> <mailto:flo at redhat.com>> wrote:
>>
>> On 05/15/2017 08:33 PM, Michael Plemmons wrote:
>>
>> I have done more searching in my logs and I see the following
>> errors.
>>
>> This is in the localhost log file /var/lib/pki/pki-tomcat/logs
>>
>> May 15, 2017 3:08:08 PM
>> org.apache.catalina.core.ApplicationContext log
>> SEVERE: StandardWrapper.Throwable
>> java.lang.NullPointerException
>>
>> May 15, 2017 3:08:08 PM org.apache.catalina.core.StandardContext
>> loadOnStartup
>> SEVERE: Servlet [castart] in web application [/ca] threw load()
>> exception
>> java.lang.NullPointerException
>>
>> May 15, 2017 3:08:09 PM
>> org.apache.catalina.core.StandardHostValve invoke
>> SEVERE: Exception Processing /ca/admin/ca/getStatus
>> javax.ws.rs <http://javax.ws.rs>
>> <http://javax.ws.rs>.ServiceUnavailableException: Subsystem
>> unavailable
>>
>>
>> Looking at the debug log it says Authentication failed for port
>> 636.
>>
>> [15/May/2017:17:39:25][localhost-startStop-1]: LdapAuthInfo:
>> init()
>> [15/May/2017:17:39:25][localhost-startStop-1]: LdapAuthInfo:
>> init begins
>> [15/May/2017:17:39:25][localhost-startStop-1]: LdapAuthInfo:
>> init ends
>> [15/May/2017:17:39:25][localhost-startStop-1]: init: before
>> makeConnection errorIfDown is true
>> [15/May/2017:17:39:25][localhost-startStop-1]: makeConnection:
>> errorIfDown true
>> [15/May/2017:17:39:25][localhost-startStop-1]:
>> SSLClientCertificateSelectionCB: Setting desired cert nickname
>> to:
>> subsystemCert cert-pki-ca
>> [15/May/2017:17:39:25][localhost-startStop-1]: LdapJssSSLSocket:
>> set
>> client auth cert nickname subsystemCert cert-pki-ca
>> [15/May/2017:17:39:25][localhost-startStop-1]:
>> SSLClientCertificatSelectionCB: Entering!
>> [15/May/2017:17:39:25][localhost-startStop-1]:
>> SSLClientCertificateSelectionCB: returning: null
>> [15/May/2017:17:39:25][localhost-startStop-1]: SSL handshake
>> happened
>> Could not connect to LDAP server host ipa12.mgmt.crosschx.com
>> <http://ipa12.mgmt.crosschx.com>
>> <http://ipa12.mgmt.crosschx.com
>> <http://ipa12.mgmt.crosschx.com>> port 636 Error
>> netscape.ldap.LDAPException: Authentication failed (48)
>> at
>> com.netscape.cmscore.ldapconn.LdapBoundConnFactory.makeConne
>> ction(LdapBoundConnFactory.java:205)
>>
>>
>> I looked at the validity of the cert it mentions and it is fine.
>>
>> (root)>getcert status -v -d /etc/pki/pki-tomcat/alias -n
>> 'subsystemCert
>> cert-pki-ca'
>> State MONITORING, stuck: no.
>>
>>
>> I then looked at the ldap errors around the time of this failure
>> and I
>> am seeing this log entry.
>>
>>
>> [15/May/2017:17:38:42.063080758 +0000] set_krb5_creds - Could
>> not get
>> initial credentials for principal
>> [ldap/ipa12.mgmt.crosschx.com at MGMT.CROSSCHX.COM
>> <mailto:ipa12.mgmt.crosschx.com at MGMT.CROSSCHX.COM>
>> <mailto:ipa12.mgmt.crosschx.com at MGMT.CROSSCHX.COM
>> <mailto:ipa12.mgmt.crosschx.com at MGMT.CROSSCHX.COM>>] in keytab
>> [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any
>> KDC for
>> requested realm)
>>
>> When I perform a klist against that keytab nothing appears out
>> of the
>> ordinary compared to working IPA servers.
>>
>> I am not sure what to look at next.
>>
>>
>> Hi,
>>
>> you can try the following to manually replay the connection
>> established by Dogtag to LDAP server:
>>
>> root$ export LDAPTLS_CACERTDIR=/etc/pki/pki-tomcat/alias
>> root$ export LDAPTLS_CERT='subsystemCert cert-pki-ca'
>>
>> The above commands specify the NSSDB containing the user certificate
>> and its name for SASL-EXTERNAL authentication.
>>
>> Then note the value obtained below as it will be used for the next
>> step as the password to access the private key in the NSSDB:
>> root$ grep internal /etc/pki/pki-tomcat/password.conf
>> internal=<some value>
>>
>> root$ ldapsearch -H ldaps://`hostname`:636 -b "" -s base -Y EXTERNAL
>> -Q -LLL dn namingcontexts
>> Please enter pin, password, or pass phrase for security token
>> 'ldap(0)': <<<< here supply the value found
>> above
>> dn:
>> namingcontexts: cn=changelog
>> namingcontexts: dc=ipadomain,dc=com
>> namingcontexts: o=ipaca
>>
>>
>>
>> So I guess I found my problem.
>>
>> (root)>ldapsearch -H ldaps://`hostname`:636 -b "" -s base -Y EXTERNAL -Q
>> -LLL dn namingcontexts
>> Please enter pin, password, or pass phrase for security token 'ldap(0)':
>> ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
>> additional info: TLS error -12195:Peer does not recognize and trust
>> the CA that issued your certificate.
>>
>>
>> I looked at our certs in /etc/dirsrv/slapd-IPADOMAIN-COM and found the
>> following.
>>
>> IPA12 - problem server
>> (root)>certutil -L -d /etc/dirsrv/slapd-IPADOMAIN-COM
>>
>> Certificate Nickname Trust
>> Attributes
>>
>> SSL,S/MIME,JAR/XPI
>>
>> Server-Cert u,u,u
>> IPADOMAIN-COM IPA CA C,,
>>
>>
>>
>> IPA11/IPA13 - 11 was the master and 13 is the new master
>> (root)>certutil -L -d /etc/dirsrv/slapd-IPADOMAIN-COM
>>
>> Certificate Nickname Trust
>> Attributes
>>
>> SSL,S/MIME,JAR/XPI
>>
>> Server-Cert u,u,u
>> IPADOMAIN-COM IPA CA CT,C,C
>>
>>
>>
>> Good news! In this case the fix is trivial:
> root$ certutil -M -d /etc/dirsrv/slapd-IPADOMAIN-COM -n 'IPADOMAIN-COM
> IPA CA' -t CT,C,C
>
> Flo.
>
>>
>> In the LDAP server access log (in
>> /etc/dirsrv/slapd-IPADOMAIN.COM/access), you should see the
>> corresponding connection:
>>
>> [18/May/2017:13:35:14.822090417 +0200] conn=297 fd=150 slot=150 SSL
>> connection from xxx to yyy
>> [18/May/2017:13:35:15.789414017 +0200] conn=297 TLS1.2 128-bit
>> AES-GCM; client CN=CA Subsystem,O=IPADOMAIN.COM
>> <http://IPADOMAIN.COM>; issuer CN=Certificate
>> Authority,O=IPADOMAIN.COM <http://IPADOMAIN.COM>
>> [18/May/2017:13:35:15.793108509 +0200] conn=297 TLS1.2 client bound
>> as uid=pkidbuser,ou=people,o=ipaca
>> [18/May/2017:13:35:15.798101505 +0200] conn=297 op=0 BIND dn=""
>> method=sasl version=3 mech=EXTERNAL
>> [18/May/2017:13:35:15.800322076 +0200] conn=297 op=0 RESULT err=0
>> tag=97 nentries=0 etime=0 dn="uid=pkidbuser,ou=people,o=ipaca"
>>
>> HTH,
>> Flo.
>>
>>
>>
>>
>> *Mike Plemmons | Senior DevOps Engineer | CROSSCHX
>> *
>> 614.427.2411
>> mike.plemmons at crosschx.com <mailto:mike.plemmons at crosschx.com>
>> <mailto:mike.plemmons at crosschx.com
>> <mailto:mike.plemmons at crosschx.com>>
>> www.crosschx.com <http://www.crosschx.com>
>> <http://www.crosschx.com/>
>>
>> On Wed, May 10, 2017 at 3:35 PM, Michael Plemmons
>> <michael.plemmons at crosschx.com
>> <mailto:michael.plemmons at crosschx.com>
>> <mailto:michael.plemmons at crosschx.com
>> <mailto:michael.plemmons at crosschx.com>>>
>> wrote:
>>
>> The PKI service came up successfully but only when it uses
>> BasicAuth
>> rather than SSL auth. I am not sure about what I need to do
>> in
>> order to get the auth working over SSL again.
>>
>> None of the certs are expired when I run getcert list and
>> ipa-getcert list.
>>
>> Since the failure is with attempts to login to LDAP over
>> 636. I
>> have been attempting to auth to LDAP via port 636 and the
>> ldapsearch
>> is not completing. When looking at packet captures, I see
>> some the
>> TCP handshake and what appears to be the start of a SSL
>> process and
>> then everything hangs.
>>
>> What is the proper method to test performing a ldapsearch
>> over 636?
>> Also, the CS.cfg shows it wants to auth as cn=Directory
>> Manager. I
>> can successfully auth with cn=Directory Manager over 389 but
>> I think
>> I am not performing ldapsearch over 636 correctly.
>>
>>
>>
>> *Mike Plemmons | Senior DevOps Engineer | CROSSCHX
>> *
>> 614.427.2411
>> mike.plemmons at crosschx.com
>> <mailto:mike.plemmons at crosschx.com>
>> <mailto:mike.plemmons at crosschx.com
>> <mailto:mike.plemmons at crosschx.com>>
>> www.crosschx.com <http://www.crosschx.com>
>> <http://www.crosschx.com/>
>>
>> On Fri, May 5, 2017 at 3:33 PM, Michael Plemmons
>> <michael.plemmons at crosschx.com
>> <mailto:michael.plemmons at crosschx.com>
>> <mailto:michael.plemmons at crosschx.com
>> <mailto:michael.plemmons at crosschx.com>>> wrote:
>>
>> I think I found the email thread. Asking for help with
>> crashed
>> freeIPA istance. That email pointed to this
>> link,
>> https://www.redhat.com/archives/freeipa-users/2017-January/
>> msg00215.html
>> <https://www.redhat.com/archives/freeipa-users/2017-January/
>> msg00215.html>
>>
>> <https://www.redhat.com/archives/freeipa-users/2017-January/
>> msg00215.html
>> <https://www.redhat.com/archives/freeipa-users/2017-January/
>> msg00215.html>>.
>> That link talked about changing the CS.cfg file to use
>> port 389
>> for PKI to auth to LDAP. I made the necessary changes
>> and PKI
>> came up successfully.
>>
>>
>>
>> *Mike Plemmons | Senior DevOps Engineer | CROSSCHX
>> *
>> 614.427.2411
>> mike.plemmons at crosschx.com
>> <mailto:mike.plemmons at crosschx.com>
>> <mailto:mike.plemmons at crosschx.com
>> <mailto:mike.plemmons at crosschx.com>>
>> www.crosschx.com <http://www.crosschx.com>
>> <http://www.crosschx.com/>
>>
>> On Fri, May 5, 2017 at 3:19 PM, Michael Plemmons
>> <michael.plemmons at crosschx.com
>> <mailto:michael.plemmons at crosschx.com>
>> <mailto:michael.plemmons at crosschx.com
>> <mailto:michael.plemmons at crosschx.com>>> wrote:
>>
>>
>>
>>
>>
>> *Mike Plemmons | Senior DevOps Engineer | CROSSCHX
>> *
>> 614.427.2411
>> mike.plemmons at crosschx.com
>> <mailto:mike.plemmons at crosschx.com>
>> <mailto:mike.plemmons at crosschx.com
>> <mailto:mike.plemmons at crosschx.com>>
>> www.crosschx.com <http://www.crosschx.com>
>> <http://www.crosschx.com/>
>>
>> On Fri, May 5, 2017 at 3:15 PM, Rob Crittenden
>> <rcritten at redhat.com <mailto:rcritten at redhat.com>
>> <mailto:rcritten at redhat.com <mailto:rcritten at redhat.com>>> wrote:
>>
>> Michael Plemmons wrote:
>> > I just realized that I sent the reply directly
>> to Rob
>> and not to the
>> > list. My response is inline
>>
>> Ok, this is actually good news.
>>
>> I made a similar proposal in another case and I
>> was
>> completely wrong.
>> Flo had the user do something and it totally
>> fixed their
>> auth error, I
>> just can't remember what it was or find the e-mail
>> thread. I'm pretty
>> sure it was this calendar year though.
>>
>> rob
>>
>>
>> Do you or Flo know what I could search for in the past
>> emails to find the answer to the problem?
>>
>>
>>
>> >
>> >
>> >
>> > *Mike Plemmons | Senior DevOps Engineer |
>> CROSSCHX
>> > *
>> > 614.427.2411
>> > mike.plemmons at crosschx.com
>> <mailto:mike.plemmons at crosschx.com>
>> <mailto:mike.plemmons at crosschx.com
>> <mailto:mike.plemmons at crosschx.com>>
>> <mailto:mike.plemmons at crosschx.com
>> <mailto:mike.plemmons at crosschx.com>
>> <mailto:mike.plemmons at crosschx.com
>> <mailto:mike.plemmons at crosschx.com>>>
>> > www.crosschx.com <http://www.crosschx.com>
>> <http://www.crosschx.com>
>> <http://www.crosschx.com/>
>> >
>> > On Thu, May 4, 2017 at 9:39 AM, Michael Plemmons
>> > <michael.plemmons at crosschx.com
>> <mailto:michael.plemmons at crosschx.com>
>> <mailto:michael.plemmons at crosschx.com
>> <mailto:michael.plemmons at crosschx.com>>
>> <mailto:michael.plemmons at crosschx.com
>> <mailto:michael.plemmons at crosschx.com>
>> <mailto:michael.plemmons at crosschx.com
>> <mailto:michael.plemmons at crosschx.com>>>>
>> > wrote:
>> >
>> >
>> >
>> >
>> >
>> > *Mike Plemmons | Senior DevOps Engineer |
>> CROSSCHX
>> > *
>> > 614.427.2411
>> > mike.plemmons at crosschx.com
>> <mailto:mike.plemmons at crosschx.com>
>> <mailto:mike.plemmons at crosschx.com
>> <mailto:mike.plemmons at crosschx.com>>
>> <mailto:mike.plemmons at crosschx.com
>> <mailto:mike.plemmons at crosschx.com>
>> <mailto:mike.plemmons at crosschx.com
>> <mailto:mike.plemmons at crosschx.com>>>
>> > www.crosschx.com <http://www.crosschx.com>
>> <http://www.crosschx.com>
>> <http://www.crosschx.com/>
>> >
>> > On Thu, May 4, 2017 at 9:24 AM, Rob
>> Crittenden
>> <rcritten at redhat.com
>> <mailto:rcritten at redhat.com> <mailto:rcritten at redhat.com
>> <mailto:rcritten at redhat.com>>
>> > <mailto:rcritten at redhat.com
>> <mailto:rcritten at redhat.com>
>> <mailto:rcritten at redhat.com
>> <mailto:rcritten at redhat.com>>>> wrote:
>> >
>> > Michael Plemmons wrote:
>> > > I realized that I was not very clear
>> in my
>> statement about
>> > testing with
>> > > ldapsearch. I had initially run it
>> without
>> logging in with a
>> > DN. I was
>> > > just running the local ldapsearch -x
>> command. I then tested on
>> > > ipa12.mgmt and ipa11.mgmt logging in
>> with a
>> full DN for the
>> > admin and
>> > > "cn=Directory Manager" from ipa12.mgmt
>> (broken server) and
>> > ipa11.mgmt
>> > > and both ldapsearch command succeeded.
>> > >
>> > > I ran the following from ipa12.mgmt
>> and
>> ipa11.mgmt as a non
>> > root user.
>> > > I also ran the command showing a
>> line count
>> for the output and
>> > the line
>> > > counts for each were the same when
>> run from
>> ipa12.mgmt and
>> > ipa11.mgmt.
>> > >
>> > > ldapsearch -LLL -h
>> ipa12.mgmt.crosschx.com <http://ipa12.mgmt.crosschx.com>
>> <http://ipa12.mgmt.crosschx.com
>> <http://ipa12.mgmt.crosschx.com>>
>> > <http://ipa12.mgmt.crosschx.com
>> <http://ipa12.mgmt.crosschx.com>
>> <http://ipa12.mgmt.crosschx.com
>> <http://ipa12.mgmt.crosschx.com>>>
>> > > <http://ipa12.mgmt.crosschx.com
>> <http://ipa12.mgmt.crosschx.com>
>> <http://ipa12.mgmt.crosschx.com
>> <http://ipa12.mgmt.crosschx.com>>
>> > <http://ipa12.mgmt.crosschx.com
>> <http://ipa12.mgmt.crosschx.com>
>> <http://ipa12.mgmt.crosschx.com
>> <http://ipa12.mgmt.crosschx.com>>>> -D "DN" -w PASSWORD -b
>> > >
>> "cn=users,cn=accounts,dc=mgmt,dc=crosschx,dc=com"
>> dn
>> > >
>> > > ldapsearch -LLL -h
>> ipa12.mgmt.crosschx.com <http://ipa12.mgmt.crosschx.com>
>> <http://ipa12.mgmt.crosschx.com
>> <http://ipa12.mgmt.crosschx.com>>
>> > <http://ipa12.mgmt.crosschx.com
>> <http://ipa12.mgmt.crosschx.com>
>> <http://ipa12.mgmt.crosschx.com
>> <http://ipa12.mgmt.crosschx.com>>>
>> > > <http://ipa12.mgmt.crosschx.com
>> <http://ipa12.mgmt.crosschx.com>
>> <http://ipa12.mgmt.crosschx.com
>> <http://ipa12.mgmt.crosschx.com>>
>> > <http://ipa12.mgmt.crosschx.com
>> <http://ipa12.mgmt.crosschx.com>
>> <http://ipa12.mgmt.crosschx.com
>> <http://ipa12.mgmt.crosschx.com>>>> -D "cn=directory
>> manager" -w
>> > PASSWORD dn
>> >
>> > The CA has its own suffix and
>> replication
>> agreements. Given the auth
>> > error and recent (5 months) renewal of
>> CA
>> credentials I'd check
>> > that the
>> > CA agent authentication entries are
>> correct.
>> >
>> > Against each master with a CA run:
>> >
>> > $ ldapsearch -LLL -x -D 'cn=directory
>> manager'
>> -W -b
>> > uid=ipara,ou=people,o=ipaca description
>> >
>> > The format is 2;serial#,subject,issuer
>> >
>> > Then on each run:
>> >
>> > # certutil -L -d /etc/httpd/alias -n
>> ipaCert
>> |grep Serial
>> >
>> > The serial # should match that in the
>> description everywhere.
>> >
>> > rob
>> >
>> >
>> >
>> > On the CA (IPA13.MGMT) I ran the ldapsearch
>> command and see that the
>> > serial number is 7. I then ran the certutil
>> command on all three
>> > servers and the serial number is 7 as well.
>> >
>> >
>> > I also ran the ldapsearch command against
>> the
>> other two servers and
>> > they also showed a serial number of 7.
>> >
>> >
>> >
>> >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > *Mike Plemmons | Senior DevOps
>> Engineer |
>> CROSSCHX
>> > > *
>> > > 614.427.2411
>> > > mike.plemmons at crosschx.com
>> <mailto:mike.plemmons at crosschx.com>
>> <mailto:mike.plemmons at crosschx.com
>> <mailto:mike.plemmons at crosschx.com>>
>> <mailto:mike.plemmons at crosschx.com
>> <mailto:mike.plemmons at crosschx.com>
>> <mailto:mike.plemmons at crosschx.com
>> <mailto:mike.plemmons at crosschx.com>>>
>> > <mailto:mike.plemmons at crosschx.com
>> <mailto:mike.plemmons at crosschx.com>
>> <mailto:mike.plemmons at crosschx.com
>> <mailto:mike.plemmons at crosschx.com>>
>> > <mailto:mike.plemmons at crosschx.com
>> <mailto:mike.plemmons at crosschx.com>
>> <mailto:mike.plemmons at crosschx.com
>> <mailto:mike.plemmons at crosschx.com>>>>
>> > > www.crosschx.com
>> <http://www.crosschx.com> <http://www.crosschx.com>
>> <http://www.crosschx.com>
>> > <http://www.crosschx.com/>
>> > >
>> > > On Wed, May 3, 2017 at 5:28 PM,
>> Michael Plemmons
>> > > <michael.plemmons at crosschx.com
>> <mailto:michael.plemmons at crosschx.com>
>> <mailto:michael.plemmons at crosschx.com
>> <mailto:michael.plemmons at crosschx.com>>
>> > <mailto:michael.plemmons at crosschx.com
>> <mailto:michael.plemmons at crosschx.com>
>> <mailto:michael.plemmons at crosschx.com
>> <mailto:michael.plemmons at crosschx.com>>>
>> > <mailto:michael.plemmons at crosschx.com
>> <mailto:michael.plemmons at crosschx.com>
>> <mailto:michael.plemmons at crosschx.com
>> <mailto:michael.plemmons at crosschx.com>>
>> > <mailto:michael.plemmons at crosschx.com
>> <mailto:michael.plemmons at crosschx.com>
>> <mailto:michael.plemmons at crosschx.com
>> <mailto:michael.plemmons at crosschx.com>>>>>
>> > > wrote:
>> > >
>> > > I have a three node IPA cluster.
>> > >
>> > > ipa11.mgmt - was a master over 6
>> months ago
>> > > ipa13.mgmt - current master
>> > > ipa12.mgmt
>> > >
>> > > ipa13 has agreements with ipa11
>> and
>> ipa12. ipa11 and
>> > ipa12 do not
>> > > have agreements between each
>> other.
>> > >
>> > > It appears that either
>> ipa12.mgmt lost
>> some level of its
>> > replication
>> > > agreement with ipa13. I saw
>> some level
>> because users /
>> > hosts were
>> > > replicated between all systems
>> but we
>> started seeing DNS
>> > was not
>> > > resolving properly from ipa12.
>> I do not
>> know when this
>> > started.
>> > >
>> > > When looking at replication
>> agreements
>> on ipa12 I did not
>> > see any
>> > > agreement with ipa13.
>> > >
>> > > When I run ipa-replica-manage
>> list all
>> three hosts show
>> > has master.
>> > >
>> > > When I run ipa-replica-manage
>> ipa11.mgmt
>> I see ipa13.mgmt
>> > is a replica.
>> > >
>> > > When I run ipa-replica-manage
>> ipa12.mgmt
>> nothing returned.
>> > >
>> > > I ran ipa-replica-manage connect
>> --cacert=/etc/ipa/ca.crt
>> > > ipa12.mgmt.crosschx.com
>> <http://ipa12.mgmt.crosschx.com>
>> <http://ipa12.mgmt.crosschx.com
>> <http://ipa12.mgmt.crosschx.com>>
>> <http://ipa12.mgmt.crosschx.com
>> <http://ipa12.mgmt.crosschx.com>
>> <http://ipa12.mgmt.crosschx.com
>> <http://ipa12.mgmt.crosschx.com>>>
>> > <http://ipa12.mgmt.crosschx.com
>> <http://ipa12.mgmt.crosschx.com>
>> <http://ipa12.mgmt.crosschx.com
>> <http://ipa12.mgmt.crosschx.com>>
>> <http://ipa12.mgmt.crosschx.com
>> <http://ipa12.mgmt.crosschx.com>
>> <http://ipa12.mgmt.crosschx.com
>> <http://ipa12.mgmt.crosschx.com>>>>
>> > > ipa13.mgmt.crosschx.com
>> <http://ipa13.mgmt.crosschx.com>
>> <http://ipa13.mgmt.crosschx.com
>> <http://ipa13.mgmt.crosschx.com>>
>> <http://ipa13.mgmt.crosschx.com
>> <http://ipa13.mgmt.crosschx.com>
>> <http://ipa13.mgmt.crosschx.com
>> <http://ipa13.mgmt.crosschx.com>>>
>> > <http://ipa13.mgmt.crosschx.com
>> <http://ipa13.mgmt.crosschx.com>
>> <http://ipa13.mgmt.crosschx.com
>> <http://ipa13.mgmt.crosschx.com>>
>> > <http://ipa13.mgmt.crosschx.com
>> <http://ipa13.mgmt.crosschx.com>
>> <http://ipa13.mgmt.crosschx.com
>> <http://ipa13.mgmt.crosschx.com>>>> on ipa12.mgmt
>> > >
>> > > I then ran the following
>> > >
>> > > ipa-replica-manage force-sync
>> --from
>> > ipa13.mgmt.crosschx.com
>> <http://ipa13.mgmt.crosschx.com>
>> <http://ipa13.mgmt.crosschx.com
>> <http://ipa13.mgmt.crosschx.com>>
>> <http://ipa13.mgmt.crosschx.com
>> <http://ipa13.mgmt.crosschx.com>
>> <http://ipa13.mgmt.crosschx.com
>> <http://ipa13.mgmt.crosschx.com>>>
>> > > <http://ipa13.mgmt.crosschx.com
>> <http://ipa13.mgmt.crosschx.com>
>> <http://ipa13.mgmt.crosschx.com
>> <http://ipa13.mgmt.crosschx.com>>
>> > <http://ipa13.mgmt.crosschx.com
>> <http://ipa13.mgmt.crosschx.com>
>> <http://ipa13.mgmt.crosschx.com
>> <http://ipa13.mgmt.crosschx.com>>>>
>> > >
>> > > ipa-replica-manage re-initialize
>> --from
>> > ipa13.mgmt.crosschx.com
>> <http://ipa13.mgmt.crosschx.com>
>> <http://ipa13.mgmt.crosschx.com
>> <http://ipa13.mgmt.crosschx.com>>
>> <http://ipa13.mgmt.crosschx.com
>> <http://ipa13.mgmt.crosschx.com>
>> <http://ipa13.mgmt.crosschx.com
>> <http://ipa13.mgmt.crosschx.com>>>
>> > > <http://ipa13.mgmt.crosschx.com
>> <http://ipa13.mgmt.crosschx.com>
>> <http://ipa13.mgmt.crosschx.com
>> <http://ipa13.mgmt.crosschx.com>>
>> > <http://ipa13.mgmt.crosschx.com
>> <http://ipa13.mgmt.crosschx.com>
>> <http://ipa13.mgmt.crosschx.com
>> <http://ipa13.mgmt.crosschx.com>>>>
>> > >
>> > > I was still seeing bad DNS
>> returns when
>> dig'ing against
>> > ipa12.mgmt.
>> > > I was able to create user and DNS
>> records and see the
>> > information
>> > > replicated properly across all
>> three nodes.
>> > >
>> > > I then ran ipactl stop on
>> ipa12.mgmt and
>> then ipactl start on
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20170518/10ccaa5d/attachment.htm>
More information about the Freeipa-users
mailing list