Re: [Freeipa-users] Could not connect to LDAP server host - IO Error creating JSS SSL Socket:

2017-05-18 Thread Michael Plemmons
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.plemm...@crosschx.com
www.crosschx.com

On Thu, May 18, 2017 at 10:28 AM, Florence Blanc-Renaud <f...@redhat.com>
wrote:

> On 05/18/2017 03:49 PM, Michael Plemmons wrote:
>
>>
>>
>>
>>
>> *Mike Plemmons | Senior DevOps Engineer | CROSSCHX
>> *
>> 614.427.2411
>> mike.plemm...@crosschx.com <mailto:mike.plemm...@crosschx.com>
>> www.crosschx.com <http://www.crosschx.com/>
>>
>> On Thu, May 18, 2017 at 8:02 AM, Florence Blanc-Renaud <f...@redhat.com
>> <mailto:f...@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 +] set_krb5_creds - Could
>> not get
>> initial credentials for principal
>> [ldap/ipa12.mgmt.crosschx@mgmt.crosschx.com
>> <mailto:ipa12.mgmt.crosschx@mgmt.crosschx.com>
>> <mailto:ipa12.mgmt.crosschx@mgmt.crosschx.com
>> <mailto:ipa12.mgmt.crosschx@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 a

Re: [Freeipa-users] Could not connect to LDAP server host - IO Error creating JSS SSL Socket:

2017-05-18 Thread Michael Plemmons
*Mike Plemmons | Senior DevOps Engineer | CROSSCHX*
614.427.2411
mike.plemm...@crosschx.com
www.crosschx.com

On Thu, May 18, 2017 at 8:02 AM, Florence Blanc-Renaud <f...@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>.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> 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 +] set_krb5_creds - Could not get
>> initial credentials for principal
>> [ldap/ipa12.mgmt.crosschx@mgmt.crosschx.com
>> <mailto:ipa12.mgmt.crosschx@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=
>
> 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-IPADOM

Re: [Freeipa-users] Domain Levels

2017-05-11 Thread Michael Plemmons
I got my answer.  I did not have to restart any services.  I ran the
domainlevel-set command on the master and it propagated to all cluster
nodes.  I verified this by running domainlevel-get on each server and they
all showed 1.




*Mike Plemmons | Senior DevOps Engineer | CROSSCHX*
614.427.2411
mike.plemm...@crosschx.com
www.crosschx.com

On Thu, May 11, 2017 at 8:35 AM, Michael Plemmons <
michael.plemm...@crosschx.com> wrote:

> Thank you for the reply.  Is there a specific order I should perform the
> DL upgrade?  Should I upgrade the master first then the replicas?  Does the
> IPA service need to be restarted after the DL upgrade?
>
>
>
>
> *Mike Plemmons | Senior DevOps Engineer | CROSSCHX*
> 614.427.2411
> mike.plemm...@crosschx.com
> www.crosschx.com
>
> On Thu, May 11, 2017 at 4:13 AM, Martin Bašti <mba...@redhat.com> wrote:
>
>>
>>
>> On 10.05.2017 22:42, Michael Plemmons wrote:
>>
>> I am currently running 4.4.0 on a three node cluster.  My domain level is
>> currently 0 on all three nodes.  Is there a reason to keep the domain level
>> at 0?  I do not plan on adding any older versions of IPA into the cluster.
>> Is there anything I need to worry about if I elevate the domain level to 1?
>>
>> My current setup is the server A is the master and B and C are replicas.
>> I do not have replication agreements between B and C and I am looking into
>> creating those agreements.  If I increase the domain level do I have to
>> handle anything differently if I add the B to C replication agreement?
>>
>>
>>
>> *Mike Plemmons | Senior DevOps Engineer | CROSSCHX *
>> 614.427.2411
>> mike.plemm...@crosschx.com
>> www.crosschx.com
>>
>>
>>
>> Hello,
>> we recommend to raise DL to 1, it opens new functionality.
>>
>> With DL1 you can create that replication agreement via webUI, and you
>> will see your replication topology, so no more ipa-replica-manage for
>> connecting replicas.
>>
>> Martin
>>
>> --
>> Martin Bašti
>> Software Engineer
>> Red Hat Czech
>>
>>
>
-- 
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

Re: [Freeipa-users] Domain Levels

2017-05-11 Thread Michael Plemmons
Thank you for the reply.  Is there a specific order I should perform the DL
upgrade?  Should I upgrade the master first then the replicas?  Does the
IPA service need to be restarted after the DL upgrade?




*Mike Plemmons | Senior DevOps Engineer | CROSSCHX*
614.427.2411
mike.plemm...@crosschx.com
www.crosschx.com

On Thu, May 11, 2017 at 4:13 AM, Martin Bašti <mba...@redhat.com> wrote:

>
>
> On 10.05.2017 22:42, Michael Plemmons wrote:
>
> I am currently running 4.4.0 on a three node cluster.  My domain level is
> currently 0 on all three nodes.  Is there a reason to keep the domain level
> at 0?  I do not plan on adding any older versions of IPA into the cluster.
> Is there anything I need to worry about if I elevate the domain level to 1?
>
> My current setup is the server A is the master and B and C are replicas.
> I do not have replication agreements between B and C and I am looking into
> creating those agreements.  If I increase the domain level do I have to
> handle anything differently if I add the B to C replication agreement?
>
>
>
> *Mike Plemmons | Senior DevOps Engineer | CROSSCHX *
> 614.427.2411
> mike.plemm...@crosschx.com
> www.crosschx.com
>
>
>
> Hello,
> we recommend to raise DL to 1, it opens new functionality.
>
> With DL1 you can create that replication agreement via webUI, and you will
> see your replication topology, so no more ipa-replica-manage for connecting
> replicas.
>
> Martin
>
> --
> Martin Bašti
> Software Engineer
> Red Hat Czech
>
>
-- 
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

[Freeipa-users] Domain Levels

2017-05-10 Thread Michael Plemmons
I am currently running 4.4.0 on a three node cluster.  My domain level is
currently 0 on all three nodes.  Is there a reason to keep the domain level
at 0?  I do not plan on adding any older versions of IPA into the cluster.
Is there anything I need to worry about if I elevate the domain level to 1?

My current setup is the server A is the master and B and C are replicas.  I
do not have replication agreements between B and C and I am looking into
creating those agreements.  If I increase the domain level do I have to
handle anything differently if I add the B to C replication agreement?



*Mike Plemmons | Senior DevOps Engineer | CROSSCHX*
614.427.2411
mike.plemm...@crosschx.com
www.crosschx.com
-- 
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

Re: [Freeipa-users] qradar UBA to IPA

2017-05-08 Thread Michael Plemmons
Your listing of the filter seems incorrect unless that is a copy paste
problem.  You probably want cn=users,cn=accounts, $Suffix.  The filter
listed above shows user,cn=accounts,$Suffix.  I am not familiar with Qradar
but does it need just the uid of the user or does it need the full DN of
the user?




*Mike Plemmons | Senior DevOps Engineer | CROSSCHX*
614.427.2411
mike.plemm...@crosschx.com
www.crosschx.com

On Mon, May 8, 2017 at 4:47 PM, Sean Hogan <scho...@us.ibm.com> wrote:

> Thanks Michael,
>
> Yes sir, the qradar box is able to hit the ipa server on 389 and 636 with
> success via telnet.
>
>
>
> Sean Hogan
>
>
>
>
>
>
>
> [image: Inactive hide details for Michael Plemmons ---05/08/2017 01:21:17
> PM--->From the server running Qradar can you ping the IPA ser]Michael
> Plemmons ---05/08/2017 01:21:17 PM--->From the server running Qradar can
> you ping the IPA server? Are you able to telnet to port 389 or
>
> From: Michael Plemmons <michael.plemm...@crosschx.com>
> To: freeipa-users <freeipa-users@redhat.com>
> Date: 05/08/2017 01:21 PM
> Subject: Re: [Freeipa-users] qradar UBA to IPA
> Sent by: freeipa-users-boun...@redhat.com
> --
>
>
>
> From the server running Qradar can you ping the IPA server?  Are you able
> to telnet to port 389 or 636 of the IPA server.  The error says it can't
> contact the LDAP server which usually means you have not gotten to the
> point of authentication yet.
>
>
>
>
> *Mike Plemmons | Senior DevOps Engineer | CROSSCHX*
> 614.427.2411
> *mike.plemm...@crosschx.com* <mike.plemm...@crosschx.com>
> *www.crosschx.com* <http://www.crosschx.com/>
>
> On Mon, May 8, 2017 at 3:31 PM, Sean Hogan <*scho...@us.ibm.com*
> <scho...@us.ibm.com>> wrote:
>
>Hello IPA,
>
>I am trying to set up User Behavioral analytics from Qradar to IPA.
>Having some issues with it after we got 389 and 636 open between the nets.
>
>Qradar Console is not in IPA and on differ net although we do have
>comms on 389 and 636 now
>ipa-server-3.0.0-50.el6.1.x86_64
>
>
>I set up an account in IPA with no HBACS or anything and just gave it
>a IPA role to read data which we use in the below config.
>Getting
>[image:
>
> file:///home/schogan/Documents/SametimeTranscripts/[multi-way]/20170508-100730%7BJUSTIN%20L.%20BAUMAN's%20group%20chat%7D/IMAGE$1CFC0CDDB6F2F123.jpg]
>
>URL I have them using ldaps://*IPofIPAserver.example.com*
><http://ipofipaserver.example.com/>
>BaseDN dc=example,dc=local
>filter users,cn=accounts,$Suffix
>attributes are left default
>username is the user i made in ipa
>pw is the pw I made in ipa
>
>
>[image:
>
> file:///home/schogan/Documents/SametimeTranscripts/[multi-way]/20170508-100730%7BJUSTIN%20L.%20BAUMAN's%20group%20chat%7D/IMAGE$1B778A1810D34E76.jpg]
>
>Has anyone attempted this or have any sample configs to play with or
>see anything I am doing incorrect?
>
>
>
>
>Sean Hogan
>
>
>
>
>
>
>
>--
>Manage your subscription for the Freeipa-users mailing list:
> *https://www.redhat.com/mailman/listinfo/freeipa-users*
><https://www.redhat.com/mailman/listinfo/freeipa-users>
>Go to *http://freeipa.org* <http://freeipa.org/> for more info on the
>project
>
> --
> 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
>
>
>
-- 
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

Re: [Freeipa-users] qradar UBA to IPA

2017-05-08 Thread Michael Plemmons
>From the server running Qradar can you ping the IPA server?  Are you able
to telnet to port 389 or 636 of the IPA server.  The error says it can't
contact the LDAP server which usually means you have not gotten to the
point of authentication yet.





*Mike Plemmons | Senior DevOps Engineer | CROSSCHX*
614.427.2411
mike.plemm...@crosschx.com
www.crosschx.com

On Mon, May 8, 2017 at 3:31 PM, Sean Hogan  wrote:

> Hello IPA,
>
> I am trying to set up User Behavioral analytics from Qradar to IPA. Having
> some issues with it after we got 389 and 636 open between the nets.
>
> Qradar Console is not in IPA and on differ net although we do have comms
> on 389 and 636 now
> ipa-server-3.0.0-50.el6.1.x86_64
>
>
> I set up an account in IPA with no HBACS or anything and just gave it a
> IPA role to read data which we use in the below config.
> Getting
> [image:
> file:///home/schogan/Documents/SametimeTranscripts/[multi-way]/20170508-100730%7BJUSTIN%20L.%20BAUMAN's%20group%20chat%7D/IMAGE$1CFC0CDDB6F2F123.jpg]
>
> URL I have them using ldaps://IPofIPAserver.example.com
> BaseDN dc=example,dc=local
> filter users,cn=accounts,$Suffix
> attributes are left default
> username is the user i made in ipa
> pw is the pw I made in ipa
>
>
> [image:
> file:///home/schogan/Documents/SametimeTranscripts/[multi-way]/20170508-100730%7BJUSTIN%20L.%20BAUMAN's%20group%20chat%7D/IMAGE$1B778A1810D34E76.jpg]
>
> Has anyone attempted this or have any sample configs to play with or see
> anything I am doing incorrect?
>
>
>
>
> Sean Hogan
>
>
>
>
>
>
>
> --
> 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
>
-- 
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

Re: [Freeipa-users] Could not connect to LDAP server host - IO Error creating JSS SSL Socket:

2017-05-05 Thread Michael Plemmons
I just realized that I sent the reply directly to Rob and not to the list.
My response is inline




*Mike Plemmons | Senior DevOps Engineer | CROSSCHX*
614.427.2411
mike.plemm...@crosschx.com
www.crosschx.com

On Thu, May 4, 2017 at 9:39 AM, Michael Plemmons <
michael.plemm...@crosschx.com> wrote:

>
>
>
>
>
> *Mike Plemmons | Senior DevOps Engineer | CROSSCHX*
> 614.427.2411
> mike.plemm...@crosschx.com
> www.crosschx.com
>
> On Thu, May 4, 2017 at 9:24 AM, Rob Crittenden <rcrit...@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> -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> -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.plemm...@crosschx.com <mailto:mike.plemm...@crosschx.com>
>> > www.crosschx.com <http://www.crosschx.com/>
>> >
>> > On Wed, May 3, 2017 at 5:28 PM, Michael Plemmons
>> > <michael.plemm...@crosschx.com <mailto:michael.plemm...@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>
>> > 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>
>> >
>> > ipa-repli

Re: [Freeipa-users] Could not connect to LDAP server host - IO Error creating JSS SSL Socket:

2017-05-03 Thread Michael Plemmons
I also looked at RUVs and here is what I found.  I do not know if anything
here is helpful.

ldapsearch -ZZ -h ipa11.mgmt.crosschx.com -D "cn=Directory Manager" -W -b
"o=ipaca"
"(&(objectclass=nstombstone)(nsUniqueId=---))"
| grep "nsds50ruv\|nsDS5ReplicaId"
nsDS5ReplicaId: 1095
nsds50ruv: {replicageneration} 583445980060
nsds50ruv: {replica 1095 ldap://ipa11.mgmt.crosschx.com:389}
5865323f04470
nsds50ruv: {replica 86 ldap://ipa13.mgmt.crosschx.com:389}
58651fdb0056000
nsds50ruv: {replica 96 ldap://ipa11.mgmt.crosschx.com:389}
5834459c006
nsds50ruv: {replica 91 ldap://ipa13.mgmt.crosschx.com:389}
58344997005b000
nsds50ruv: {replica 97 ldap://ipa12.mgmt.crosschx.com:389}
583445c30061000
nsds50ruv: {replica 81 ldap://ipa12.mgmt.crosschx.com:389}
586529560051000

IPA12 - this is the problem node.
ldapsearch -ZZ -h ipa12.mgmt.crosschx.com -D "cn=Directory Manager" -W -b
"o=ipaca"
"(&(objectclass=nstombstone)(nsUniqueId=---))"
| grep "nsds50ruv\|nsDS5ReplicaId"
nsDS5ReplicaId: 81
nsds50ruv: {replicageneration} 583445980060
nsds50ruv: {replica 81 ldap://ipa12.mgmt.crosschx.com:389}
586529560051000
nsds50ruv: {replica 96 ldap://ipa11.mgmt.crosschx.com:389}
5834459c006
nsds50ruv: {replica 86 ldap://ipa13.mgmt.crosschx.com:389}
58651fdb0056000
nsds50ruv: {replica 91 ldap://ipa13.mgmt.crosschx.com:389}
58344997005b000
nsds50ruv: {replica 97 ldap://ipa12.mgmt.crosschx.com:389}
583445c30061000

ldapsearch -ZZ -h ipa13.mgmt.crosschx.com -D "cn=Directory Manager" -W -b
"o=ipaca"
"(&(objectclass=nstombstone)(nsUniqueId=---))"
| grep "nsds50ruv\|nsDS5ReplicaId"
nsDS5ReplicaId: 86
nsds50ruv: {replicageneration} 583445980060
nsds50ruv: {replica 86 ldap://ipa13.mgmt.crosschx.com:389}
58651fdb0056000
nsds50ruv: {replica 1095 ldap://ipa11.mgmt.crosschx.com:389}
5865323f04470
nsds50ruv: {replica 96 ldap://ipa11.mgmt.crosschx.com:389}
5834459c006
nsds50ruv: {replica 91 ldap://ipa13.mgmt.crosschx.com:389}
58344997005b000
nsds50ruv: {replica 97 ldap://ipa12.mgmt.crosschx.com:389}
583445c30061000
nsds50ruv: {replica 81 ldap://ipa12.mgmt.crosschx.com:389}
586529560051000





*Mike Plemmons | Senior DevOps Engineer | CROSSCHX*
614.427.2411
mike.plemm...@crosschx.com
www.crosschx.com

On Wed, May 3, 2017 at 10:52 PM, Michael Plemmons <
michael.plemm...@crosschx.com> wrote:

> I ran another test.  I started IPA with the ignore service failure option
> and I tired doing ldap searches like this.
>
> ldapsearch -H ldaps://ipa12.mgmt.crosschx.com
>
> from both my laptop and from ipa11.mgmt and I get successful returns when
> logging in as the admin user and as the directory manager.
>
> I then looked closer at the LDAP access logs for the last time I tried to
> start up PKI and got the auth failure and i see this.
>
>
> [04/May/2017:02:22:45.859021005 +] conn=12 fd=101 slot=101 SSL
> connection from 10.71.100.92 to 10.71.100.92
> [04/May/2017:02:22:45.875672450 +] conn=12 TLS1.2 256-bit AES
> [04/May/2017:02:22:45.940908536 +] conn=12 op=0 BIND dn=""
> method=sasl version=3 mech=EXTERNAL
> [04/May/2017:02:22:45.942441120 +] conn=12 op=0 RESULT err=48 tag=97
> nentries=0 etime=0
>
> Is dn="" supposed to be empty?
>
>
>
>
>
>
> *Mike Plemmons | Senior DevOps Engineer | CROSSCHX*
> 614.427.2411
> mike.plemm...@crosschx.com
> www.crosschx.com
>
> On Wed, May 3, 2017 at 10:16 PM, Michael Plemmons <
> michael.plemm...@crosschx.com> 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 -D "DN" -w PASSWORD -b
>> "cn=users,cn=accounts,dc=mgmt,dc=crosschx,dc=com" dn
>>
>> ldapsearch -LLL -h ipa12.mgmt.crosschx.com -D "cn=directory manager" -w
>> PASSWORD dn
>>
>>
>>
>>
>>
>>
>> *Mike Plemmons | Senior DevOps Engineer | CROSSCHX*
>> 614.427.2411
>> mike

Re: [Freeipa-users] Could not connect to LDAP server host - IO Error creating JSS SSL Socket:

2017-05-03 Thread Michael Plemmons
I ran another test.  I started IPA with the ignore service failure option
and I tired doing ldap searches like this.

ldapsearch -H ldaps://ipa12.mgmt.crosschx.com

from both my laptop and from ipa11.mgmt and I get successful returns when
logging in as the admin user and as the directory manager.

I then looked closer at the LDAP access logs for the last time I tried to
start up PKI and got the auth failure and i see this.


[04/May/2017:02:22:45.859021005 +] conn=12 fd=101 slot=101 SSL
connection from 10.71.100.92 to 10.71.100.92
[04/May/2017:02:22:45.875672450 +] conn=12 TLS1.2 256-bit AES
[04/May/2017:02:22:45.940908536 +] conn=12 op=0 BIND dn="" method=sasl
version=3 mech=EXTERNAL
[04/May/2017:02:22:45.942441120 +] conn=12 op=0 RESULT err=48 tag=97
nentries=0 etime=0

Is dn="" supposed to be empty?






*Mike Plemmons | Senior DevOps Engineer | CROSSCHX*
614.427.2411
mike.plemm...@crosschx.com
www.crosschx.com

On Wed, May 3, 2017 at 10:16 PM, Michael Plemmons <
michael.plemm...@crosschx.com> 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 -D "DN" -w PASSWORD -b
> "cn=users,cn=accounts,dc=mgmt,dc=crosschx,dc=com" dn
>
> ldapsearch -LLL -h ipa12.mgmt.crosschx.com -D "cn=directory manager" -w
> PASSWORD dn
>
>
>
>
>
>
> *Mike Plemmons | Senior DevOps Engineer | CROSSCHX*
> 614.427.2411
> mike.plemm...@crosschx.com
> www.crosschx.com
>
> On Wed, May 3, 2017 at 5:28 PM, Michael Plemmons <
> michael.plemm...@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 ipa13.mgmt.crosschx.com on ipa12.mgmt
>>
>> I then ran the following
>>
>> ipa-replica-manage force-sync --from ipa13.mgmt.crosschx.com
>>
>> ipa-replica-manage re-initialize --from 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 ipa12.mgmt
>> because I wanted to make sure everything was running fresh after the
>> changes above.  While IPA was staring up (DNS started) we were able to see
>> valid DNS queries returned but pki-tomcat would not start.
>>
>> I am not sure what I need to do in order to get this working.  I have
>> included the output of certutil and getcert below from all three servers as
>> well as the debug output for pki.
>>
>>
>> While the IPA system is coming up I am able to successfully run
>> ldapsearch -x as the root user and see results.  I am also able to login
>> with the "cn=Directory Manager" account and see results.
>>
>>
>> The debug log shows the following error.
>>
>>
>> [03/May/2017:21:22:01][localhost-startStop-1]:
>> 
>> [03/May/2017:21:22:01][localhost-startStop-1]: =  DEBUG SUBSYSTEM
>> INITIALIZED   ===
>> [03/May/2017:21:22:01][localhost-startStop-1]:
>> =

Re: [Freeipa-users] Could not connect to LDAP server host - IO Error creating JSS SSL Socket:

2017-05-03 Thread Michael Plemmons
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 -D "DN" -w PASSWORD -b
"cn=users,cn=accounts,dc=mgmt,dc=crosschx,dc=com" dn

ldapsearch -LLL -h ipa12.mgmt.crosschx.com -D "cn=directory manager" -w
PASSWORD dn






*Mike Plemmons | Senior DevOps Engineer | CROSSCHX*
614.427.2411
mike.plemm...@crosschx.com
www.crosschx.com

On Wed, May 3, 2017 at 5:28 PM, Michael Plemmons <
michael.plemm...@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 ipa13.mgmt.crosschx.com on ipa12.mgmt
>
> I then ran the following
>
> ipa-replica-manage force-sync --from ipa13.mgmt.crosschx.com
>
> ipa-replica-manage re-initialize --from 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 ipa12.mgmt
> because I wanted to make sure everything was running fresh after the
> changes above.  While IPA was staring up (DNS started) we were able to see
> valid DNS queries returned but pki-tomcat would not start.
>
> I am not sure what I need to do in order to get this working.  I have
> included the output of certutil and getcert below from all three servers as
> well as the debug output for pki.
>
>
> While the IPA system is coming up I am able to successfully run ldapsearch
> -x as the root user and see results.  I am also able to login with the
> "cn=Directory Manager" account and see results.
>
>
> The debug log shows the following error.
>
>
> [03/May/2017:21:22:01][localhost-startStop-1]:
> 
> [03/May/2017:21:22:01][localhost-startStop-1]: =  DEBUG SUBSYSTEM
> INITIALIZED   ===
> [03/May/2017:21:22:01][localhost-startStop-1]:
> 
> [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: restart at
> autoShutdown? false
> [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: autoShutdown
> crumb file path? /var/lib/pki/pki-tomcat/logs/autoShutdown.crumb
> [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: about to look
> for cert for auto-shutdown support:auditSigningCert cert-pki-ca
> [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: found
> cert:auditSigningCert cert-pki-ca
> [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: done init
> id=debug
> [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: initialized
> debug
> [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: initSubsystem
> id=log
> [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: ready to init
> id=log
> [03/May/2017:21:22:01][localhost-startStop-1]: Creating
> RollingLogFile(/var/lib/pki/pki-tomcat/logs/ca/signedAudit/ca_audit)
> [03/May/2017:21:22:01][localhost-startStop-1]: Creating
> RollingLogFile(/var/lib/pki/pki-tomcat/logs/ca/system)
> [03/May/2017:21:22:01][localhost-startStop-1]: Creating
> RollingLogFile(/var/lib/pki/pki-tomcat/logs/ca/transactions)
> [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: restart at
> autoShutdown? false
> [03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: autoShutdown
> crumb file path?

[Freeipa-users] Could not connect to LDAP server host - IO Error creating JSS SSL Socket:

2017-05-03 Thread Michael Plemmons
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 ipa13.mgmt.crosschx.com on ipa12.mgmt

I then ran the following

ipa-replica-manage force-sync --from ipa13.mgmt.crosschx.com

ipa-replica-manage re-initialize --from 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 ipa12.mgmt
because I wanted to make sure everything was running fresh after the
changes above.  While IPA was staring up (DNS started) we were able to see
valid DNS queries returned but pki-tomcat would not start.

I am not sure what I need to do in order to get this working.  I have
included the output of certutil and getcert below from all three servers as
well as the debug output for pki.


While the IPA system is coming up I am able to successfully run ldapsearch
-x as the root user and see results.  I am also able to login with the
"cn=Directory Manager" account and see results.


The debug log shows the following error.


[03/May/2017:21:22:01][localhost-startStop-1]:

[03/May/2017:21:22:01][localhost-startStop-1]: =  DEBUG SUBSYSTEM
INITIALIZED   ===
[03/May/2017:21:22:01][localhost-startStop-1]:

[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: restart at
autoShutdown? false
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: autoShutdown
crumb file path? /var/lib/pki/pki-tomcat/logs/autoShutdown.crumb
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: about to look for
cert for auto-shutdown support:auditSigningCert cert-pki-ca
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: found
cert:auditSigningCert cert-pki-ca
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: done init id=debug
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: initialized debug
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: initSubsystem
id=log
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: ready to init
id=log
[03/May/2017:21:22:01][localhost-startStop-1]: Creating
RollingLogFile(/var/lib/pki/pki-tomcat/logs/ca/signedAudit/ca_audit)
[03/May/2017:21:22:01][localhost-startStop-1]: Creating
RollingLogFile(/var/lib/pki/pki-tomcat/logs/ca/system)
[03/May/2017:21:22:01][localhost-startStop-1]: Creating
RollingLogFile(/var/lib/pki/pki-tomcat/logs/ca/transactions)
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: restart at
autoShutdown? false
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: autoShutdown
crumb file path? /var/lib/pki/pki-tomcat/logs/autoShutdown.crumb
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: about to look for
cert for auto-shutdown support:auditSigningCert cert-pki-ca
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: found
cert:auditSigningCert cert-pki-ca
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: done init id=log
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: initialized log
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: initSubsystem
id=jss
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: ready to init
id=jss
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: restart at
autoShutdown? false
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: autoShutdown
crumb file path? /var/lib/pki/pki-tomcat/logs/autoShutdown.crumb
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: about to look for
cert for auto-shutdown support:auditSigningCert cert-pki-ca
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: found
cert:auditSigningCert cert-pki-ca
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: done init id=jss
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: initialized jss
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: initSubsystem
id=dbs
[03/May/2017:21:22:01][localhost-startStop-1]: CMSEngine: ready to init
id=dbs
[03/May/2017:21:22:01][localhost-startStop-1]: DBSubsystem: init()
 mEnableSerialMgmt=true

Re: [Freeipa-users] LDAP - Load Balancer - SSL cert with SAN

2017-01-03 Thread Michael Plemmons
Maciej,
  Thank you for the information.  I am not terminating at a load balancer.
Originally, I was trying to use a Route53 DNS CNAME entry of
ipa.dev.crosschx.com but we found documentation that says the entry should
be an A record and not a CNAME.  I then created an A record in FreeIPA for
ipa.dev.crosschx.com and pointed the A record to the IP addresses of
ipa-master.dev.crosschx.com and ipa-replica.dev.crosschx.com.

  I guess using the phrase load balancer may be a poor choice here as I am
using FreeIPA DNS as a way to load balance the traffic.




*Mike Plemmons | Senior DevOps Engineer | CROSSCHX*
614-741-5475
mike.plemm...@crosschx.com
www.crosschx.com

On Tue, Jan 3, 2017 at 10:14 AM, Maciej Drobniuch <m...@collective-sense.com>
wrote:

> Hello Mike,
>
> I don't know if I'm aligned with your problem, but generally I was facing
> a SAN cert issue too.
>
> Not sure if you're terminating SSL/TLS on the load balancer or not?
>
> Usually I do SAN certs in IPA via GUI/IdM.
> I am adding a service and hosts assigned to that service.
>
> Every host has an additional https service.
>
> Then I am simply pasting the SAN csr into the host that owns the main
> service and this creates a signed SAN cert that you can upload later to
> your LB.
>
> In simple words the service is assigned to all hosts but those hosts have
> also a service added(this is a hack).
>
> Hope that makes sense and helps solving your problem.
>
> BR
>
> On Thu, Dec 29, 2016 at 10:48 PM, Michael Plemmons <
> michael.plemm...@crosschx.com> wrote:
>
>> I am trying to get FreeIPA LDAP to work when behind a load balancer and
>> using SSL and I do not understand how I am supposed to get the server to
>> use a certificate I created that has a SAN created.
>>
>> FreeIPA 4.4.0 on CentOS 7
>>
>> Here is what I have:
>> ipa-master.dev.crosschx.com - master
>> ipa-replica.dev.crosschx.com - replica
>> ipa.dev.crosschx.com - load balancer DNS name which point to the master
>> and replica servers
>>
>> Here is what I have done.
>> ipa host-add ipa.dev.crosschx.com --random --force
>>
>> ipa service-add --force ldap/ipa.dev.crosschx.com
>>
>> ipa service-add-host ldap/ipa.dev.crosschx.com --hosts={
>> ipa-master.dev.crosschx.com,ipa-replica.dev.crosschx.com}
>>
>> ipa service-allow-retrieve-keytab ldap/ipa.dev.crosschx.com --users=admin
>>
>> ipa-getcert request -d /etc/crosschx -n ipa-load-balancer -N "CN=
>> ipa-master.dev.crosschx.com,O=DEV.CROSSCHX.COM" -D ipa.dev.crosschx.com
>> -K ldap/ipa-master.dev.crosschx.com
>>
>>
>> I can see the certificate is being monitored by IPA when I run
>> ipa-getcert list but I am lost at the step to have this cert put into the
>> database so that IPA will properly respond when I try to connect over LDAPS.
>>
>> I was testing the connection with the following command and I see the the
>> ipa-master.dev cert being served.
>>
>> openssl s_client -connect ipa-master.dev.crosschx.com:636 -servername
>> ipa.dev.crosschx.com
>>
>> Can you point me to the documentation I need to follow?
>>
>> Thank you.
>>
>>
>> *Mike Plemmons | Senior DevOps Engineer | CROSSCHX*
>> 614-741-5475 <(614)%20741-5475>
>> mike.plemm...@crosschx.com
>> www.crosschx.com
>>
>> --
>> 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
>>
>
>
>
> --
> Best regards
>
> Maciej Drobniuch
> Network Security Engineer
> Collective-Sense,LLC
>
-- 
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

[Freeipa-users] LDAP - Load Balancer - SSL cert with SAN

2016-12-29 Thread Michael Plemmons
I am trying to get FreeIPA LDAP to work when behind a load balancer and
using SSL and I do not understand how I am supposed to get the server to
use a certificate I created that has a SAN created.

FreeIPA 4.4.0 on CentOS 7

Here is what I have:
ipa-master.dev.crosschx.com - master
ipa-replica.dev.crosschx.com - replica
ipa.dev.crosschx.com - load balancer DNS name which point to the master and
replica servers

Here is what I have done.
ipa host-add ipa.dev.crosschx.com --random --force

ipa service-add --force ldap/ipa.dev.crosschx.com

ipa service-add-host ldap/ipa.dev.crosschx.com --hosts={
ipa-master.dev.crosschx.com,ipa-replica.dev.crosschx.com}

ipa service-allow-retrieve-keytab ldap/ipa.dev.crosschx.com --users=admin

ipa-getcert request -d /etc/crosschx -n ipa-load-balancer -N "CN=
ipa-master.dev.crosschx.com,O=DEV.CROSSCHX.COM" -D ipa.dev.crosschx.com -K
ldap/ipa-master.dev.crosschx.com


I can see the certificate is being monitored by IPA when I run ipa-getcert
list but I am lost at the step to have this cert put into the database so
that IPA will properly respond when I try to connect over LDAPS.

I was testing the connection with the following command and I see the the
ipa-master.dev cert being served.

openssl s_client -connect ipa-master.dev.crosschx.com:636 -servername
ipa.dev.crosschx.com

Can you point me to the documentation I need to follow?

Thank you.


*Mike Plemmons | Senior DevOps Engineer | CROSSCHX*
614-741-5475
mike.plemm...@crosschx.com
www.crosschx.com
-- 
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

Re: [Freeipa-users] Host with Multiple hostnames

2016-11-28 Thread Michael Plemmons
The error is telling you that a DNS entry already exists for the hostname
you want the CNAME.  A DNS record can only have one record type.  Meaning
is you have 1.2.3.4 points to test.example.com you cannot have
test.example.com also be a CNAME for foo.example.com.



*Mike Plemmons | Senior DevOps Engineer*
614-741-5475
mike.plemm...@crosschx.com
www.crosschx.com

On Mon, Nov 28, 2016 at 1:02 PM, Mike Jacobacci  wrote:

> Hello,
>
> I am sorry for the simple question, but I am using FreeIPA as our DNS
> server and I am trying to figure out how to map a second hostname to a
> host... I am unsure how the best way to go do it. I am just trying to
> give a server a user friendly name for access and I don't want to change
> the system hostname.
>
> I thought I could just add a CNAME entry for the host record, but it fails
> with the following error:
>
> invalid 'cnamerecord': CNAME record is not allowed to coexist with any
> other record (RFC 1034, section 3.6.2)
>
> Is there an easy way I can do this?
>
> Cheers,
> Mike
>
>
>
> --
> 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
>
-- 
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

[Freeipa-users] FreeIPA 3 to FreeIPA 4 migration and Kerberos realm is a forwarded zone

2016-11-18 Thread Michael Plemmons
Hello,

My existing FreeIPA 3.0 (CentOS 6) setup is as follows:

Kerberos Realm: test.com
I have several DNS zones
test.com
dev.test.com
stage.test.com
qa.test.com
prod.test.com
mgmt.test.com

ipa01.mgmt.test.com - FreeIPA 3.0 Master
ipa02.mgmt.test.com - FreeIPA 3.0 Replica

The FreeIPA servers actually reside in mgmt.test.com.  test.com in FreeIPA
3 has forwarding DNS servers configured.

We are going to move to FreeIPA 4.2 (CentOS 7) and here is the path I have
tested that appears to work.

I followed this guide.

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html


1 Create an IPA 4 server (ipa03.mgmt.test.com) that is a replica of the IPA
3 master server (ipa01.mgmt.test.com)
2 Remove replica agreement for ipa02.mgmt.test.com on IPA 3 master (
ipa01.mgmt.test.com)
3 Shutdown ipa02.mgmt.test.com to prep for an IPA 4 server to take its place
4 Build a new server and install IPA 4 server that will become a new
ipa02.mgmt.test.com
5 Make ipa02.mgmt.test.com a replica of ipa03.mgmt.test.com
6 Make ipa02.mgmt.test.com the master CRL server instead of
ipa01.mgmt.test.com
7 Shutdown ipa01.mgmt.test.com to prep for an IPA 4 server to take its place
8 Build a new server and install IPA 4 server that will become a new
ipa01.mgmt.test.com
9 Make ipa01.mgmt.test.com a replica of ipa02.mgmt.test.com

The reason for removing old servers to take the place of new servers is so
that I can reuse the IP addresses and do not need to change DNS entries on
any client

The problem occurs when I realize that the test.com zone needs to be a
forwarded zone in IPA 4 but in IPA 3 is it a normal DNS zone and I need to
have test.com be a forwarded zone.  In IPA 3 there is no entry for
ipa-ca.test.com but I do see it in IPA 4.  In my testing I have removed the
test.com zone and made it a forwarding zone but that removes the entry for
ipa-ca.test.com as well as all the test.com kerberos entries.

What I do not know is what did I break when I removed test.com since it is
the Kerberos realm.  It appears that replication between the servers still
works and I was able to add a IPA 4 client server without issue.  We plan
on using certs generated from IPA 4 for OpenVPN but I do not have enough
information to know if the removal of the test.com zone will break that
certificate validation and revocation since the ipa-ca.test.com DNS entry
no longer exists.

I believe where I went wrong was that I should have setup mgmt.test.com as
the Kerberos realm rather than test.com and I would not have the questions
I do now.

Thank you for your help.

*Mike Plemmons | Senior DevOps Engineer*
614-741-5475
mike.plemm...@crosschx.com
www.crosschx.com
-- 
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