[Freeipa-users] Re: Failed Upgrade?
On 08/01/2017 12:03 PM, Rob Crittenden wrote: Ian Harding wrote: On 08/01/2017 07:39 AM, Florence Blanc-Renaud wrote: On 08/01/2017 03:11 PM, Ian Harding wrote: On 08/01/2017 01:48 AM, Florence Blanc-Renaud wrote: On 08/01/2017 01:32 AM, Ian Harding via FreeIPA-users wrote: On 07/31/2017 11:34 AM, Rob Crittenden wrote: Ian Harding via FreeIPA-users wrote: I had an unexpected restart of an IPA server that had apparently had updates run but had not been restarted. ipactl says pki-tomcatd would not start. Strangely, the actual service appears to be running: dogtag is an application within tomcat so tomcat can run without dogtag running. We need to see more of the dogtag debug log to see what is going on. It looks like an authentication problem... [28/Jul/2017:10:08:47][localhost-startStop-1]: SSL handshake happened Could not connect to LDAP server host seattlenfs.bpt.rocks port 636 Error netscape.ldap.LDAPException: Authentication failed (49) Hi, dogtag stores its internal data in the LDAP server and needs to establish a secure LDAP connection. You can check how this connection is configured in /etc/pki/pki-tomcat/ca/CS.cfg, look for the lines: internaldb.ldapauth.authtype=SslClientAuth internaldb.ldapauth.bindDN=cn=Directory Manager internaldb.ldapauth.bindPWPrompt=internaldb internaldb.ldapauth.clientCertNickname=subsystemCert cert-pki-ca internaldb.ldapconn.host=vm-... internaldb.ldapconn.port=636 internaldb.ldapconn.secureConn authtype can be SslClientAuth (authentication with a ssl certificate) or BasicAuth (authentication with a bind DN and password stored in /var/lib/pki/pki-tomcat/conf/password.conf). You can use this information to manually check the credentials. For instance with sslclientauth: export LDAPTLS_CACERTDIR=/etc/pki/pki-tomcat/alias export LDAPTLS_CERT='subsystemCert cert-pki-ca' ldapsearch -H ldaps://`hostname`:636 -b "" -s base -Y EXTERNAL (provide the password from /etc/pki/pki-tomcat/alias/pwdfile.txt) I found this: internaldb.ldapauth.authtype=SslClientAuth internaldb.ldapauth.bindDN=uid=pkidbuser,ou=people,o=ipaca internaldb.ldapauth.bindPWPrompt=internaldb internaldb.ldapauth.clientCertNickname=subsystemCert cert-pki-ca internaldb.ldapconn.cloneReplicationPort=389 ... and when I try the ldapsearch I am presented with a prompt to provide a pin/password Please enter pin, password, or pass phrase for security token 'ldap(0)': but there is no password file... Hi, you are right, in 4.4. there is no pwdfile.txt and the password can be found in /var/lib/pki/pki-tomcat/conf/password.conf (with the tag internal=...) Can you check if the password with the tag internal=... allows to read the keys from the NSS db? certutil -K -d /etc/pki/pki-tomcat/alias (provide password) That works... # certutil -K -d /etc/pki/pki-tomcat/alias certutil: Checking token "NSS Certificate DB" in slot "NSS User Private Key and Certificate Services" Enter Password or Pin for "NSS Certificate DB": < 0> rsa 0f327e760a7eecdcf6973f5dc57ca5367c592d64 (orphan) < 1> rsa b12580c7c696cfcd8aefc9405a7a870b24b7b96a NSS Certificate DB:auditSigningCert cert-pki-ca < 2> rsa 881b7254c40fa40bc50681bcc8d37bb3eb49937e caSigningCert cert-pki-ca < 3> rsa fa9a255a1d15585ac28064c0f4986e416bc48403 NSS Certificate DB:ocspSigningCert cert-pki-ca < 4> rsa 3fb609d0f7d72c2d325d6a2dc16577a7f7e5a01f Server-Cert cert-pki-ca < 5> rsa 1e9479a9556af9339bb5e4552ccbd381d3c38856 NSS Certificate DB:subsystemCert cert-pki-ca But this doesn't (with the same password from password.conf) # ldapsearch -H ldaps://`hostname`:636 -b "" -s base -Y EXTERNAL Please enter pin, password, or pass phrase for security token 'ldap(0)': SASL/EXTERNAL authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) That password is getting me somewhere though, since if I put in a nonsense or incorrect password it just prompts over and over. Let's step back a second. You upgraded from what to what? There wasn't much of a change... I just assumed someone ran yum upgrade and didn't restart, then the power outage... it looks like not much of a version change though. # grep ipa /var/log/yum.log Jan 08 04:45:32 Installed: ipa-common-4.4.0-14.el7.centos.1.1.noarch Jan 08 04:45:32 Installed: ipa-client-common-4.4.0-14.el7.centos.1.1.noarch Jan 08 04:46:06 Updated: libipa_hbac-1.14.0-43.el7_3.4.x86_64 Jan 08 04:46:07 Updated: python-libipa_hbac-1.14.0-43.el7_3.4.x86_64 Jan 08 04:46:08 Installed: python-ipaddress-1.0.16-2.el7.noarch Jan 08 04:47:04 Installed: python2-ipalib-4.4.0-14.el7.centos.1.1.noarch Jan 08 04:47:05 Installed: python2-ipaclient-4.4.0-14.el7.centos.1.1.noarch Jan 08 04:47:05 Updated: ipa-admintools-4.4.0-14.el7.centos.1.1.noarch Jan 08 04:47:05 Installed: ipa-server-common-4.4.0-14.el7.centos.1.1.noarch Jan 08 04:47:06 Installed: python2-ipaserver-4.4.0-14.el7.centos.1.1.noarch Jan 08 04:47:07 Updated: sssd-ipa-1.14.0-43.el7_3.4.x86_64 Jan 08 04:47:17
[Freeipa-users] Replication intermittently breaks---DNS process fail?
We have observed the following situationreplication agreement between server1 and server2 exists ipa-replica-manage list server2>server1 However some of the users, hosts etc that are added on server1 are not making it to server2. In sssd/error logs I can see the following which looks relevant: [27/Jul/2017:04:53:22.624847790 +] NSMMReplicationPlugin - agmt="cn=meToserver1" (server1:389): Unable to receive the response for a startReplication extended operation to consumer (Timed out). Will retry later.[27/Jul/2017:05:01:34.472586960 +] NSMMReplicationPlugin - agmt="cn=meToserver1" (server1:389): Unable to receive the response for a startReplication extended operation to consumer (Can't contact LDAP server). Will retry later.[29/Jul/2017:01:33:20.466840208 +] NSMMReplicationPlugin - agmt="cn=meToserver1" (server1:389): Replication bind with GSSAPI auth resumed [29/Jul/2017:11:16:51.566360207 +] NSMMReplicationPlugin - agmt="cn=meToserver1" (server1:389): Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact LDAP server) ()[29/Jul/2017:11:17:00.664020018 +] NSMMReplicationPlugin - agmt="cn=meToserver1" (server1:389): Replication bind with GSSAPI auth resumed[29/Jul/2017:11:17:01.106831731 +] NSMMReplicationPlugin - agmt="cn=meToserver1" (server1:389): The remote replica has a different database generation ID than the local database. You may have to reinitialize the remote replica, or the local replica. there are no known network issues between the two servers, and all ports are opened as confirmed by nmap. I am also able to ipa-replica-manage re-initialize --from server1 which has the desired effect of updating server2's information. in /var/log/messages I do see Jul 31 03:18:08 server2 named-pkcs11[30962]: zone domain.com/IN: NS 'server1' has no address records (A or )Jul 31 11:41:52 server2 ns-slapd: [31/Jul/2017:11:41:52.408672378 +] NSMMReplicationPlugin - agmt="cn=meToserver1" (ipa-x1:389): Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact LDAP server) () in var/log/messages I see Jul 31 03:18:08 server2 named-pkcs11[30962]: zone domain.com/IN: NS 'server1.domain.com' has no address records (A or )Jul 31 03:18:08 server2 named-pkcs11[30962]: zone domain.com/IN: not loaded due to errors. Jul 31 03:18:08 server2 named-pkcs11[30962]: update_zone (syncrepl) failed for master zone DN 'idnsname=domain.com.,cn=dns,dc=company,dc=com'. Zones can be outdated, run `rndc reload`: bad zone Jul 31 04:05:03 server2 named-pkcs11[30962]: error (network unreachable) resolving 'srv.external_dns.net/A/IN': 2a02:e180:8::1#53 Jul 31 11:40:05 server2 named-pkcs11[30962]: received control channel command 'stop' Jul 31 11:40:05 server2 named-pkcs11[30962]: shutting down: flushing changesJul 31 11:40:05 server2 named-pkcs11[30962]: stopping command channel on ::1#953 Jul 31 11:40:05 server2 named-pkcs11[30962]: zone 23.34.34.-addr.arpa/IN: shutting down so looks like some problem with IPA's dns server. Since server2 is it's own auth DNS server for freeipa domains it would make sense that it wouldn't be able to resolve the server1 ip address and replication would fail. If you agree then what would be the steps to troubleshoot the DNS functionality problems above. PS:Another thing to note is that when I re-initialized the database from server1 DNS still wasn't working properly and I had to ipactl restartto get it working. thank you ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: Failed Upgrade?
Ian Harding wrote: > On 08/01/2017 07:39 AM, Florence Blanc-Renaud wrote: >> On 08/01/2017 03:11 PM, Ian Harding wrote: >>> On 08/01/2017 01:48 AM, Florence Blanc-Renaud wrote: On 08/01/2017 01:32 AM, Ian Harding via FreeIPA-users wrote: > > > On 07/31/2017 11:34 AM, Rob Crittenden wrote: >> Ian Harding via FreeIPA-users wrote: >>> I had an unexpected restart of an IPA server that had apparently had >>> updates run but had not been restarted. ipactl says pki-tomcatd >>> would >>> not start. >>> >>> Strangely, the actual service appears to be running: >>> >> >> dogtag is an application within tomcat so tomcat can run without >> dogtag >> running. >> >> We need to see more of the dogtag debug log to see what is going on. >> > > It looks like an authentication problem... > > [28/Jul/2017:10:08:47][localhost-startStop-1]: SSL handshake happened > Could not connect to LDAP server host seattlenfs.bpt.rocks port 636 > Error netscape.ldap.LDAPException: Authentication failed (49) > Hi, dogtag stores its internal data in the LDAP server and needs to establish a secure LDAP connection. You can check how this connection is configured in /etc/pki/pki-tomcat/ca/CS.cfg, look for the lines: internaldb.ldapauth.authtype=SslClientAuth internaldb.ldapauth.bindDN=cn=Directory Manager internaldb.ldapauth.bindPWPrompt=internaldb internaldb.ldapauth.clientCertNickname=subsystemCert cert-pki-ca internaldb.ldapconn.host=vm-... internaldb.ldapconn.port=636 internaldb.ldapconn.secureConn authtype can be SslClientAuth (authentication with a ssl certificate) or BasicAuth (authentication with a bind DN and password stored in /var/lib/pki/pki-tomcat/conf/password.conf). You can use this information to manually check the credentials. For instance with sslclientauth: export LDAPTLS_CACERTDIR=/etc/pki/pki-tomcat/alias export LDAPTLS_CERT='subsystemCert cert-pki-ca' ldapsearch -H ldaps://`hostname`:636 -b "" -s base -Y EXTERNAL (provide the password from /etc/pki/pki-tomcat/alias/pwdfile.txt) >>> >>> I found this: >>> >>> internaldb.ldapauth.authtype=SslClientAuth >>> internaldb.ldapauth.bindDN=uid=pkidbuser,ou=people,o=ipaca >>> internaldb.ldapauth.bindPWPrompt=internaldb >>> internaldb.ldapauth.clientCertNickname=subsystemCert cert-pki-ca >>> internaldb.ldapconn.cloneReplicationPort=389 >>> ... >>> >>> and when I try the ldapsearch I am presented with a prompt to provide >>> a pin/password >>> >>> Please enter pin, password, or pass phrase for security token 'ldap(0)': >>> >>> but there is no password file... >>> >> Hi, >> >> you are right, in 4.4. there is no pwdfile.txt and the password can be >> found in /var/lib/pki/pki-tomcat/conf/password.conf (with the tag >> internal=...) >> >> Can you check if the password with the tag internal=... allows to read >> the keys from the NSS db? >> certutil -K -d /etc/pki/pki-tomcat/alias >> (provide password) > > That works... > > # certutil -K -d /etc/pki/pki-tomcat/alias > certutil: Checking token "NSS Certificate DB" in slot "NSS User Private > Key and Certificate Services" > Enter Password or Pin for "NSS Certificate DB": > < 0> rsa 0f327e760a7eecdcf6973f5dc57ca5367c592d64 (orphan) > < 1> rsa b12580c7c696cfcd8aefc9405a7a870b24b7b96a NSS Certificate > DB:auditSigningCert cert-pki-ca > < 2> rsa 881b7254c40fa40bc50681bcc8d37bb3eb49937e caSigningCert > cert-pki-ca > < 3> rsa fa9a255a1d15585ac28064c0f4986e416bc48403 NSS Certificate > DB:ocspSigningCert cert-pki-ca > < 4> rsa 3fb609d0f7d72c2d325d6a2dc16577a7f7e5a01f Server-Cert > cert-pki-ca > < 5> rsa 1e9479a9556af9339bb5e4552ccbd381d3c38856 NSS Certificate > DB:subsystemCert cert-pki-ca > > But this doesn't (with the same password from password.conf) > > # ldapsearch -H ldaps://`hostname`:636 -b "" -s base -Y EXTERNAL > Please enter pin, password, or pass phrase for security token 'ldap(0)': > SASL/EXTERNAL authentication started > ldap_sasl_interactive_bind_s: Invalid credentials (49) > > That password is getting me somewhere though, since if I put in a > nonsense or incorrect password it just prompts over and over. Let's step back a second. You upgraded from what to what? Are you running in SELinux enforcing mode? If so can you run: # ausearch -m AVC I suspect that the subsystem cert was renewed and everything wasn't updated properly. If I'm right this is unrelated to the upgrade it just shone a spotlight on it. Can you run these commands: $ ldapsearch -LLL -D 'cn=directory manager' -W -b uid=pkidbuser,ou=people,o=ipaca userCertificate description and # certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca' | grep Serial # certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca' -a The description attribute in
[Freeipa-users] Re: AD trust setup woes
On Tue, Aug 01, 2017 at 11:20:16AM -, Igor Sever via FreeIPA-users wrote: > I have the same error. > I established two-way trust with AD which went fine. > Authentication with Kerberos to AD is working. > Since I have one test FreeIPA which is working correctly (relatively) I > compared logs and pinpointed problem to strange LDAP search which is FreeIPA > sending to DC: > (&(sAMAccountName=domain\20admins)(objectClass=group)(sAMAccountName=*)(&(gidNumber=*)(!(gidNumber=0 > This LDAP query is of course not working on AD. I don’t know why FreeIPA is > sending this kind of query to AD in this case? > Only difference that I can think of in this case is that I didn’t establish > trust in two steps, but in one step from FreeIPA using command switch > --two-way=true. Pardon my ignorance, but what part of that query doesn't work? ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: External Application Authentication Against FreeIPA LDAP Not Working
Yes, this information helped. In summary, I needed to create a "Service Account" that my application could bind to. I'm not sure why as it was able to BIND just fine using my credentials, but that is not a question for this group. It took some trial and error to get it to work correctly, but I was finally able to get it to function properly. I'm grateful for the assistance. Thanks again, Brady ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: IPA replica with CA role problems
On 08/01/2017 11:01 AM, Florence Blanc-Renaud wrote: you can connect to IPA web UI on the server to revoke the cert: https://server.ipadomain.com/ipa/ui, then navigate to Authentication > Certificates, click on the certificate corresponding to the replica which failed installation (CN=,o=DOM...) and then Actions > Revoke Certificate (superseded). Flo Okay, this is just bloody stupid. It should NOT be that hard to build a bloody replica of an existing LDAP server. It's beyond insane. I revoked the certs of ipa1 off ipa0, built a new ipa-replica file on ipa0, copied to ipa1 and ran ipa-replica-install replica-info-ipa1.neonova.net.gpg --setup-ca and it FAILED AGAIN. It seems the issue is that ipa1 can't find the GoDaddy supplied certs we are using for the web UI /only/. I expected that ALL certs would be replicated over, but apparently that would be FAR too convenient. It's silly crap like this that keeps LDAP from being anything more than a giant PITA and pushes people to not-centralize linux accounts outside of maybe AD (which in itself is sad). The failure is exactly that as the previous 4 times I've tried this. Why isn't the GoDaddy signed certs 1) not being found despite being on the server and 2) not carried over in the ipa-replica-prepare package? This really should be a straightforward process. The fact it isn't, and the documentation being called sparse would be an insult to that word, I'm at my wits end. Does anyone have ANY ideas on why the GoDaddy signed certs aren't behaving? -- Mark Haney Network Engineer at NeoNova 919-460-3330 option 1 mark.ha...@neonova.net www.neonova.net ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: Renewing /etc/httpd/alias certs
On 08/01/2017 03:50 PM, Jason B. Nance via FreeIPA-users wrote: Hello everyone, I'm running FreeIPA 4.4 (as shipped with current CentOS 7). I had a series of unfortunate events which resulted in the entire cluster being offline for a matter of a couple weeks during which the certificate in /etc/httpd/alias expired. I rolled back the clocks on all of the servers in the cluster and started them successfully, however, the certificates in /etc/httpd/alias did not get renewed. Is there a process that automatically handles this or was I supposed to be maintaining that? Additionally, based on: https://www.freeipa.org/page/Howto/CA_Certificate_Renewal ...I ran "ipa-cacert-manage renew" on my CA in a hope that that would trigger renewals across the boards, but now it appears that only the CA was updated as none of the server certificates were re-issued and are now all untrusted (I can't do "kinit admin" any longer as my realm is now down). Is there any chance of rolling that back or issuing new certs to get things going again? Hi, ipa-cacert-manage will only renew IPA CA certificate, not the LDAP or HTTP server certificates. When IPA is using an embedded CA, the LDAP and HTTP server certificates should be automatically renewed thanks to certmonger. If the automatic renewal did not happen, you can check: - if the certificates are indeed tracked by certmonger sudo getcert list -n Server-Cert The tool should output one cert for HTTP (in /etc/httpd/alias) and one for LDAP (in /etc/dirsrv/slapd-DOM...). If the certs are not tracked, you need to use getcert start-tracking to track them. - if they are tracked but not renewed, check the journal for certmonger messages. Certmonger should log a message when a certificate is nearing its expiration, and another message when the renewal succeeded. When the certificates are expired, the method is to stop ntpd, go back in time to a date where the certs were still valid, then manually trigger the renewal using getcert resubmit -i . In case of errors, examine the journal logs and try to fix the issue, then relaunch getcert resubmit. Once the renewal succeeds, getcert list shows the cert status as MONITORING and you can restart ntpd. This blog [1] provides a few examples of issues and their resolution HTH, Flo [1] https://floblanc.wordpress.com/2016/12/19/troubleshooting-certmonger-issues-with-freeipa/ If I have to start over, that is certainly an option. I'm just trying to get a better understanding of what I should have been doing to avoid this situation in the first place. Thanks, j ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: IPA replica with CA role problems
On 08/01/2017 11:01 AM, Florence Blanc-Renaud wrote: Hi, you can connect to IPA web UI on the server to revoke the cert: https://server.ipadomain.com/ipa/ui, then navigate to Authentication > Certificates, click on the certificate corresponding to the replica which failed installation (CN=,o=DOM...) and then Actions > Revoke Certificate (superseded). Flo Ah okay. If I didn't mention it in my first post, we here are still very green with IPA. Me especially since I didn't install the original server and have been working here right at 4 months. Thanks for the help, I'll keep you posted. -- Mark Haney Network Engineer at NeoNova 919-460-3330 option 1 mark.ha...@neonova.net www.neonova.net ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: IPA replica with CA role problems
On 08/01/2017 03:11 PM, Mark Haney via FreeIPA-users wrote: On 08/01/2017 03:26 AM, Florence Blanc-Renaud wrote: another user hit the same problem as you (ipa-replica-install --setup-ca fails during pkispawn and the PKI debug log shows an error related to updateNumberRange). He managed to workaround the issue by un-enrolling the failing replica and revoking all the certificates that were created during replica setup attempts (you can find the mail thread here [1]). I still don't know what is the root cause of the issue or why the workaround succeeded, but it's worth giving it a try. Flo [1] https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/TJGJZANRCIYTGXCUEAZ3XLISNEO7QOIN/#A54XHWAG4Z6BVX62YRUQXYO5QKW4OXAZ The logs do look similar to me, so I can give this a shot, what I don't know is how to revoke all the certificates on the replica server (at least I'm assuming it's the replica getting the revokations. Hi, you can connect to IPA web UI on the server to revoke the cert: https://server.ipadomain.com/ipa/ui, then navigate to Authentication > Certificates, click on the certificate corresponding to the replica which failed installation (CN=,o=DOM...) and then Actions > Revoke Certificate (superseded). Flo ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: I appear to have an issue with "hosts" on my replica
The resolv.conf is identical on both systems, DNS is solid. SRV records are functioning as expected. I looked at everything and failing to find a resolution, sought advice here on the board. Now that these are out of sync, how would one manually initiate a sync? I haven’t found this in the documentation. - grant Grant, Any ideas on this? Everything appears to be in order, yet there is a disparity between the master and replica on the host count. What's going on with DNS on these two hosts? Are they pointing to the same DNS server? Are there kerberos and ldap records. mpapet This e-mail and any attachments are intended only for use by the addressee(s) named herein and may contain confidential information. If you are not the intended recipient of this e-mail, you are hereby notified any dissemination, distribution or copying of this email and any attachments is strictly prohibited. If you receive this email in error, please immediately notify the sender by return email and permanently delete the original, any copy and any printout thereof. The integrity and security of e-mail cannot be guaranteed. ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: Time Skew on Amazon nodes?
On 08/01/2017 04:42 PM, pgb 205 via FreeIPA-users wrote: ok thats great news! But I just want to make sure even if the server IS ALREADY DOWN due to this bug we can still manually edit the database (dse.ldif) for this value and then bring up the processes. Would that work? yes, that should work ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org -- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: Time Skew on Amazon nodes?
ok thats great news! But I just want to make sure even if the server IS ALREADY DOWN due to this bug we can still manually edit the database (dse.ldif) for this value and then bring up the processes. Would that work? ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: Server died
Stupid return key. I solved this and was trying to delete the email. Sorry for the spam. On 08/01/2017 10:28 AM, Bret Wortman via FreeIPA-users wrote: I've got a server with multiple replication agreements that just went toes up. The tail end of the startup output says: Aug 01 14:21:22 zsipa systemd[1]: dirsrv@DG-NET.service: main process exited, code=exited, status=1/FAILURE Aug 01 14:21:22 zsipa systemd[1]: Aug 01 14:21:22 zsipa systemd[1]: -- *Bret Wortman* Damascus Products ph/fax: 1-855-644-2783 Wrap Buddies now available for preorder! ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: Failed Upgrade?
On 08/01/2017 03:11 PM, Ian Harding wrote: On 08/01/2017 01:48 AM, Florence Blanc-Renaud wrote: On 08/01/2017 01:32 AM, Ian Harding via FreeIPA-users wrote: On 07/31/2017 11:34 AM, Rob Crittenden wrote: Ian Harding via FreeIPA-users wrote: I had an unexpected restart of an IPA server that had apparently had updates run but had not been restarted. ipactl says pki-tomcatd would not start. Strangely, the actual service appears to be running: dogtag is an application within tomcat so tomcat can run without dogtag running. We need to see more of the dogtag debug log to see what is going on. It looks like an authentication problem... [28/Jul/2017:10:08:47][localhost-startStop-1]: SSL handshake happened Could not connect to LDAP server host seattlenfs.bpt.rocks port 636 Error netscape.ldap.LDAPException: Authentication failed (49) Hi, dogtag stores its internal data in the LDAP server and needs to establish a secure LDAP connection. You can check how this connection is configured in /etc/pki/pki-tomcat/ca/CS.cfg, look for the lines: internaldb.ldapauth.authtype=SslClientAuth internaldb.ldapauth.bindDN=cn=Directory Manager internaldb.ldapauth.bindPWPrompt=internaldb internaldb.ldapauth.clientCertNickname=subsystemCert cert-pki-ca internaldb.ldapconn.host=vm-... internaldb.ldapconn.port=636 internaldb.ldapconn.secureConn authtype can be SslClientAuth (authentication with a ssl certificate) or BasicAuth (authentication with a bind DN and password stored in /var/lib/pki/pki-tomcat/conf/password.conf). You can use this information to manually check the credentials. For instance with sslclientauth: export LDAPTLS_CACERTDIR=/etc/pki/pki-tomcat/alias export LDAPTLS_CERT='subsystemCert cert-pki-ca' ldapsearch -H ldaps://`hostname`:636 -b "" -s base -Y EXTERNAL (provide the password from /etc/pki/pki-tomcat/alias/pwdfile.txt) I found this: internaldb.ldapauth.authtype=SslClientAuth internaldb.ldapauth.bindDN=uid=pkidbuser,ou=people,o=ipaca internaldb.ldapauth.bindPWPrompt=internaldb internaldb.ldapauth.clientCertNickname=subsystemCert cert-pki-ca internaldb.ldapconn.cloneReplicationPort=389 ... and when I try the ldapsearch I am presented with a prompt to provide a pin/password Please enter pin, password, or pass phrase for security token 'ldap(0)': but there is no password file... Hi, you are right, in 4.4. there is no pwdfile.txt and the password can be found in /var/lib/pki/pki-tomcat/conf/password.conf (with the tag internal=...) Can you check if the password with the tag internal=... allows to read the keys from the NSS db? certutil -K -d /etc/pki/pki-tomcat/alias (provide password) If the password is not the right one, certutil will prompt you once again for it. This would mean that the password does not allow to access the key from the NSSdb and Dogtag will not be able to use the certificate for authentication. Flo ls -a /etc/pki/pki-tomcat/alias/ . .. cert8.db key3.db secmod.db There are "internal" and "replicationdb" values in /var/lib/pki/pki-tomcat/conf/password.conf but they don't work in response to the ldapsearch prompt above. Thank you so much for your help! HTH, Flo. at org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1966) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Internal Database Error encountered: Could not connect to LDAP server host seattlenfs.bpt.rocks port 636 Error netscape.ldap.LDAPException: Authentication failed (49) at com.netscape.cmscore.dbs.DBSubsystem.init(DBSubsystem.java:676) at com.netscape.cmscore.apps.CMSEngine.initSubsystem(CMSEngine.java:1172) at com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:1078) at com.netscape.cmscore.apps.CMSEngine.init(CMSEngine.java:570) at com.netscape.certsrv.apps.CMS.init(CMS.java:188) at com.netscape.certsrv.apps.CMS.start(CMS.java:1621) at com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:114) at javax.servlet.GenericServlet.init(GenericServlet.java:158) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 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
[Freeipa-users] Server died
I've got a server with multiple replication agreements that just went toes up. The tail end of the startup output says: Aug 01 14:21:22 zsipa systemd[1]: dirsrv@DG-NET.service: main process exited, code=exited, status=1/FAILURE Aug 01 14:21:22 zsipa systemd[1]: Aug 01 14:21:22 zsipa systemd[1]: -- *Bret Wortman* Damascus Products ph/fax: 1-855-644-2783 Wrap Buddies now available for preorder! ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Renewing /etc/httpd/alias certs
Hello everyone, I'm running FreeIPA 4.4 (as shipped with current CentOS 7). I had a series of unfortunate events which resulted in the entire cluster being offline for a matter of a couple weeks during which the certificate in /etc/httpd/alias expired. I rolled back the clocks on all of the servers in the cluster and started them successfully, however, the certificates in /etc/httpd/alias did not get renewed. Is there a process that automatically handles this or was I supposed to be maintaining that? Additionally, based on: https://www.freeipa.org/page/Howto/CA_Certificate_Renewal ...I ran "ipa-cacert-manage renew" on my CA in a hope that that would trigger renewals across the boards, but now it appears that only the CA was updated as none of the server certificates were re-issued and are now all untrusted (I can't do "kinit admin" any longer as my realm is now down). Is there any chance of rolling that back or issuing new certs to get things going again? If I have to start over, that is certainly an option. I'm just trying to get a better understanding of what I should have been doing to avoid this situation in the first place. Thanks, j ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: "Cannot obtain CA certificate" error when trying to install, but works on older instances; force fails
None via FreeIPA-users wrote:
> Further update: I'm pretty sure I found out the problem.
>
> Basically, my old server is running pyasn1==0.2.3 and the new one has
> pyasn1==0.3.1. Per the pyasn1 documentation, they made a breaking change
> to __init__ and a few other functions in 0.3.1, so I guess FreeIPA 4.3.1
> isn't compatible with these changes.
>
> I've got a ticket open at https://pagure.io/freeipa/issue/7079 about this.
Nice catch.
0.3.1 was just released a few days ago and I haven't had a chance to try
packaging it for Fedora yet much less do any compatibility testing.
Given the API changes I'll need to coordinate the update with the other
module users, including freeIPA.
In the meantime it might be a good idea for packagers to specifically
require 0.2.3 for now.
rob
>
> - greg
>
> On 2017-08-01 08:15, g...@greg-gilbert.com wrote:
>
>> Slight update: I tried precreating /etc/ipa/ca.crt, and when running
>> the install, I get the same Python error I did before:
>>
>> File "/usr/sbin/ipa-client-install", line 3099, in
>> sys.exit(main())
>> File "/usr/sbin/ipa-client-install", line 3080, in main
>> rval = install(options, env, fstore, statestore)
>> File "/usr/sbin/ipa-client-install", line 2727, in install
>> api.finalize()
>> File "/usr/lib/python2.7/dist-packages/ipalib/plugable.py", line
>> 656, in finalize
>> self.__do_if_not_done('load_plugins')
>> File "/usr/lib/python2.7/dist-packages/ipalib/plugable.py", line
>> 370, in __do_if_not_done
>> getattr(self, name)()
>> File "/usr/lib/python2.7/dist-packages/ipalib/plugable.py", line
>> 534, in load_plugins
>> self.import_plugins(module)
>> File "/usr/lib/python2.7/dist-packages/ipalib/plugable.py", line
>> 572, in import_plugins
>> module = importlib.import_module(name)
>> File "/usr/lib/python2.7/importlib/__init__.py", line 37, in
>> import_module
>> __import__(name)
>> File "/usr/lib/python2.7/dist-packages/ipalib/plugins/cert.py", line
>> 29, in
>> from ipalib import pkcs10
>> File "/usr/lib/python2.7/dist-packages/ipalib/pkcs10.py", line 79,
>> in
>> class _PrincipalName(univ.Sequence):
>> File "/usr/lib/python2.7/dist-packages/ipalib/pkcs10.py", line 84,
>> in _PrincipalName
>> namedtype.NamedType('name-string',
>> univ.SequenceOf(char.GeneralString()).subtype(
>> TypeError: __init__() takes exactly 1 argument (2 given)
>>
>>
>> On 2017-08-01 07:07, g...@greg-gilbert.com wrote:
>>
>> Hey,
>>
>> I checked the logs and found this:
>>
>> conn=3295 op=3 SRCH
>> base="cn=certificates,cn=ipa,cn=etc,dc=ipa,dc=services,dc=example"
>> scope=2
>> filter="(&(objectClass=ipaCertificate)(objectClass=pkiCA))"
>> attrs="ipaKeyExtUsage cn ipaCertSubject ipaPublicKey
>> cacertificate;binary ipaKeyTrust ipaCertIssuerSerial"
>> conn=3295 op=3 RESULT err=0 tag=101 nentries=1 etime=0
>>
>> So that looks like it's finding an entry, I guess.
>>
>> All of the lines have err=0 except these:
>>
>> conn=3295 op=0 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind
>> in progress
>> conn=3295 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI
>> conn=3295 op=1 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind
>> in progress
>> conn=3295 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI
>>
>> The server is running FreeIPA 4.4:
>>
>> $ ipa --version
>> VERSION: 4.4.0, API_VERSION: 2.213
>> $ ipa-client-install --version
>> 4.4.0
>>
>> - greg
>>
>> On 2017-08-01 05:13, Florence Blanc-Renaud wrote:
>>
>> On 08/01/2017 03:26 AM, None via FreeIPA-users wrote:
>>
>> I'm really at a loss on this one.
>>
>> I have a bunch of old server images (from 2 months ago)
>> that can run ipa-client-install just fine. When I created
>> a new image, though, I get this error (from the install logs):
>>
>> DEBUG flushing ldap://ipa.services.example:389 from SchemaCache
>> DEBUG retrieving schema for SchemaCache
>> url=ldap://ipa.services.example:389
>> conn=> 0x7ff6a4e67560>
>> DEBUG get_ca_certs_from_ldap() error:
>> 'ipa.services.example' doesn't have a certificate.
>> DEBUG 'ipa.services.example' doesn't have a certificate.
>> ERROR In unattended mode without a One Time Password (OTP)
>> or without --ca-cert-file
>> You must specify --force to retrieve the CA cert using HTTP
>> ERROR Cannot obtain CA certificate
>> HTTP certificate download requires --force
>> ERROR Installation failed. Rolling back changes.
>> ERROR IPA client is not configured on this system.
>>
>> For comparison, the old images work as expected:
>>
>> DEBUG flushing ldap://ipa.services.example:389 from SchemaCache
>> DEBUG retrieving schema for SchemaCache
>>
[Freeipa-users] Re: "Cannot obtain CA certificate" error when trying to install, but works on older instances; force fails
Further update: I'm pretty sure I found out the problem.
Basically, my old server is running pyasn1==0.2.3 and the new one has
pyasn1==0.3.1. Per the pyasn1 documentation, they made a breaking change
to __init__ and a few other functions in 0.3.1, so I guess FreeIPA 4.3.1
isn't compatible with these changes.
I've got a ticket open at https://pagure.io/freeipa/issue/7079 about
this.
- greg
On 2017-08-01 08:15, g...@greg-gilbert.com wrote:
> Slight update: I tried precreating /etc/ipa/ca.crt, and when running the
> install, I get the same Python error I did before:
>
> File "/usr/sbin/ipa-client-install", line 3099, in
> sys.exit(main())
> File "/usr/sbin/ipa-client-install", line 3080, in main
> rval = install(options, env, fstore, statestore)
> File "/usr/sbin/ipa-client-install", line 2727, in install
> api.finalize()
> File "/usr/lib/python2.7/dist-packages/ipalib/plugable.py", line 656, in
> finalize
> self.__do_if_not_done('load_plugins')
> File "/usr/lib/python2.7/dist-packages/ipalib/plugable.py", line 370, in
> __do_if_not_done
> getattr(self, name)()
> File "/usr/lib/python2.7/dist-packages/ipalib/plugable.py", line 534, in
> load_plugins
> self.import_plugins(module)
> File "/usr/lib/python2.7/dist-packages/ipalib/plugable.py", line 572, in
> import_plugins
> module = importlib.import_module(name)
> File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
> __import__(name)
> File "/usr/lib/python2.7/dist-packages/ipalib/plugins/cert.py", line 29, in
>
> from ipalib import pkcs10
> File "/usr/lib/python2.7/dist-packages/ipalib/pkcs10.py", line 79, in
> class _PrincipalName(univ.Sequence):
> File "/usr/lib/python2.7/dist-packages/ipalib/pkcs10.py", line 84, in
> _PrincipalName
> namedtype.NamedType('name-string',
> univ.SequenceOf(char.GeneralString()).subtype(
> TypeError: __init__() takes exactly 1 argument (2 given)
>
> On 2017-08-01 07:07, g...@greg-gilbert.com wrote:
>
> Hey,
>
> I checked the logs and found this:
>
> conn=3295 op=3 SRCH
> base="cn=certificates,cn=ipa,cn=etc,dc=ipa,dc=services,dc=example" scope=2
> filter="(&(objectClass=ipaCertificate)(objectClass=pkiCA))"
> attrs="ipaKeyExtUsage cn ipaCertSubject ipaPublicKey cacertificate;binary
> ipaKeyTrust ipaCertIssuerSerial"
> conn=3295 op=3 RESULT err=0 tag=101 nentries=1 etime=0
>
> So that looks like it's finding an entry, I guess.
>
> All of the lines have err=0 except these:
>
> conn=3295 op=0 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress
> conn=3295 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI
> conn=3295 op=1 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress
> conn=3295 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI
>
> The server is running FreeIPA 4.4:
>
> $ ipa --version
> VERSION: 4.4.0, API_VERSION: 2.213
> $ ipa-client-install --version
> 4.4.0
>
> - greg
>
> On 2017-08-01 05:13, Florence Blanc-Renaud wrote:
> On 08/01/2017 03:26 AM, None via FreeIPA-users wrote: I'm really at a loss on
> this one.
>
> I have a bunch of old server images (from 2 months ago) that can run
> ipa-client-install just fine. When I created a new image, though, I get this
> error (from the install logs):
>
> DEBUG flushing ldap://ipa.services.example:389 from SchemaCache
> DEBUG retrieving schema for SchemaCache url=ldap://ipa.services.example:389
> conn=
> DEBUG get_ca_certs_from_ldap() error: 'ipa.services.example' doesn't have a
> certificate.
> DEBUG 'ipa.services.example' doesn't have a certificate.
> ERROR In unattended mode without a One Time Password (OTP) or without
> --ca-cert-file
> You must specify --force to retrieve the CA cert using HTTP
> ERROR Cannot obtain CA certificate
> HTTP certificate download requires --force
> ERROR Installation failed. Rolling back changes.
> ERROR IPA client is not configured on this system.
>
> For comparison, the old images work as expected:
>
> DEBUG flushing ldap://ipa.services.example:389 from SchemaCache
> DEBUG retrieving schema for SchemaCache url=ldap://ipa.services.example:389
> conn=
> INFO Successfully retrieved CA cert
> Subject: CN=Certificate Authority,O=IPA.SERVICES.example
> Issuer: CN=Certificate Authority,O=IPA.SERVICES.example
> Valid From: Wed Apr 05 21:11:13 2017 UTC
> Valid Until: Sun Apr 05 21:11:13 2037 UTC
>
> It's literally the same build script, so nothing there has changed. The old
> images still work even now, so I don't think it's a DNS issue. I tried
> running update-ca-certificates, but that did nothing. I tried restarting the
> FreeIPA server, nothing changed.
>
> If I try --forceing the install, this happens:
>
> Enrolled in IPA realm IPA.SERVICES.EXAMPLE
> Created /etc/ipa/default.conf
> Traceback (most recent call last):
> File "/usr/sbin/ipa-client-install", line 3099, in
> sys.exit(main())
> File "/usr/sbin/ipa-client-install", line 3080, in main
> rval = install(options, env, fstore, statestore)
> File "/usr/sbin/ipa-client-install",
[Freeipa-users] Re: IPA replica with CA role problems
On 08/01/2017 03:26 AM, Florence Blanc-Renaud wrote: another user hit the same problem as you (ipa-replica-install --setup-ca fails during pkispawn and the PKI debug log shows an error related to updateNumberRange). He managed to workaround the issue by un-enrolling the failing replica and revoking all the certificates that were created during replica setup attempts (you can find the mail thread here [1]). I still don't know what is the root cause of the issue or why the workaround succeeded, but it's worth giving it a try. Flo [1] https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/TJGJZANRCIYTGXCUEAZ3XLISNEO7QOIN/#A54XHWAG4Z6BVX62YRUQXYO5QKW4OXAZ The logs do look similar to me, so I can give this a shot, what I don't know is how to revoke all the certificates on the replica server (at least I'm assuming it's the replica getting the revokations. -- Mark Haney Network Engineer at NeoNova 919-460-3330 option 1 mark.ha...@neonova.net www.neonova.net ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: "Cannot obtain CA certificate" error when trying to install, but works on older instances; force fails
Slight update: I tried precreating /etc/ipa/ca.crt, and when running the
install, I get the same Python error I did before:
File "/usr/sbin/ipa-client-install", line 3099, in
sys.exit(main())
File "/usr/sbin/ipa-client-install", line 3080, in main
rval = install(options, env, fstore, statestore)
File "/usr/sbin/ipa-client-install", line 2727, in install
api.finalize()
File "/usr/lib/python2.7/dist-packages/ipalib/plugable.py", line 656,
in finalize
self.__do_if_not_done('load_plugins')
File "/usr/lib/python2.7/dist-packages/ipalib/plugable.py", line 370,
in __do_if_not_done
getattr(self, name)()
File "/usr/lib/python2.7/dist-packages/ipalib/plugable.py", line 534,
in load_plugins
self.import_plugins(module)
File "/usr/lib/python2.7/dist-packages/ipalib/plugable.py", line 572,
in import_plugins
module = importlib.import_module(name)
File "/usr/lib/python2.7/importlib/__init__.py", line 37, in
import_module
__import__(name)
File "/usr/lib/python2.7/dist-packages/ipalib/plugins/cert.py", line
29, in
from ipalib import pkcs10
File "/usr/lib/python2.7/dist-packages/ipalib/pkcs10.py", line 79, in
class _PrincipalName(univ.Sequence):
File "/usr/lib/python2.7/dist-packages/ipalib/pkcs10.py", line 84, in
_PrincipalName
namedtype.NamedType('name-string',
univ.SequenceOf(char.GeneralString()).subtype(
TypeError: __init__() takes exactly 1 argument (2 given)
On 2017-08-01 07:07, g...@greg-gilbert.com wrote:
> Hey,
>
> I checked the logs and found this:
>
> conn=3295 op=3 SRCH
> base="cn=certificates,cn=ipa,cn=etc,dc=ipa,dc=services,dc=example" scope=2
> filter="(&(objectClass=ipaCertificate)(objectClass=pkiCA))"
> attrs="ipaKeyExtUsage cn ipaCertSubject ipaPublicKey cacertificate;binary
> ipaKeyTrust ipaCertIssuerSerial"
> conn=3295 op=3 RESULT err=0 tag=101 nentries=1 etime=0
>
> So that looks like it's finding an entry, I guess.
>
> All of the lines have err=0 except these:
>
> conn=3295 op=0 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress
> conn=3295 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI
> conn=3295 op=1 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress
> conn=3295 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI
>
> The server is running FreeIPA 4.4:
>
> $ ipa --version
> VERSION: 4.4.0, API_VERSION: 2.213
> $ ipa-client-install --version
> 4.4.0
>
> - greg
>
> On 2017-08-01 05:13, Florence Blanc-Renaud wrote:
> On 08/01/2017 03:26 AM, None via FreeIPA-users wrote: I'm really at a loss on
> this one.
>
> I have a bunch of old server images (from 2 months ago) that can run
> ipa-client-install just fine. When I created a new image, though, I get this
> error (from the install logs):
>
> DEBUG flushing ldap://ipa.services.example:389 from SchemaCache
> DEBUG retrieving schema for SchemaCache url=ldap://ipa.services.example:389
> conn=
> DEBUG get_ca_certs_from_ldap() error: 'ipa.services.example' doesn't have a
> certificate.
> DEBUG 'ipa.services.example' doesn't have a certificate.
> ERROR In unattended mode without a One Time Password (OTP) or without
> --ca-cert-file
> You must specify --force to retrieve the CA cert using HTTP
> ERROR Cannot obtain CA certificate
> HTTP certificate download requires --force
> ERROR Installation failed. Rolling back changes.
> ERROR IPA client is not configured on this system.
>
> For comparison, the old images work as expected:
>
> DEBUG flushing ldap://ipa.services.example:389 from SchemaCache
> DEBUG retrieving schema for SchemaCache url=ldap://ipa.services.example:389
> conn=
> INFO Successfully retrieved CA cert
> Subject: CN=Certificate Authority,O=IPA.SERVICES.example
> Issuer: CN=Certificate Authority,O=IPA.SERVICES.example
> Valid From: Wed Apr 05 21:11:13 2017 UTC
> Valid Until: Sun Apr 05 21:11:13 2037 UTC
>
> It's literally the same build script, so nothing there has changed. The old
> images still work even now, so I don't think it's a DNS issue. I tried
> running update-ca-certificates, but that did nothing. I tried restarting the
> FreeIPA server, nothing changed.
>
> If I try --forceing the install, this happens:
>
> Enrolled in IPA realm IPA.SERVICES.EXAMPLE
> Created /etc/ipa/default.conf
> Traceback (most recent call last):
> File "/usr/sbin/ipa-client-install", line 3099, in
> sys.exit(main())
> File "/usr/sbin/ipa-client-install", line 3080, in main
> rval = install(options, env, fstore, statestore)
> File "/usr/sbin/ipa-client-install", line 2727, in install
> api.finalize()
> File "/usr/lib/python2.7/dist-packages/ipalib/plugable.py", line 656, in
> finalize
> self.__do_if_not_done('load_plugins')
> File "/usr/lib/python2.7/dist-packages/ipalib/plugable.py", line 370, in
> __do_if_not_done
> getattr(self, name)()
> File "/usr/lib/python2.7/dist-packages/ipalib/plugable.py", line 534, in
> load_plugins
> self.import_plugins(module)
> File
[Freeipa-users] Re: "Cannot obtain CA certificate" error when trying to install, but works on older instances; force fails
Hey,
I checked the logs and found this:
conn=3295 op=3 SRCH
base="cn=certificates,cn=ipa,cn=etc,dc=ipa,dc=services,dc=example"
scope=2 filter="(&(objectClass=ipaCertificate)(objectClass=pkiCA))"
attrs="ipaKeyExtUsage cn ipaCertSubject ipaPublicKey
cacertificate;binary ipaKeyTrust ipaCertIssuerSerial"
conn=3295 op=3 RESULT err=0 tag=101 nentries=1 etime=0
So that looks like it's finding an entry, I guess.
All of the lines have err=0 except these:
conn=3295 op=0 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in
progress
conn=3295 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI
conn=3295 op=1 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in
progress
conn=3295 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI
The server is running FreeIPA 4.4:
$ ipa --version
VERSION: 4.4.0, API_VERSION: 2.213
$ ipa-client-install --version
4.4.0
- greg
On 2017-08-01 05:13, Florence Blanc-Renaud wrote:
> On 08/01/2017 03:26 AM, None via FreeIPA-users wrote:
>
>> I'm really at a loss on this one.
>>
>> I have a bunch of old server images (from 2 months ago) that can run
>> ipa-client-install just fine. When I created a new image, though, I get this
>> error (from the install logs):
>>
>> DEBUG flushing ldap://ipa.services.example:389 from SchemaCache
>> DEBUG retrieving schema for SchemaCache url=ldap://ipa.services.example:389
>> conn=
>> DEBUG get_ca_certs_from_ldap() error: 'ipa.services.example' doesn't have a
>> certificate.
>> DEBUG 'ipa.services.example' doesn't have a certificate.
>> ERROR In unattended mode without a One Time Password (OTP) or without
>> --ca-cert-file
>> You must specify --force to retrieve the CA cert using HTTP
>> ERROR Cannot obtain CA certificate
>> HTTP certificate download requires --force
>> ERROR Installation failed. Rolling back changes.
>> ERROR IPA client is not configured on this system.
>>
>> For comparison, the old images work as expected:
>>
>> DEBUG flushing ldap://ipa.services.example:389 from SchemaCache
>> DEBUG retrieving schema for SchemaCache url=ldap://ipa.services.example:389
>> conn=
>> INFO Successfully retrieved CA cert
>> Subject: CN=Certificate Authority,O=IPA.SERVICES.example
>> Issuer: CN=Certificate Authority,O=IPA.SERVICES.example
>> Valid From: Wed Apr 05 21:11:13 2017 UTC
>> Valid Until: Sun Apr 05 21:11:13 2037 UTC
>>
>> It's literally the same build script, so nothing there has changed. The old
>> images still work even now, so I don't think it's a DNS issue. I tried
>> running update-ca-certificates, but that did nothing. I tried restarting the
>> FreeIPA server, nothing changed.
>>
>> If I try --forceing the install, this happens:
>>
>> Enrolled in IPA realm IPA.SERVICES.EXAMPLE
>> Created /etc/ipa/default.conf
>> Traceback (most recent call last):
>> File "/usr/sbin/ipa-client-install", line 3099, in
>> sys.exit(main())
>> File "/usr/sbin/ipa-client-install", line 3080, in main
>> rval = install(options, env, fstore, statestore)
>> File "/usr/sbin/ipa-client-install", line 2727, in install
>> api.finalize()
>> File "/usr/lib/python2.7/dist-packages/ipalib/plugable.py", line 656, in
>> finalize
>> self.__do_if_not_done('load_plugins')
>> File "/usr/lib/python2.7/dist-packages/ipalib/plugable.py", line 370, in
>> __do_if_not_done
>> getattr(self, name)()
>> File "/usr/lib/python2.7/dist-packages/ipalib/plugable.py", line 534, in
>> load_plugins
>> self.import_plugins(module)
>> File "/usr/lib/python2.7/dist-packages/ipalib/plugable.py", line 572, in
>> import_plugins
>> module = importlib.import_module(name)
>> File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
>> __import__(name)
>> File "/usr/lib/python2.7/dist-packages/ipalib/plugins/cert.py", line 29, in
>>
>> from ipalib import pkcs10
>> File "/usr/lib/python2.7/dist-packages/ipalib/pkcs10.py", line 79, in
>>
>> class _PrincipalName(univ.Sequence):
>> File "/usr/lib/python2.7/dist-packages/ipalib/pkcs10.py", line 84, in
>> _PrincipalName
>> namedtype.NamedType('name-string',
>> univ.SequenceOf(char.GeneralString()).subtype(
>> TypeError: __init__() takes exactly 1 argument (2 given)
>>
>> Really not sure what's going on here; does anyone have advice on how to fix
>> this? Thanks!
>>
>> ___
>> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Hi,
>
> during client installation, the installer tries to retrieve the CA
> certificate:
> - either from the provider --ca-cert-file
> - or from an existing /etc/ipa/ca.crt
> - or (when principal and password are supplied) via ldap
> - or (when the above failed) via http only if --force is supplied
>
> The ldap method looks for a certificate in
> cn=certificates,cn=ipa,cn=etc,$BASEDN or cn=CAcert,cn=ipa,cn=etc,$BASEDN.
>
> You can check if the CA certificate can be found by the installer. Do you see
> matching logs in the directory
[Freeipa-users] Re: "Cannot obtain CA certificate" error when trying to install, but works on older instances; force fails
On 08/01/2017 03:26 AM, None via FreeIPA-users wrote:
I'm really at a loss on this one.
I have a bunch of old server images (from 2 months ago) that can run
ipa-client-install just fine. When I created a new image, though, I get
this error (from the install logs):
DEBUG flushing ldap://ipa.services.example:389 from SchemaCache
DEBUG retrieving schema for SchemaCache
url=ldap://ipa.services.example:389
conn=
DEBUG get_ca_certs_from_ldap() error: 'ipa.services.example' doesn't
have a certificate.
DEBUG 'ipa.services.example' doesn't have a certificate.
ERROR In unattended mode without a One Time Password (OTP) or without
--ca-cert-file
You must specify --force to retrieve the CA cert using HTTP
ERROR Cannot obtain CA certificate
HTTP certificate download requires --force
ERROR Installation failed. Rolling back changes.
ERROR IPA client is not configured on this system.
For comparison, the old images work as expected:
DEBUG flushing ldap://ipa.services.example:389 from SchemaCache
DEBUG retrieving schema for SchemaCache
url=ldap://ipa.services.example:389
conn=
INFO Successfully retrieved CA cert
Subject: CN=Certificate Authority,O=IPA.SERVICES.example
Issuer: CN=Certificate Authority,O=IPA.SERVICES.example
Valid From: Wed Apr 05 21:11:13 2017 UTC
Valid Until: Sun Apr 05 21:11:13 2037 UTC
It's literally the same build script, so nothing there has changed. The
old images still work even now, so I don't think it's a DNS issue. I
tried running update-ca-certificates, but that did nothing. I tried
restarting the FreeIPA server, nothing changed.
If I try --forceing the install, this happens:
Enrolled in IPA realm IPA.SERVICES.EXAMPLE
Created /etc/ipa/default.conf
Traceback (most recent call last):
File "/usr/sbin/ipa-client-install", line 3099, in
sys.exit(main())
File "/usr/sbin/ipa-client-install", line 3080, in main
rval = install(options, env, fstore, statestore)
File "/usr/sbin/ipa-client-install", line 2727, in install
api.finalize()
File "/usr/lib/python2.7/dist-packages/ipalib/plugable.py", line 656,
in finalize
self.__do_if_not_done('load_plugins')
File "/usr/lib/python2.7/dist-packages/ipalib/plugable.py", line 370,
in __do_if_not_done
getattr(self, name)()
File "/usr/lib/python2.7/dist-packages/ipalib/plugable.py", line 534,
in load_plugins
self.import_plugins(module)
File "/usr/lib/python2.7/dist-packages/ipalib/plugable.py", line 572,
in import_plugins
module = importlib.import_module(name)
File "/usr/lib/python2.7/importlib/__init__.py", line 37, in
import_module
__import__(name)
File "/usr/lib/python2.7/dist-packages/ipalib/plugins/cert.py", line
29, in
from ipalib import pkcs10
File "/usr/lib/python2.7/dist-packages/ipalib/pkcs10.py", line 79, in
class _PrincipalName(univ.Sequence):
File "/usr/lib/python2.7/dist-packages/ipalib/pkcs10.py", line 84, in
_PrincipalName
namedtype.NamedType('name-string',
univ.SequenceOf(char.GeneralString()).subtype(
TypeError: __init__() takes exactly 1 argument (2 given)
Really not sure what's going on here; does anyone have advice on how to
fix this? Thanks!
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Hi,
during client installation, the installer tries to retrieve the CA
certificate:
- either from the provider --ca-cert-file
- or from an existing /etc/ipa/ca.crt
- or (when principal and password are supplied) via ldap
- or (when the above failed) via http only if --force is supplied
The ldap method looks for a certificate in
cn=certificates,cn=ipa,cn=etc,$BASEDN or cn=CAcert,cn=ipa,cn=etc,$BASEDN.
You can check if the CA certificate can be found by the installer. Do
you see matching logs in the directory server access log
(/var/log/dirsrv/slapd-xx/access), like the following:
[27/Jul/2017:09:48:14.923015575 +0200] conn=2 op=16 SRCH
base="cn=certificates,cn=ipa,cn=etc,dc=dom-ipa,dc=com" scope=2
filter="(&(objectClass=ipaCertificate)(objectClass=pkiCA))"
attrs="ipaKeyExtUsage cn ipaCertSubject ipaPublicKey
cacertificate;binary ipaKeyTrust ipaCertIssuerSerial"
[27/Jul/2017:09:48:14.923834321 +0200] conn=2 op=16 RESULT err=0 tag=101
nentries=1 etime=1
If yes, check the return code (err=x) and the number of found entries
(nentries=x).
When you run the installer with --force, the tool manages to retrieve
the cert using http but fails later. Which version of IPA are you using?
Flo.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: Failed Upgrade?
On 08/01/2017 01:32 AM, Ian Harding via FreeIPA-users wrote: On 07/31/2017 11:34 AM, Rob Crittenden wrote: Ian Harding via FreeIPA-users wrote: I had an unexpected restart of an IPA server that had apparently had updates run but had not been restarted. ipactl says pki-tomcatd would not start. Strangely, the actual service appears to be running: dogtag is an application within tomcat so tomcat can run without dogtag running. We need to see more of the dogtag debug log to see what is going on. It looks like an authentication problem... [28/Jul/2017:10:08:47][localhost-startStop-1]: SSL handshake happened Could not connect to LDAP server host seattlenfs.bpt.rocks port 636 Error netscape.ldap.LDAPException: Authentication failed (49) Hi, dogtag stores its internal data in the LDAP server and needs to establish a secure LDAP connection. You can check how this connection is configured in /etc/pki/pki-tomcat/ca/CS.cfg, look for the lines: internaldb.ldapauth.authtype=SslClientAuth internaldb.ldapauth.bindDN=cn=Directory Manager internaldb.ldapauth.bindPWPrompt=internaldb internaldb.ldapauth.clientCertNickname=subsystemCert cert-pki-ca internaldb.ldapconn.host=vm-... internaldb.ldapconn.port=636 internaldb.ldapconn.secureConn authtype can be SslClientAuth (authentication with a ssl certificate) or BasicAuth (authentication with a bind DN and password stored in /var/lib/pki/pki-tomcat/conf/password.conf). You can use this information to manually check the credentials. For instance with sslclientauth: export LDAPTLS_CACERTDIR=/etc/pki/pki-tomcat/alias export LDAPTLS_CERT='subsystemCert cert-pki-ca' ldapsearch -H ldaps://`hostname`:636 -b "" -s base -Y EXTERNAL (provide the password from /etc/pki/pki-tomcat/alias/pwdfile.txt) HTH, Flo. at org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1966) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Internal Database Error encountered: Could not connect to LDAP server host seattlenfs.bpt.rocks port 636 Error netscape.ldap.LDAPException: Authentication failed (49) at com.netscape.cmscore.dbs.DBSubsystem.init(DBSubsystem.java:676) at com.netscape.cmscore.apps.CMSEngine.initSubsystem(CMSEngine.java:1172) at com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:1078) at com.netscape.cmscore.apps.CMSEngine.init(CMSEngine.java:570) at com.netscape.certsrv.apps.CMS.init(CMS.java:188) at com.netscape.certsrv.apps.CMS.start(CMS.java:1621) at com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:114) at javax.servlet.GenericServlet.init(GenericServlet.java:158) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 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.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:124) at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1270) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1195) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1085) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5318) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5610) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:147) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:899) at org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:133) at org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:156) at org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:145) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:873) at
