Re: [Freeipa-users] [SOLVED] CA not found?
Hi Fraser, Although I modified the ids to release the data, I made sure to use consistent ids where they appeared. As you noted, there was a discrepancy and changing the 'ipacaid' attribute of cn=ipa,cn=cas,cn=ca,dc=ipa,dc=local to match the authorityID from Dogtag fixed the issue. We're now able to sign certificates as before. Yay!!! As of what could have cause this discrepancy, the only thing I can think of is that, back when we migrated the cluster, there were a few times where the cloning of the CA from 3.x to 4.x failed. Thank you very much for your help with this! I really appreciate it! Have a great time off! Guillermo On Fri, Feb 10, 2017 at 5:03 AM, Fraser Tweedale <ftwee...@redhat.com> wrote: > On Thu, Feb 09, 2017 at 09:01:01PM -0500, Guillermo Fuentes wrote: >> As we're enforcing encryption, here is via ldaps: >> $ ldapsearch -H ldaps://`hostname` -D "cn=Directory Manager" -W -s >> sub -b ou=authorities,ou=ca,o=ipaca Enter LDAP >> Password: >> # extended LDIF >> # >> # LDAPv3 >> # base
Re: [Freeipa-users] CA not found?
As we're enforcing encryption, here is via ldaps: $ ldapsearch -H ldaps://`hostname` -D "cn=Directory Manager" -W -s sub -b ou=authorities,ou=ca,o=ipaca Enter LDAP Password: # extended LDIF # # LDAPv3 # base
Re: [Freeipa-users] CA not found?
Hi Fraser, The cluster was migrated from FreeIPA 3 (CentOS 6) to FreeIPA 4 (CentOS 7) a year ago. - Output of 'ldapsearch -s sub -b ou=authorities,ou=ca,o=ipaca': SASL/EXTERNAL authentication started ldap_sasl_interactive_bind_s: Unknown authentication method (-6) additional info: SASL(-4): no mechanism available: - Output providing GSSAPI mechanism: $ ldapsearch -Y GSSAPI -s sub -b ou=authorities,ou=ca,o=ipaca SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server ldap/localh...@example.com not found in Kerberos database) - Output providing user credentials: $ ldapsearch -D "uid=user1,cn=users,cn=accounts,dc=example,dc=com" -W -H ldaps://`hostname` -s sub -b ou=authorities,ou=ca,o=ipaca Enter LDAP Password: # extended LDIF # # LDAPv3 # base
[Freeipa-users] CA not found?
Hi list,
I'm trying to sign a service certificate but it's failing with "CA not found".
The CA does exist but for some reason the ipa cert-request can't find it:
$ ipa ca-show ipa
Name: ipa
Description: IPA CA
Authority ID: 0cb513ea-6084-4144-a61c-7a0a8368d25c
Subject DN: CN=Certificate Authority,O=EXAMPLE.COM
Issuer DN: CN=Certificate Authority,O=EXAMPLE.COM
This was working in previous versions of freeipa but in our current
environment isn't working:
Cluster of four FreeIPA servers
CentOS Linux release 7.3.1611 (Core)
ipa-client-common-4.4.0-14.el7.centos.4.noarch
ipa-client-4.4.0-14.el7.centos.4.x86_64
ipa-debuginfo-4.2.0-15.0.1.el7_2.6.1.x86_64
ipa-server-trust-ad-4.4.0-14.el7.centos.4.x86_64
ipa-server-4.4.0-14.el7.centos.4.x86_64
ipa-admintools-4.4.0-14.el7.centos.4.noarch
ipa-server-common-4.4.0-14.el7.centos.4.noarch
ipa-common-4.4.0-14.el7.centos.4.noarch
ipa-server-dns-4.4.0-14.el7.centos.4.noarch
ipa-python-compat-4.4.0-14.el7.centos.4.noarch
389-ds-base-1.3.5.10-15.el7_3.x86_64
389-ds-base-libs-1.3.5.10-15.el7_3.x86_64
389-ds-base-snmp-1.3.5.10-15.el7_3.x86_64
389-ds-base-debuginfo-1.3.4.0-30.el7_2.x86_64
pki-base-java-10.3.3-16.el7_3.noarch
pki-base-10.3.3-16.el7_3.noarch
pki-server-10.3.3-16.el7_3.noarch
pki-ca-10.3.3-16.el7_3.noarch
pki-symkey-10.3.3-16.el7_3.x86_64
pki-kra-10.3.3-16.el7_3.noarch
pki-tools-10.3.3-16.el7_3.x86_64
krb5-libs-1.14.1-27.el7_3.x86_64
python-krbV-1.0.90-8.el7.x86_64
pam_krb5-2.4.8-6.el7.x86_64
krb5-workstation-1.14.1-27.el7_3.x86_64
krb5-pkinit-1.14.1-27.el7_3.x86_64
sssd-krb5-common-1.14.0-43.el7_3.11.x86_64
krb5-server-1.14.1-27.el7_3.x86_64
sssd-krb5-1.14.0-43.el7_3.11.x86_64
***
This is the error (same result in all four servers):
$ ipa cert-request --principal=HTTP/host1.example.com host1.example.com.csr
ipa: ERROR: Certificate operation cannot be completed: FAILURE (CA not
found: 0cb513ea-6084-4144-a61c-7a0a8368d25c)
***
>From /var/log/pki/pki-tomcat/ca/debug:
[07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]:
CMSServlet:service() uri = /ca/eeca/ca/profileSubmitSSLClient
[07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]:
CMSServlet::service() param name='xml' value='true'
[07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]:
CMSServlet::service() param name='profileId' value='caIPAserviceCert'
[07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]:
CMSServlet::service() param name='authorityId'
value='0cb513ea-6084-4144-a61c-7a0a8368d25c'
[07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]:
CMSServlet::service() param name='cert_request' value='(sensitive)'
[07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]:
CMSServlet::service() param name='cert_request_type' value='pkcs10'
[07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: CMSServlet:
caProfileSubmitSSLClient start to service.
[07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: xmlOutput true
[07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]:
ProfileSubmitServlet: isRenewal false
[07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: according to
ccMode, authorization for servlet: caProfileSubmit is LDAP based, not
XML {1}, use default authz mgr: {2}.
[07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]:
ProfileSubmitServlet: profile: caIPAserviceCert
CA not found: 0cb513ea-6084-4144-a61c-7a0a8368d25c
at
com.netscape.cms.servlet.profile.ProfileSubmitServlet.processEnrollment(ProfileSubmitServlet.java:239)
at
com.netscape.cms.servlet.profile.ProfileSubmitServlet.process(ProfileSubmitServlet.java:128)
at com.netscape.cms.servlet.base.CMSServlet.service(CMSServlet.java:515)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)
at sun.reflect.GeneratedMethodAccessor72.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:288)
at
org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:285)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAsPrivileged(Subject.java:549)
at
org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:320)
at
org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:175)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:297)
at
org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
at
org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:191)
at
org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:187)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:186)
Re: [Freeipa-users] Getting Minimum SSF not met.
Hi Deepak, What you did was disabling unsecure connections to the directory service. As such, use LDAPS to connect and enable unsecure connections again: ldapmodify -D "cn=directory manager" -W -H ldaps://`hostname` dn: cn=config changetype: modify replace: nsslapd-minssf nsslapd-minssf: 0 If the directory service is stopped, you can edit the attribute in /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif and start the service. Hope it helps, Guillermo GUILLERMO FUENTES SENIOR SYSTEMS ADMINISTRATOR T: 561-880-2998 x1337 E: guillermo.fuen...@modmed.com [image: [ Modernizing Medicine ]] <http://www.modmed.com/> [image: [ Facebook ]] <http://www.facebook.com/modernizingmedicine> [image: [ LinkedIn ]] <http://www.linkedin.com/company/modernizing-medicine/> [image: [ YouTube ]] <http://www.youtube.com/user/modernizingmedicine> [image: [ Twitter ]] <https://twitter.com/modmed_EMA> [image: [ Blog ]] <http://www.modmed.com/BlogBeyondEMR> [image: [ Instagram ]] <http://instagram.com/modernizing_medicine> [image: [ MOMENTUM 2016 ]] <https://www.eventproducers.events/momentum2016> On Thu, Oct 20, 2016 at 8:03 AM, Deepak Dimri <deepak_di...@hotmail.com> wrote: > Hi All, > > > I wanted to enable secure LDAP connection on freeIPA but alas after > changing cn=config > > nsslapd-minssf from 0 to 128 i am getting below error: > > > ipactl restart > > Failed to read data from Directory Service: Unknown error when retrieving > list of services from LDAP: Server is unwilling to perform: Minimum SSF not > met. > > Shutting down > > > When trying to put back the original nsslapd-minssf to "0" i am getting below > error: > > modifying entry "cn=config" > > ldap_modify: Server is unwilling to perform (53) > > additional info: Minimum SSF not met. > > > I tried below configuration but still getting unwilling to perform (53) > Minimum SSF not met Error. > > > dn: cn=config > > changetype: modify > > replace: nsslapd-minssf > > nsslapd-minssf: 10 > > - > > replace: nsslapd-allow-anonymous-access > > nsslapd-allow-anonymous-access: on > > - > > replace: nsslapd-minssf-exclude-rootdse > > nsslapd-minssf-exclude-rootdse: off > > > I am following the steps mentioned here: https://access.redhat.co > m/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Admi > nistration_Guide/SecureConnections.html > Chapter 14. Configuring Secure Connections - Red Hat Support > <https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/SecureConnections.html> > access.redhat.com > By default, clients and users connect to the Red Hat Directory Server over > a standard connection. Standard connections do not use any encryption, so > information is ... > > > How can i get LDAPS working on my FreeIPA? > > > Many Thanks, > > Deepak > > > -- > 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] ns-slapd hangs for 2-3 minutes, then resumes.
Hi all, Did any ipa/sssd developer had a chance to take a look at this issue? Updating to the latest version available for CentOS 7 didn't fix it: ipa-debuginfo-4.2.0-15.0.1.el7_2.6.1.x86_64 ipa-python-4.2.0-15.0.1.el7.centos.17.x86_64 ipa-server-dns-4.2.0-15.0.1.el7.centos.17.x86_64 sssd-ipa-1.13.0-40.el7_2.9.x86_64 python-libipa_hbac-1.13.0-40.el7_2.9.x86_64 ipa-admintools-4.2.0-15.0.1.el7.centos.17.x86_64 ipa-server-4.2.0-15.0.1.el7.centos.17.x86_64 libipa_hbac-1.13.0-40.el7_2.9.x86_64 ipa-server-trust-ad-4.2.0-15.0.1.el7.centos.17.x86_64 ipa-client-4.2.0-15.0.1.el7.centos.17.x86_64 389-ds-base-libs-1.3.4.0-32.el7_2.x86_64 389-ds-base-1.3.4.0-32.el7_2.x86_64 389-ds-base-debuginfo-1.3.4.0-30.el7_2.x86_64 Please let me know if you need more information or how I can help to get it fixed. Thanks so much, Guillermo On Mon, Jun 13, 2016 at 6:30 PM, Rich Megginson <rmegg...@redhat.com> wrote: > On 06/13/2016 01:13 PM, Guillermo Fuentes wrote: > >> Hi Rich, >> >> After I started running the stack traces, the problem hasn't happen as >> frequently as it use to but today I was able to get the stack traces. >> As they aren't similar I'll send them over to you in a separate email. >> >> This is what I did to start the stack traces (CentOS 7): >> # yum install -y --enablerepo=base-debuginfo 389-ds-base-debuginfo >> ipa-debuginfo slapi-nis-debuginfo nspr-debuginfo >> # yum install -y gdb >> # systemctl stop ipa.service ; sleep 10; systemctl start ipa.service >> # mkdir -p /var/log/stacktraces >> >> Setup crontab to run the following every minute: >> gdb -ex 'set confirm off' -ex 'set pagination off' -ex 'thread apply >> all bt full' -ex 'quit' /usr/sbin/ns-slapd `pidof ns-slapd` > >> /var/log/stacktraces/stacktrace.`date +%s`.txt 2>&1 >> > > It looks similar to https://fedorahosted.org/389/ticket/48341 but you > already have that fix. > > One of the problems is that ids_sasl_check_bind acquires the connection > lock and holds it for a very long time, which causes the main loop to block > on that connection, which is similar to the above problem, and also similar > to https://fedorahosted.org/389/ticket/48882. Basically, anything which > holds the connection c_mutex lock too long can hang the server. In your > case, this stack trace: > > poll sss_cli_make_request_nochecks sss_cli_check_socket > sss_pac_make_request sssdpac_verify krb5int_authdata_verify > rd_req_decoded_opt krb5_rd_req_decoded kg_accept_krb5 > krb5_gss_accept_sec_context_ext krb5_gss_accept_sec_context > gss_accept_sec_context gssapi_server_mech_step sasl_server_step > sasl_server_start ids_sasl_check_bind do_bind connection_dispatch_operation > _pt_root start_thread clone > > I'm not sure if this particular situation is known/fixed. Perhaps there > is a way to make the poll() called by sss_cli_make_request_nochecks() have > a smaller timeout? > > Does this look familiar to any ipa/sssd developer? > > > >> Thank you so much for your help, >> >> Guillermo >> >> >> >> >> >> >> On Wed, Jun 1, 2016 at 6:52 PM, Guillermo Fuentes >> <guillermo.fuen...@modernizingmedicine.com> wrote: >> >>> I'm now taking stack traces every minute and waiting for it to hang >>> again to check it. It happens usually under load but it's >>> unpredictable. Must likely tomorrow. >>> GUILLERMO FUENTES >>> SR. SYSTEMS ADMINISTRATOR >>> >>> 561-880-2998 x1337 >>> >>> guillermo.fuen...@modmed.com >>> >>> >>> >>> >>> >>> >>> On Wed, Jun 1, 2016 at 2:03 PM, Rich Megginson <rmegg...@redhat.com> >>> wrote: >>> >>>> On 06/01/2016 10:37 AM, Guillermo Fuentes wrote: >>>> >>>>> Hi all, >>>>> >>>>> We are experiencing a similar issue like the one discussed in the >>>>> following thread but we are running FreeIPA 4.2 on CentOS 7.2: >>>>> >>>>> https://www.redhat.com/archives/freeipa-users/2015-February/msg00205.html >>>>> >>>> >>>> Are your stack traces similar? >>>> >>>> >>>> LDAP service stops responding to queries (hangs). LDAP connections on >>>>> the server climb sometimes up to 10 times the normal amount and load >>>>> goes to 0. Then, the connections start to drop until they get to a >>>>> normal level and the LDAP service starts to respond to queries again. >>>>> This happens in between 3-5 minutes: >>>>> >>>>> Time,LDAP conn, Opened file
Re: [Freeipa-users] ns-slapd hangs for 2-3 minutes, then resumes.
Hi Rich, After I started running the stack traces, the problem hasn't happen as frequently as it use to but today I was able to get the stack traces. As they aren't similar I'll send them over to you in a separate email. This is what I did to start the stack traces (CentOS 7): # yum install -y --enablerepo=base-debuginfo 389-ds-base-debuginfo ipa-debuginfo slapi-nis-debuginfo nspr-debuginfo # yum install -y gdb # systemctl stop ipa.service ; sleep 10; systemctl start ipa.service # mkdir -p /var/log/stacktraces Setup crontab to run the following every minute: gdb -ex 'set confirm off' -ex 'set pagination off' -ex 'thread apply all bt full' -ex 'quit' /usr/sbin/ns-slapd `pidof ns-slapd` > /var/log/stacktraces/stacktrace.`date +%s`.txt 2>&1 Thank you so much for your help, Guillermo On Wed, Jun 1, 2016 at 6:52 PM, Guillermo Fuentes <guillermo.fuen...@modernizingmedicine.com> wrote: > I'm now taking stack traces every minute and waiting for it to hang > again to check it. It happens usually under load but it's > unpredictable. Must likely tomorrow. > GUILLERMO FUENTES > SR. SYSTEMS ADMINISTRATOR > > 561-880-2998 x1337 > > guillermo.fuen...@modmed.com > > > > > > > On Wed, Jun 1, 2016 at 2:03 PM, Rich Megginson <rmegg...@redhat.com> wrote: >> On 06/01/2016 10:37 AM, Guillermo Fuentes wrote: >>> >>> Hi all, >>> >>> We are experiencing a similar issue like the one discussed in the >>> following thread but we are running FreeIPA 4.2 on CentOS 7.2: >>> https://www.redhat.com/archives/freeipa-users/2015-February/msg00205.html >> >> >> Are your stack traces similar? >> >> >>> >>> LDAP service stops responding to queries (hangs). LDAP connections on >>> the server climb sometimes up to 10 times the normal amount and load >>> goes to 0. Then, the connections start to drop until they get to a >>> normal level and the LDAP service starts to respond to queries again. >>> This happens in between 3-5 minutes: >>> >>> Time,LDAP conn, Opened files(ns-slapd), File >>> Desc(ns-slapd),Threads(ns-slapd),Load1,Load5,Load15 >>> 8:54:03,101,353,216,142,0.43,0.20,0.16 >>> 8:55:02,108,359,221,142,0.19,0.18,0.15 >>> 8:56:03,110,361,224,142,0.07,0.15,0.14 >>> 8:57:14,117,383,246,142,0.15,0.16,0.15 >>> 8:58:04,276,371,234,142,0.05,0.13,0.14 >>> 8:59:05,469,371,234,142,0.02,0.11,0.13 >>> 9:00:08,719,371,234,142,0.01,0.09,0.12 >>> 9:01:18,1060,371,234,142,0.00,0.07,0.12 >>> 9:02:10,742,371,233,142,0.10,0.09,0.12 >>> 9:03:06,365,372,235,142,0.13,0.10,0.13 >>> 9:04:04,262,379,242,142,0.87,0.29,0.19 >>> 9:05:02,129,371,233,142,0.51,0.31,0.20 >>> 9:06:03,126,377,240,142,0.42,0.33,0.22 >>> 9:07:03,125,377,238,142,0.17,0.27,0.21 >>> >>> Nothing is logged in the errors log file of the server having the >>> problem (ipa1 as an example). >>> In the replicas this is logged: >>> 8:59:05 -0400] NSMMReplicationPlugin - agmt="cn=meToipa1.example.com" >>> (ipa1:389): Unable to receive the response for a startReplication >>> extended operation to consumer (Timed out). Will retry later. >>> 9:01:05 -0400] NSMMReplicationPlugin - agmt="cn=meToipa1.example.com" >>> (ipa1:389): Unable to receive the response for a startReplication >>> extended operation to consumer (Timed out). Will retry later. >>> >>> Nothing is logged in the access log file until after ns-slapd starts >>> responding again: >>> ... >>> 8:57:00 -0400] conn=12384 fd=234 slot=234 connection from 172.20.0.1 >>> to 172.20.2.45 >>> 8:57:00 -0400] conn=12385 fd=235 slot=235 connection from 172.20.0.1 >>> to 172.20.2.45 >>> 8:57:00 -0400] conn=12386 fd=236 slot=236 connection from 172.20.0.1 >>> to 172.20.2.45 >>> 8:57:00 -0400] conn=12387 fd=237 slot=237 connection from 172.20.0.1 >>> to 172.20.2.45 >>> 8:57:00 -0400] conn=10384 op=1227 EXT oid="2.16.840.1.113730.3.5.12" >>> name="replication-multimaster-extop" >>> 8:57:00 -0400] conn=12324 op=8 RESULT err=0 tag=101 nentries=1 etime=0 >>> 8:57:00 -0400] conn=8838 op=2545 EXT oid="2.16.840.1.113730.3.5.12" >>> name="replication-multimaster-extop" >>> 8:57:00 -0400] conn=8838 op=2545 RESULT err=0 tag=120 nentries=0 etime=0 >>> 8:57:00 -0400] conn=10384 op=1227 RESULT err=0 tag=120 nentries=0 etime=0 >>> 8:57:00 -0400] conn=12382 op=-1 fd=170 closed - B1 >>> 8:57:00 -0400] conn=12383 op=0 SRCH base="" scope=0 >>> filt
Re: [Freeipa-users] ns-slapd hangs for 2-3 minutes, then resumes.
I'm now taking stack traces every minute and waiting for it to hang again to check it. It happens usually under load but it's unpredictable. Must likely tomorrow. GUILLERMO FUENTES SR. SYSTEMS ADMINISTRATOR 561-880-2998 x1337 guillermo.fuen...@modmed.com On Wed, Jun 1, 2016 at 2:03 PM, Rich Megginson <rmegg...@redhat.com> wrote: > On 06/01/2016 10:37 AM, Guillermo Fuentes wrote: >> >> Hi all, >> >> We are experiencing a similar issue like the one discussed in the >> following thread but we are running FreeIPA 4.2 on CentOS 7.2: >> https://www.redhat.com/archives/freeipa-users/2015-February/msg00205.html > > > Are your stack traces similar? > > >> >> LDAP service stops responding to queries (hangs). LDAP connections on >> the server climb sometimes up to 10 times the normal amount and load >> goes to 0. Then, the connections start to drop until they get to a >> normal level and the LDAP service starts to respond to queries again. >> This happens in between 3-5 minutes: >> >> Time,LDAP conn, Opened files(ns-slapd), File >> Desc(ns-slapd),Threads(ns-slapd),Load1,Load5,Load15 >> 8:54:03,101,353,216,142,0.43,0.20,0.16 >> 8:55:02,108,359,221,142,0.19,0.18,0.15 >> 8:56:03,110,361,224,142,0.07,0.15,0.14 >> 8:57:14,117,383,246,142,0.15,0.16,0.15 >> 8:58:04,276,371,234,142,0.05,0.13,0.14 >> 8:59:05,469,371,234,142,0.02,0.11,0.13 >> 9:00:08,719,371,234,142,0.01,0.09,0.12 >> 9:01:18,1060,371,234,142,0.00,0.07,0.12 >> 9:02:10,742,371,233,142,0.10,0.09,0.12 >> 9:03:06,365,372,235,142,0.13,0.10,0.13 >> 9:04:04,262,379,242,142,0.87,0.29,0.19 >> 9:05:02,129,371,233,142,0.51,0.31,0.20 >> 9:06:03,126,377,240,142,0.42,0.33,0.22 >> 9:07:03,125,377,238,142,0.17,0.27,0.21 >> >> Nothing is logged in the errors log file of the server having the >> problem (ipa1 as an example). >> In the replicas this is logged: >> 8:59:05 -0400] NSMMReplicationPlugin - agmt="cn=meToipa1.example.com" >> (ipa1:389): Unable to receive the response for a startReplication >> extended operation to consumer (Timed out). Will retry later. >> 9:01:05 -0400] NSMMReplicationPlugin - agmt="cn=meToipa1.example.com" >> (ipa1:389): Unable to receive the response for a startReplication >> extended operation to consumer (Timed out). Will retry later. >> >> Nothing is logged in the access log file until after ns-slapd starts >> responding again: >> ... >> 8:57:00 -0400] conn=12384 fd=234 slot=234 connection from 172.20.0.1 >> to 172.20.2.45 >> 8:57:00 -0400] conn=12385 fd=235 slot=235 connection from 172.20.0.1 >> to 172.20.2.45 >> 8:57:00 -0400] conn=12386 fd=236 slot=236 connection from 172.20.0.1 >> to 172.20.2.45 >> 8:57:00 -0400] conn=12387 fd=237 slot=237 connection from 172.20.0.1 >> to 172.20.2.45 >> 8:57:00 -0400] conn=10384 op=1227 EXT oid="2.16.840.1.113730.3.5.12" >> name="replication-multimaster-extop" >> 8:57:00 -0400] conn=12324 op=8 RESULT err=0 tag=101 nentries=1 etime=0 >> 8:57:00 -0400] conn=8838 op=2545 EXT oid="2.16.840.1.113730.3.5.12" >> name="replication-multimaster-extop" >> 8:57:00 -0400] conn=8838 op=2545 RESULT err=0 tag=120 nentries=0 etime=0 >> 8:57:00 -0400] conn=10384 op=1227 RESULT err=0 tag=120 nentries=0 etime=0 >> 8:57:00 -0400] conn=12382 op=-1 fd=170 closed - B1 >> 8:57:00 -0400] conn=12383 op=0 SRCH base="" scope=0 >> filter="(objectClass=*)" attrs="supportedSASLMechanisms >> defaultnamingcontext namingContexts schemanamingcontext saslrealm" >> 8:57:00 -0400] conn=12384 op=-1 fd=234 closed - B1 >> 8:57:00 -0400] conn=12385 op=0 SRCH base="" scope=0 >> filter="(objectClass=*)" attrs="supportedSASLMechanisms >> defaultnamingcontext namingContexts schemanamingcontext saslrealm" >> 8:57:00 -0400] conn=12383 op=0 RESULT err=0 tag=101 nentries=1 etime=0 >> 8:57:00 -0400] conn=12386 op=-1 fd=236 closed - B1 >> 8:57:00 -0400] conn=12385 op=0 RESULT err=0 tag=101 nentries=1 etime=0 >> 8:57:00 -0400] conn=12387 op=0 SRCH base="" scope=0 >> filter="(objectClass=*)" attrs="supportedSASLMechanisms >> defaultnamingcontext namingContexts schemanamingcontext saslrealm" >> 8:57:00 -0400] conn=12387 op=0 RESULT err=0 tag=101 nentries=1 etime=0 >> 8:57:00 -0400] conn=12385 op=1 BIND dn="" method=sasl version=3 >> mech=GSSAPI >> 8:57:00 -0400] conn=12387 op=1 BIND dn="" method=sasl version=3 >> mech=GSSAPI >> 8:57:00 -0400] conn=12385 op=1 RESULT err=14 tag=97 nentries=0 >> etime=0,
[Freeipa-users] ns-slapd hangs for 2-3 minutes, then resumes.
Hi all, We are experiencing a similar issue like the one discussed in the following thread but we are running FreeIPA 4.2 on CentOS 7.2: https://www.redhat.com/archives/freeipa-users/2015-February/msg00205.html LDAP service stops responding to queries (hangs). LDAP connections on the server climb sometimes up to 10 times the normal amount and load goes to 0. Then, the connections start to drop until they get to a normal level and the LDAP service starts to respond to queries again. This happens in between 3-5 minutes: Time,LDAP conn, Opened files(ns-slapd), File Desc(ns-slapd),Threads(ns-slapd),Load1,Load5,Load15 8:54:03,101,353,216,142,0.43,0.20,0.16 8:55:02,108,359,221,142,0.19,0.18,0.15 8:56:03,110,361,224,142,0.07,0.15,0.14 8:57:14,117,383,246,142,0.15,0.16,0.15 8:58:04,276,371,234,142,0.05,0.13,0.14 8:59:05,469,371,234,142,0.02,0.11,0.13 9:00:08,719,371,234,142,0.01,0.09,0.12 9:01:18,1060,371,234,142,0.00,0.07,0.12 9:02:10,742,371,233,142,0.10,0.09,0.12 9:03:06,365,372,235,142,0.13,0.10,0.13 9:04:04,262,379,242,142,0.87,0.29,0.19 9:05:02,129,371,233,142,0.51,0.31,0.20 9:06:03,126,377,240,142,0.42,0.33,0.22 9:07:03,125,377,238,142,0.17,0.27,0.21 Nothing is logged in the errors log file of the server having the problem (ipa1 as an example). In the replicas this is logged: 8:59:05 -0400] NSMMReplicationPlugin - agmt="cn=meToipa1.example.com" (ipa1:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. 9:01:05 -0400] NSMMReplicationPlugin - agmt="cn=meToipa1.example.com" (ipa1:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later. Nothing is logged in the access log file until after ns-slapd starts responding again: ... 8:57:00 -0400] conn=12384 fd=234 slot=234 connection from 172.20.0.1 to 172.20.2.45 8:57:00 -0400] conn=12385 fd=235 slot=235 connection from 172.20.0.1 to 172.20.2.45 8:57:00 -0400] conn=12386 fd=236 slot=236 connection from 172.20.0.1 to 172.20.2.45 8:57:00 -0400] conn=12387 fd=237 slot=237 connection from 172.20.0.1 to 172.20.2.45 8:57:00 -0400] conn=10384 op=1227 EXT oid="2.16.840.1.113730.3.5.12" name="replication-multimaster-extop" 8:57:00 -0400] conn=12324 op=8 RESULT err=0 tag=101 nentries=1 etime=0 8:57:00 -0400] conn=8838 op=2545 EXT oid="2.16.840.1.113730.3.5.12" name="replication-multimaster-extop" 8:57:00 -0400] conn=8838 op=2545 RESULT err=0 tag=120 nentries=0 etime=0 8:57:00 -0400] conn=10384 op=1227 RESULT err=0 tag=120 nentries=0 etime=0 8:57:00 -0400] conn=12382 op=-1 fd=170 closed - B1 8:57:00 -0400] conn=12383 op=0 SRCH base="" scope=0 filter="(objectClass=*)" attrs="supportedSASLMechanisms defaultnamingcontext namingContexts schemanamingcontext saslrealm" 8:57:00 -0400] conn=12384 op=-1 fd=234 closed - B1 8:57:00 -0400] conn=12385 op=0 SRCH base="" scope=0 filter="(objectClass=*)" attrs="supportedSASLMechanisms defaultnamingcontext namingContexts schemanamingcontext saslrealm" 8:57:00 -0400] conn=12383 op=0 RESULT err=0 tag=101 nentries=1 etime=0 8:57:00 -0400] conn=12386 op=-1 fd=236 closed - B1 8:57:00 -0400] conn=12385 op=0 RESULT err=0 tag=101 nentries=1 etime=0 8:57:00 -0400] conn=12387 op=0 SRCH base="" scope=0 filter="(objectClass=*)" attrs="supportedSASLMechanisms defaultnamingcontext namingContexts schemanamingcontext saslrealm" 8:57:00 -0400] conn=12387 op=0 RESULT err=0 tag=101 nentries=1 etime=0 8:57:00 -0400] conn=12385 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI 8:57:00 -0400] conn=12387 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI 8:57:00 -0400] conn=12385 op=1 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress 8:57:00 -0400] conn=12383 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI 8:57:00 -0400] conn=10384 op=1228 EXT oid="2.16.840.1.113730.3.5.5" name="Netscape Replication End Session" 8:57:00 -0400] conn=10384 op=1228 RESULT err=0 tag=120 nentries=0 etime=0 8:57:00 -0400] conn=12383 op=1 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress 9:02:00 -0400] conn=12388 fd=170 slot=170 connection from 172.20.0.1 to 172.20.2.45 9:02:00 -0400] conn=12389 fd=234 slot=234 SSL connection from 172.20.0.24 to 172.20.2.45 9:02:00 -0400] conn=12390 fd=236 slot=236 connection from local to /var/run/slapd-EXAMPLE-COM.socket 9:02:00 -0400] conn=12391 fd=238 slot=238 connection from 172.20.0.1 to 172.20.2.45 9:02:00 -0400] conn=12392 fd=239 slot=239 SSL connection from 172.20.0.24 to 172.20.2.45 9:02:00 -0400] conn=12393 fd=240 slot=240 connection from local to /var/run/slapd-EXAMPLE-COM.socket 9:02:00 -0400] conn=12394 fd=241 slot=241 connection from 172.20.0.1 to 172.20.2.45 9:02:00 -0400] conn=12395 fd=242 slot=242 SSL connection from 172.20.0.24 to 172.20.2.45 9:02:00 -0400] conn=12396 fd=243 slot=243 connection from 172.20.0.1 to 172.20.2.45 9:02:00 -0400] conn=12397 fd=244 slot=244 SSL connection from 172.20.0.24 to 172.20.2.45 9:02:00 -0400] conn=12398 fd=245 slot=245 connection from
Re: [Freeipa-users] LDAP server failover via altServer attribute?
This is great info Razvan. Thanks for sharing it!
We provision Macs by pushing configuration scripts via Munki.
Can you point me where I can find more documentation about this?
Thanks again,
Guillermo
On Fri, May 20, 2016 at 3:45 PM, "Răzvan Corneliu C.R. VILT" <
razvan.v...@me.com> wrote:
> Hi guys,
>
> Regarding the Macs, there are a few notes:
>
> 1) The template kerberos setup can be pushed through LDAP
> (cn=KerberosClient and cn=KerberosKDC,cn=config)
> 2) The LDAP replicas can be also configured in cn=config and it is cached
> by OpenDirectory in the following format:
>
> dn: cn=ldapreplicas, cn=config, dc=example, dc=com
> objectClass: apple-configuration
> apple-ldap-replica: ldap://192.168.1.1
> apple-ldap-replica: ldap://192.168.2.2
> apple-ldap-writable-replica: ldap://192.168.1.1
> apple-ldap-writable-replica: ldap://192.168.2.2
> apple-xml-plist: base64 encode of:
> -
>
> http://www.apple.com/DTDs/PropertyList-1.0.dtd;>
>
>
> GUID
> 01234567-89AB-CDEF-0123-456789ABCDEF
> IPaddresses
>
> 192.168.1.1
> 10.0.0.1
>
> PrimaryMaster
> ipa-server.example.org
> ReplicaName
> Master
> Replicas
>
>ipa-bkserver.example.org
>
>
>
>
> --
>
> 3) The main problem with FreeIPA and Mac OS X comes from the SSL part (CRL
> and/or OCSP are enforced). IPA refuses PLAIN authentication on SSL.
>
>
> If you do this manually instead of OpenDirectory compatible way, your
> machine doesn't create an account for itself in IPA so service access
> without login are not available, it doesn't download the root CA
> automatically and you don't get SSO out of the box.
>
>
> On 20 mai 2016, at 22:13, Guillermo Fuentes <
> guillermo.fuen...@modernizingmedicine.com> wrote:
>
> SRV record failover works for Kerberos on the Mac. Setting "dns_lookup_kdc
> = yes" and removing the KDC server ("kdc = xxx") entries from the
> /Library/Preferences/edu.mit.Kerberos config file does the trick.
>
> For LDAP, although you can enable it, I can't see it documented anywhere
> so I'm assuming that isn't the recommended way for the Mac. This can be
> enabled by running this for the LDAP server you're using:
> sudo odutil set configuration /LDAPv3/ipa1.example.com module ldap option
> "Use DNS replicas" "true"
>
> Adding the altServer values with the Directory Manager credentials worked
> and I'm happy to report that the failover on the Mac works great with
> FreeIPA!
>
> As suggested by Rob, for three servers, on server ipa1:
> $ ldapmodify -x -D 'cn=directory manager' -W
> Enter LDAP Password:
> dn:
> changetype: modify
> add: altServer
> altServer: ldap://ipa2.example.com
> -
> add: altServer
> altServer: ldap://ipa3.example.com
>
> modifying entry ""
> ^D
>
> The altServer values didn't replicate so I had to add them to each of the
> FreeIPA servers.
>
> Then, tell the Mac (testing on OS X v10.11.5) to use the altServer
> attribute to look for replicas in case of failover:
> sudo odutil set configuration /LDAPv3/ipa1.example.com module ldap option
> "Use altServer replicas" "true"
>
> And, viola! Highly available authentication with a FreeIPA cluster for the
> Mac!
>
> Thanks so much for your help!
> Guillermo
>
>
> On Fri, May 20, 2016 at 10:38 AM, Rob Crittenden <rcrit...@redhat.com>
> wrote:
>
>> Martin Basti wrote:
>>
>>> Hello,
>>>
>>> IPA uses SRV records for failover to another replica/LDAP.
>>>
>>> I don't know how it works on MACs, but in case that there is no
>>> possibility to use SRV, you may need to file a RFE ticket
>>> (https://fedorahosted.org/freeipa/newticket)
>>>
>>
>> Agreed, SRV records are the preferred mechanism. I was curious though so
>> played with this a bit and it is possible to add altServer values:
>>
>> $ ldapmodify -x -D 'cn=directory manager' -W
>> Enter LDAP Password:
>> dn:
>> changetype: modify
>> add: altServer
>> altServer: ldap://gyre.example.com
>>
>> modifying entry ""
>> ^D
>>
>> $ ldapsearch -LLL -x -b "" -s base altServer
>> dn:
>> altServer: ldap://gyre.example.com
>>
>> My test rig is a single master so I don't know if this replicates or not.
>>
>> rob
>>
>>
>>> Martin
>>>
>>>
>>> On 19.05.2016 17:43, Guillermo Fuentes wrote:
>>>
>>>> Hello all,
>>>>
>>>> As OS X allows LDAP server failover
Re: [Freeipa-users] LDAP server failover via altServer attribute?
SRV record failover works for Kerberos on the Mac. Setting "dns_lookup_kdc
= yes" and removing the KDC server ("kdc = xxx") entries from the
/Library/Preferences/edu.mit.Kerberos config file does the trick.
For LDAP, although you can enable it, I can't see it documented anywhere so
I'm assuming that isn't the recommended way for the Mac. This can be
enabled by running this for the LDAP server you're using:
sudo odutil set configuration /LDAPv3/ipa1.example.com module ldap option
"Use DNS replicas" "true"
Adding the altServer values with the Directory Manager credentials worked
and I'm happy to report that the failover on the Mac works great with
FreeIPA!
As suggested by Rob, for three servers, on server ipa1:
$ ldapmodify -x -D 'cn=directory manager' -W
Enter LDAP Password:
dn:
changetype: modify
add: altServer
altServer: ldap://ipa2.example.com
-
add: altServer
altServer: ldap://ipa3.example.com
modifying entry ""
^D
The altServer values didn't replicate so I had to add them to each of the
FreeIPA servers.
Then, tell the Mac (testing on OS X v10.11.5) to use the altServer
attribute to look for replicas in case of failover:
sudo odutil set configuration /LDAPv3/ipa1.example.com module ldap option
"Use altServer replicas" "true"
And, viola! Highly available authentication with a FreeIPA cluster for the
Mac!
Thanks so much for your help!
Guillermo
On Fri, May 20, 2016 at 10:38 AM, Rob Crittenden <rcrit...@redhat.com>
wrote:
> Martin Basti wrote:
>
>> Hello,
>>
>> IPA uses SRV records for failover to another replica/LDAP.
>>
>> I don't know how it works on MACs, but in case that there is no
>> possibility to use SRV, you may need to file a RFE ticket
>> (https://fedorahosted.org/freeipa/newticket)
>>
>
> Agreed, SRV records are the preferred mechanism. I was curious though so
> played with this a bit and it is possible to add altServer values:
>
> $ ldapmodify -x -D 'cn=directory manager' -W
> Enter LDAP Password:
> dn:
> changetype: modify
> add: altServer
> altServer: ldap://gyre.example.com
>
> modifying entry ""
> ^D
>
> $ ldapsearch -LLL -x -b "" -s base altServer
> dn:
> altServer: ldap://gyre.example.com
>
> My test rig is a single master so I don't know if this replicates or not.
>
> rob
>
>
>> Martin
>>
>>
>> On 19.05.2016 17:43, Guillermo Fuentes wrote:
>>
>>> Hello all,
>>>
>>> As OS X allows LDAP server failover via the altServer attribute
>>> (RFC4512) from RootDSE, it would be great to be able to configure our
>>> Macs to connect to a single FreeIPA server and add other FreeIPA
>>> servers as multiple altServer values.
>>> The current schema doesn't seem to support adding this attribute.
>>> Can this be done in a way I'm missing?
>>>
>>> Thanks in advance!
>>>
>>> GUILLERMO FUENTES
>>> SR. SYSTEMS ADMINISTRATOR
>>>
>>> 561-880-2998 x1337
>>>
>>> guillermo.fuen...@modmed.com <mailto:guillermo.fuen...@modmed.com>
>>>
>>>
>>> [ Modernizing Medicine ] <http://www.modmed.com/>
>>> [ Facebook ] <http://www.facebook.com/modernizingmedicine>
>>> [
>>> LinkedIn ] <http://www.linkedin.com/company/modernizing-medicine/>
>>> [
>>> YouTube ] <http://www.youtube.com/user/modernizingmedicine>
>>> [
>>> Twitter ] <https://twitter.com/modmed_EMA> [ Blog ]
>>> <http://www.modmed.com/BlogBeyondEMR> [ Instagram ]
>>> <http://instagram.com/modernizing_medicine>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
--
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 server failover via altServer attribute?
Hello all, As OS X allows LDAP server failover via the altServer attribute (RFC4512) from RootDSE, it would be great to be able to configure our Macs to connect to a single FreeIPA server and add other FreeIPA servers as multiple altServer values. The current schema doesn't seem to support adding this attribute. Can this be done in a way I'm missing? Thanks in advance! GUILLERMO FUENTES SR. SYSTEMS ADMINISTRATOR 561-880-2998 x1337 guillermo.fuen...@modmed.com [image: [ Modernizing Medicine ]] <http://www.modmed.com/> [image: [ Facebook ]] <http://www.facebook.com/modernizingmedicine> [image: [ LinkedIn ]] <http://www.linkedin.com/company/modernizing-medicine/> [image: [ YouTube ]] <http://www.youtube.com/user/modernizingmedicine> [image: [ Twitter ]] <https://twitter.com/modmed_EMA> [image: [ Blog ]] <http://www.modmed.com/BlogBeyondEMR> [image: [ Instagram ]] <http://instagram.com/modernizing_medicine> -- 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] stubborn old replicas
on the project -- Guillermo Fuentes Rodriguez Computer Systems Analyst (561) 880-2998 x1337 guillermo.fuen...@modmed.com [image: [ Modernizing Medicine ]] http://www.modmed.com [image: [ Facebook ]] http://www.facebook.com/modernizingmedicine [image: [ LinkedIn ]] http://www.linkedin.com/company/modernizing-medicine/ [image: [ YouTube ]] http://www.youtube.com/user/modernizingmedicine [image: [ Twitter ]] https://twitter.com/modmed_EMA [image: [ Blog ]] http://www.modmed.com/BlogBeyondEMR [image: [ Instagram ]] http://instagram.com/modernizing_medicine -- 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] Another Migration from 3.0 (CentOS 6.6) to 4.1 (CentOS 7.1)
On Wed, Jul 29, 2015 at 11:25 AM, Lukas Slebodnik lsleb...@redhat.com wrote: On (29/07/15 10:52), Guillermo Fuentes wrote: Thanks so much for the info David! We're using the latest version available via EPEL, which is 10.1.2. pki-core is not available in epel7 https://admin.fedoraproject.org/pkgdb/package/pki-core/ So you have the latest version from base CentOS 7.1 CentOS rebuild rhel packages. So you will need to wait for CentOS 7.2 for update. Thanks for clarifying this. List, any idea where to grab pki 10.2.6 for CentOS 7? Source or binary would be fine. Or, if it isn't available, where can I start contributing to the port of pki 10.2.6 to CentOS 7? You might try to backport pki-core from Fedora. Good luck. LS Best, Guillermo -- 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] Another Migration from 3.0 (CentOS 6.6) to 4.1 (CentOS 7.1)
Hi all,
We're also trying to migrate from 3.0 (CentOS 6.6) to 4.1 (CentOS 7.1).
Starting with FreeIPA 3.0 and to avoid the SSL certificate warning
when accessing the GUI, we installed a 3rd part certificate for https:
https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP
We're ready to migrate to FreeIPA 4.1 and we already have two 4.1
replicas but we're having problems cloning the CA from the 3.0 master.
This is our current environment:
master1 and master2:
CentOS 6.6 (up to date)
ipa-admintools-3.0.0-42.el6.centos.x86_64
ipa-server-3.0.0-42.el6.centos.x86_64
python-iniparse-0.3.1-2.1.el6.noarch
ipa-pki-common-theme-9.0.3-7.el6.noarch
libipa_hbac-1.11.6-30.el6_6.4.x86_64
device-mapper-multipath-0.4.9-80.el6_6.3.x86_64
ipa-client-3.0.0-42.el6.centos.x86_64
ipa-server-selinux-3.0.0-42.el6.centos.x86_64
ipa-python-3.0.0-42.el6.centos.x86_64
ipa-pki-ca-theme-9.0.3-7.el6.noarch
sssd-ipa-1.11.6-30.el6_6.4.x86_64
pki-selinux-9.0.3-39.el6_6.noarch
pki-common-9.0.3-39.el6_6.noarch
pki-native-tools-9.0.3-39.el6_6.x86_64
pki-setup-9.0.3-39.el6_6.noarch
pki-util-9.0.3-39.el6_6.noarch
pki-symkey-9.0.3-39.el6_6.x86_64
pki-ca-9.0.3-39.el6_6.noarch
pki-java-tools-9.0.3-39.el6_6.noarch
ipa-pki-ca-theme-9.0.3-7.el6.noarch
pki-silent-9.0.3-39.el6_6.noarch
replica1 and replica2:
CentOS 7.1 (up to date)
ipa-client-4.1.0-18.el7.centos.3.x86_64
libipa_hbac-python-1.12.2-58.el7_1.6.x86_64
sssd-ipa-1.12.2-58.el7_1.6.x86_64
python-iniparse-0.4-9.el7.noarch
ipa-admintools-4.1.0-18.el7.centos.3.x86_64
ipa-server-4.1.0-18.el7.centos.3.x86_64
ipa-python-4.1.0-18.el7.centos.3.x86_64
libipa_hbac-1.12.2-58.el7_1.6.x86_64
pki-server-10.1.2-7.el7.noarch
krb5-pkinit-1.12.2-14.el7.x86_64
pki-base-10.1.2-7.el7.noarch
pki-ca-10.1.2-7.el7.noarch
pki-symkey-10.1.2-7.el7.x86_64
pki-tools-10.1.2-7.el7.x86_64
# ipa-replica-manage list
master1.example.com: master
master2.example.com: master
replica1.example.com: master
replica2.example.com.com: master
# ipa-csreplica-manage list
Directory Manager password:
replica1.example.com: CA not configured
master1.example.com: master
master2.example.com: master
replica2.example.com: CA not configured
When trying to install the CA on replica1 to do the migration:
ipa-ca-install --skip-conncheck --skip-schema-check
/var/lib/ipa/replica-info-replica1.example.com.gpg
we're getting the following error in the
/var/log/ipareplica-ca-install.log file:
...
2015-07-28T21:25:14Z DEBUG Saving StateFile to
'/var/lib/ipa/sysrestore/sysrestore.state'
2015-07-28T21:25:14Z DEBUG Starting external process
2015-07-28T21:25:14Z DEBUG args='/usr/sbin/pkispawn' '-s' 'CA' '-f'
'/tmp/tmp2ON_ql'
2015-07-28T21:25:51Z DEBUG Process finished, return code=1
2015-07-28T21:25:51Z DEBUG stdout=Loading deployment configuration
from /tmp/tmp2ON_ql.
Installing CA into /var/lib/pki/pki-tomcat.
Storing deployment configuration into
/etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg.
Installation failed.
2015-07-28T21:25:51Z DEBUG
stderr=/usr/lib/python2.7/site-packages/urllib3/connectionpool.py:771:
InsecureRequestWarning: Unverified HTTPS request is being made. Adding
certificate verification is strongly advised. See:
https://urllib3.readthedocs.org/en/latest/security.html
InsecureRequestWarning)
pkispawn: WARNING ... unable to validate security domain
user/password through REST interface. Interface not available
pkispawn: ERROR... Exception from Java Configuration
Servlet: Failed to obtain configuration entries from the master for
cloning java.io.IOException: Error: Not authorized
2015-07-28T21:25:51Z CRITICAL failed to configure ca instance Command
''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmp2ON_ql'' returned
non-zero exit status 1
2015-07-28T21:25:51Z DEBUG Traceback (most recent call last):
File /usr/lib/python2.7/site-packages/ipaserver/install/service.py,
line 382, in start_creation
run_step(full_msg, method)
File /usr/lib/python2.7/site-packages/ipaserver/install/service.py,
line 372, in run_step
method()
File /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,
line 673, in __spawn_instance
raise RuntimeError('Configuration of CA failed')
RuntimeError: Configuration of CA failed
...
From /var/log/pki/pki-ca-spawn.20150728172515.log:
...
2015-07-28 17:25:16 pkispawn: INFO ... executing 'certutil
-N -d /tmp/tmp-eUbMVB -f /root/.dogtag/pki-tomcat/ca/password.conf'
2015-07-28 17:25:16 pkispawn: INFO ... executing
'systemctl daemon-reload'
2015-07-28 17:25:16 pkispawn: INFO ... executing
'systemctl start pki-tomcatd@pki-tomcat.service'
2015-07-28 17:25:16 pkispawn: DEBUG... No connection -
server may still be down
2015-07-28 17:25:16 pkispawn: DEBUG... No connection -
exception thrown: ('Connection aborted.', error(111, 'Connection
refused'))
2015-07-28 17:25:17 pkispawn: DEBUG... No connection -
server may still be down
2015-07-28 17:25:17 pkispawn: DEBUG
Re: [Freeipa-users] Another Migration from 3.0 (CentOS 6.6) to 4.1 (CentOS 7.1)
Thanks so much for the info David!
We're using the latest version available via EPEL, which is 10.1.2.
List, any idea where to grab pki 10.2.6 for CentOS 7? Source or binary
would be fine. Or, if it isn't available, where can I start
contributing to the port of pki 10.2.6 to CentOS 7?
Thanks!
Guillermo
On Wed, Jul 29, 2015 at 9:13 AM, David Kupka dku...@redhat.com wrote:
On 29/07/15 01:47, Guillermo Fuentes wrote:
Hi all,
We're also trying to migrate from 3.0 (CentOS 6.6) to 4.1 (CentOS 7.1).
Starting with FreeIPA 3.0 and to avoid the SSL certificate warning
when accessing the GUI, we installed a 3rd part certificate for https:
https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP
We're ready to migrate to FreeIPA 4.1 and we already have two 4.1
replicas but we're having problems cloning the CA from the 3.0 master.
This is our current environment:
master1 and master2:
CentOS 6.6 (up to date)
ipa-admintools-3.0.0-42.el6.centos.x86_64
ipa-server-3.0.0-42.el6.centos.x86_64
python-iniparse-0.3.1-2.1.el6.noarch
ipa-pki-common-theme-9.0.3-7.el6.noarch
libipa_hbac-1.11.6-30.el6_6.4.x86_64
device-mapper-multipath-0.4.9-80.el6_6.3.x86_64
ipa-client-3.0.0-42.el6.centos.x86_64
ipa-server-selinux-3.0.0-42.el6.centos.x86_64
ipa-python-3.0.0-42.el6.centos.x86_64
ipa-pki-ca-theme-9.0.3-7.el6.noarch
sssd-ipa-1.11.6-30.el6_6.4.x86_64
pki-selinux-9.0.3-39.el6_6.noarch
pki-common-9.0.3-39.el6_6.noarch
pki-native-tools-9.0.3-39.el6_6.x86_64
pki-setup-9.0.3-39.el6_6.noarch
pki-util-9.0.3-39.el6_6.noarch
pki-symkey-9.0.3-39.el6_6.x86_64
pki-ca-9.0.3-39.el6_6.noarch
pki-java-tools-9.0.3-39.el6_6.noarch
ipa-pki-ca-theme-9.0.3-7.el6.noarch
pki-silent-9.0.3-39.el6_6.noarch
replica1 and replica2:
CentOS 7.1 (up to date)
ipa-client-4.1.0-18.el7.centos.3.x86_64
libipa_hbac-python-1.12.2-58.el7_1.6.x86_64
sssd-ipa-1.12.2-58.el7_1.6.x86_64
python-iniparse-0.4-9.el7.noarch
ipa-admintools-4.1.0-18.el7.centos.3.x86_64
ipa-server-4.1.0-18.el7.centos.3.x86_64
ipa-python-4.1.0-18.el7.centos.3.x86_64
libipa_hbac-1.12.2-58.el7_1.6.x86_64
pki-server-10.1.2-7.el7.noarch
krb5-pkinit-1.12.2-14.el7.x86_64
pki-base-10.1.2-7.el7.noarch
pki-ca-10.1.2-7.el7.noarch
pki-symkey-10.1.2-7.el7.x86_64
pki-tools-10.1.2-7.el7.x86_64
# ipa-replica-manage list
master1.example.com: master
master2.example.com: master
replica1.example.com: master
replica2.example.com.com: master
# ipa-csreplica-manage list
Directory Manager password:
replica1.example.com: CA not configured
master1.example.com: master
master2.example.com: master
replica2.example.com: CA not configured
When trying to install the CA on replica1 to do the migration:
ipa-ca-install --skip-conncheck --skip-schema-check
/var/lib/ipa/replica-info-replica1.example.com.gpg
we're getting the following error in the
/var/log/ipareplica-ca-install.log file:
...
2015-07-28T21:25:14Z DEBUG Saving StateFile to
'/var/lib/ipa/sysrestore/sysrestore.state'
2015-07-28T21:25:14Z DEBUG Starting external process
2015-07-28T21:25:14Z DEBUG args='/usr/sbin/pkispawn' '-s' 'CA' '-f'
'/tmp/tmp2ON_ql'
2015-07-28T21:25:51Z DEBUG Process finished, return code=1
2015-07-28T21:25:51Z DEBUG stdout=Loading deployment configuration
from /tmp/tmp2ON_ql.
Installing CA into /var/lib/pki/pki-tomcat.
Storing deployment configuration into
/etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg.
Installation failed.
2015-07-28T21:25:51Z DEBUG
stderr=/usr/lib/python2.7/site-packages/urllib3/connectionpool.py:771:
InsecureRequestWarning: Unverified HTTPS request is being made. Adding
certificate verification is strongly advised. See:
https://urllib3.readthedocs.org/en/latest/security.html
InsecureRequestWarning)
pkispawn: WARNING ... unable to validate security domain
user/password through REST interface. Interface not available
pkispawn: ERROR... Exception from Java Configuration
Servlet: Failed to obtain configuration entries from the master for
cloning java.io.IOException: Error: Not authorized
2015-07-28T21:25:51Z CRITICAL failed to configure ca instance Command
''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmp2ON_ql'' returned
non-zero exit status 1
2015-07-28T21:25:51Z DEBUG Traceback (most recent call last):
File /usr/lib/python2.7/site-packages/ipaserver/install/service.py,
line 382, in start_creation
run_step(full_msg, method)
File /usr/lib/python2.7/site-packages/ipaserver/install/service.py,
line 372, in run_step
method()
File
/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,
line 673, in __spawn_instance
raise RuntimeError('Configuration of CA failed')
RuntimeError: Configuration of CA failed
...
From /var/log/pki/pki-ca-spawn.20150728172515.log:
...
2015-07-28 17:25:16 pkispawn: INFO ... executing 'certutil
-N -d /tmp/tmp-eUbMVB -f /root/.dogtag/pki-tomcat/ca/password.conf'
2015-07-28 17:25:16 pkispawn: INFO
Re: [Freeipa-users] Replication stopped working
Update: m2 and m3 are now in sync! After making sure ldapsearch was working both ways (m1=m2 and m1=m3) using the server's keytabs (/etc/dirsrv/ds.keytab) for getting the ticket, I re-initialize both replicas and they were able to get updated: @m2 # ipa-replica-manage re-initialize --from m1.example.com @m3 # ipa-replica-manage re-initialize --from m1.example.com Thanks so much for your hint Martin! On Fri, Sep 5, 2014 at 12:43 PM, Guillermo Fuentes guillermo.fuen...@modernizingmedicine.com wrote: Hi Martin, Attached are m2.log, m3.log and m4.log files. 1) All masters are time synced with same NTP server pool. 2) DNS is fine. Forward and reverse lookup. 3) ldapsearch: m1 to m2 and m3 work: kinit -k -t /etc/dirsrv/ds.keytab ldap/`hostname` # getting ticket on m1 ldapsearch -Y GSSAPI -H ldaps://m2.example.com -b dc=example,dc=com uid=testuser ldapsearch -Y GSSAPI -H ldaps://m3.example.com -b dc=example,dc=com uid=testuser m1 to m4 fails: # ldapsearch -Y GSSAPI -H ldaps://m4.example.com -b dc=example,dc=com uid=testuser SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (KDC returned error string: FINDING_SERVER_KEY) m2 to m1, and m3 to m1 work fine: kinit -k -t /etc/dirsrv/ds.keytab ldap/`hostname` ldapsearch -Y GSSAPI -H ldaps://m1.example.com -b dc=example,dc=com uid=testuser m4 to m1 fails: # ldapsearch -Y GSSAPI -H ldaps://m1.example.com -b dc=example,dc=com uid=testuser SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-14): authorization failure: security flags do not match required m2 and m3 are at the same state now where connections between them and m1 are fine but the updates won't happen logging the following on m1 (/var/log/dirsrv/slapd-EXAMPLE-COM/errors) for both: [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - agmt=cn=meTom3.example.com (m3:389): replay_update: Sending modify operation (dn=uid=testuser,cn=users,cn=accounts,dc=example,dc=com csn=53d66ecb0004) [05/Sep/2014:12:30:49 -0400] - repl5_inc_result_threadmain: read result for message_id 0 [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - agmt=cn=meTom3.example.com (m3:389): replay_update: modifys operation (dn=uid=testuser,cn=users,cn=accounts,dc=example,dc=com csn=53d66ecb0004) not sent - empty [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - agmt=cn=meTom3.example.com (m3:389): replay_update: Consumer successfully sent operation with csn 53d66ecb0004 [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - agmt=cn=meTom3.example.com (m3:389): Skipping update operation with no message_id (uniqueid 04b0b435-5ef311e3-9c91ec9f-6cd72e64, CSN 53d66ecb0004): [05/Sep/2014:12:30:49 -0400] agmt=cn=meTom3.example.com (m3:389) - load=1 rec=38 csn=53d66ecb00020004 [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - agmt=cn=meTom3.example.com (m3:389): replay_update: Sending modify operation (dn=uid=testuser,cn=users,cn=accounts,dc=example,dc=com csn=53d66ecb00020004) [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - agmt=cn=meTom3.example.com (m3:389): replay_update: modifys operation (dn=uid=testuser,cn=users,cn=accounts,dc=example,dc=com csn=53d66ecb00020004) not sent - empty [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - agmt=cn=meTom3.example.com (m3:389): replay_update: Consumer successfully sent operation with csn 53d66ecb00020004 [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - agmt=cn=meTom3.example.com (m3:389): Skipping update operation with no message_id (uniqueid 04b0b435-5ef311e3-9c91ec9f-6cd72e64, CSN 53d66ecb00020004): [05/Sep/2014:12:30:49 -0400] agmt=cn=meTom3.example.com (m3:389) - load=1 rec=39 csn=53d66ecc00010004 [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - agmt=cn=meTom3.example.com (m3:389): replay_update: Sending modify operation (dn=uid=testuser,cn=users,cn=accounts,dc=example,dc=com csn=53d66ecc00010004) [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - agmt=cn=meTom3.example.com (m3:389): replay_update: modifys operation (dn=uid=testuser,cn=users,cn=accounts,dc=example,dc=com csn=53d66ecc00010004) not sent - empty [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - agmt=cn=meTom3.example.com (m3:389): replay_update: Consumer successfully sent operation with csn 53d66ecc00010004 [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - agmt=cn=meTom3.example.com (m3:389): Skipping update operation with no message_id (uniqueid 04b0b435-5ef311e3-9c91ec9f-6cd72e64, CSN 53d66ecc00010004): [05/Sep/2014:12:30:49 -0400] NSMMReplicationPlugin - agmt=cn=meTom3.example.com (m3:389): No more updates to send (cl5GetNextOperationToReplay) [05/Sep/2014:12:30:49 -0400] - repl5_inc_waitfor_async_results: 0
Re: [Freeipa-users] Replication stopped working
Hi Martin, That's a good question! We're not sure what was the root cause of the replication errors. When we realized the replication wasn't happening, we had recently updated FreeIPA from 3.0.0-36 to 3.0.0-37 (on CentOS 6.5) and we had shutdown m1 and m2 in order to do a snapshot of the VMs. We've been doing that for several months and never had a problem. Note that m3 wasn't shutdown and the replication stopped for it as well. The configuration wasn't change so I don't think it was a configuration problem. I did have to get a new ldap service keytab for the m2 replica (/etc/dirsrv/ds.keytab) but not for m3. I'll do more research on what happened and report back if I find anything relevant. Thanks again, Guillermo On Fri, Sep 5, 2014 at 4:22 PM, Martin Kosek mko...@redhat.com wrote: Good to hear Guillermo, I am glad you are back up and running. I am just curious, what as the root cause of your replication errors in the end? I did not catch that from the thread. Is it something we can fix in FreeIPA or is it just a configuration error? Thanks, Martin On 09/05/2014 08:06 PM, Guillermo Fuentes wrote: Update: m2 and m3 are now in sync! After making sure ldapsearch was working both ways (m1=m2 and m1=m3) using the server's keytabs (/etc/dirsrv/ds.keytab) for getting the ticket, I re-initialize both replicas and they were able to get updated: @m2 # ipa-replica-manage re-initialize --from m1.example.com @m3 # ipa-replica-manage re-initialize --from m1.example.com Thanks so much for your hint Martin! -- 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] Replication stopped working
Hello list, We’re running FreeIPA with a master and 3 replicas. The replication stopped working and currently we’re adding resources only to the master. This is the environment we have: m1: OS: CentOS release 6.5 FreeIPA: 3.0.0-37 CA: pki-ca-9.0.3 # ipa-replica-manage list -v `hostname` m2.example.com: replica last init status: None last init ended: None last update status: 49 - LDAP error: Invalid credentials last update ended: None m3.example.com: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2014-09-04 14:28:44+00:00 m4.example.com: replica last init status: None last init ended: None last update status: -2 - LDAP error: Local error last update ended: None m2: OS: CentOS release 6.5 FreeIPA: 3.0.0-37 # ipa-replica-manage list -v `hostname` m1.example.com: replica last init status: None last init ended: None last update status: -1 Incremental update has failed and requires administrator actionLDAP error: Can't contact LDAP server last update ended: 2014-09-03 22:53:21+00:00 m3: OS: CentOS release 6.5 FreeIPA: 3.0.0-37 # ipa-replica-manage list -v `hostname` m1.example.com: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2014-09-04 14:31:51+00:00 m4: OS: CentOS release 6.5 FreeIPA: 3.3.3-28 # ipa-replica-manage list -v `hostname` m1.example.com: replica last init status: None last init ended: None last update status: 49 Unable to acquire replicaLDAP error: Invalid credentials last update ended: None Note that although m3 reports “Incremental update succeeded”, users created on m1 are not replicated to m3, and users created on m3 are not replicated back to m1. We’ve tried different things including re-initializing m2. Can somebody point me in the right direction to get replication going again? Thanks in advance! Guillermo -- 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] Disabling anonymous binds breaks OS X (10.8.5 and 10.9.1) UI logins.
Hello, We are deploying FreeIPA (which it's a great project BTW) as our Identity Management System. As we don't want any info from the directory to be publically available, we tried disabling anonymous binds but it breaks UI logins on Macs (10.8.5 and 10.9.1) FreeIPA logs show that OS X retrieves attributes using anonymous bind and when it's disabled it logs: ... authzid=(null), anonymous search not allowed Has anyone been able to get this setup working properly? Thanks in advance, Guillermo ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
