Jim Richard wrote: > Hmm ya. So before I rebuilt anything I thought maybe it was my DNS > records but it looks like that’s not it. > > More background, I used to have sso-109 and sso-110, both CA’s. I > rebuilt sso-110 without CA. > > My DNS is external, BIND on another host. > > Using the following (at the end of the message) host/key issue as an > example. On this host, in sssd.conf, ipa_server and krb5_server values > are both _srv_ so that means they’ll discover from DNS right? > > But in my krb5.conf I have: > > [realms] > PLACEIQ.NET <http://placeiq.net> = { > kdc = sso-110.nym1.placeiq.net <http://sso-110.nym1.placeiq.net>:88 > master_kdc = sso-110.nym1.placeiq.net > <http://sso-110.nym1.placeiq.net>:88 > admin_server = sso-110.nym1.placeiq.net > <http://sso-110.nym1.placeiq.net>:749 > default_domain = placeiq.net <http://placeiq.net> > pkinit_anchors = FILE:/etc/ipa/ca.crt > } > > > Is there any other IPA related config file that might reference a host name? > > I’ll include my DNS records at the end here, do they look correct for a > two server setup, one with a CA (sso-109) and the other no CA (sso-110)? > > I never have been sure about the “kerberos-master” entries, what makes > an IPA host a “kerberos master” and is this related to the CA in any way? > > ; ldap servers > _ldap._tcp IN SRV 0 100 389 sso-109.nym1.placeiq.net > <http://sso-109.nym1.placeiq.net>. > _ldap._tcp IN SRV 0 100 389 sso-110.nym1.placeiq.net > <http://sso-110.nym1.placeiq.net>. > > ;kerberos realm > _kerberos IN TXT PLACEIQ.NET <http://placeiq.net> > > ; kerberos servers > _kerberos._tcp IN SRV 0 100 88 sso-109.nym1.placeiq.net > <http://sso-109.nym1.placeiq.net>. > _kerberos._tcp IN SRV 0 100 88 sso-110.nym1.placeiq.net > <http://sso-110.nym1.placeiq.net>. > > _kerberos._udp IN SRV 0 100 88 sso-109.nym1.placeiq.net > <http://sso-109.nym1.placeiq.net>. > _kerberos._udp IN SRV 0 100 88 sso-110.nym1.placeiq.net > <http://sso-110.nym1.placeiq.net>. > > _kerberos-master._tcp IN SRV 0 100 88 sso-109.nym1.placeiq.net > <http://sso-109.nym1.placeiq.net>. > _kerberos-master._udp IN SRV 0 100 88 sso-109.nym1.placeiq.net > <http://sso-109.nym1.placeiq.net>. > _kerberos-adm._tcp IN SRV 0 100 749 sso-109.nym1.placeiq.net > <http://sso-109.nym1.placeiq.net>. > _kerberos-adm._udp IN SRV 0 100 749 sso-109.nym1.placeiq.net > <http://sso-109.nym1.placeiq.net>. > > _kpasswd._tcp IN SRV 0 100 464 sso-109.nym1.placeiq.net > <http://sso-109.nym1.placeiq.net>. > _kpasswd._tcp IN SRV 0 100 464 sso-110.nym1.placeiq.net > <http://sso-110.nym1.placeiq.net>. > > _kpasswd._udp IN SRV 0 100 464 sso-109.nym1.placeiq.net > <http://sso-109.nym1.placeiq.net>. > _kpasswd._udp IN SRV 0 100 464 sso-110.nym1.placeiq.net > <http://sso-110.nym1.placeiq.net>. > > ; CNAME for IPA CA replicas (used for CRL, OCSP) > ipa-ca IN A 10.1.41.109 > > > > Number of certificates and requests being tracked: 1. > Request ID '20141110221330': > status: MONITORING > ca-error: Server at https://sso-110.nym1.placeiq.net/ipa/xml > denied our request, giving up: 2100 (RPC failed at server. Insufficient > access: not allowed to perform this command). > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/nssdb',nickname='IPA Machine Certificate - > phoenix-142.nym1.placeiq.net > <http://phoenix-142.nym1.placeiq.net>',token='NSS Certificate DB' > certificate: type=NSSDB,location='/etc/pki/nssdb',nickname='IPA > Machine Certificate - phoenix-142.nym1.placeiq.net > <http://phoenix-142.nym1.placeiq.net>',token='NSS Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=PLACEIQ.NET <http://placeiq.net> > subject: CN=phoenix-142.nym1.placeiq.net > <http://phoenix-142.nym1.placeiq.net>,O=PLACEIQ.NET <http://placeiq.net> > expires: 2016-11-10 22:13:31 UTC > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: > track: yes > auto-renew: yes > > > > We are moving to latest version on RHEL so we’ll have paid support but > before than, gaining this understanding is massively valuable :)
I'm pretty certain this has nothing to do with servers being removed. IPA isn't saying it can't find something, it's saying you aren't allowed to do something. Why that is the case I don't know. A way to maybe find out would involve enabling debugging on the server. You can do this by creating /etc/ipa/server.conf with these contents: [global] debug=True Restart httpd and watch. I'd leave it on just long enough to see the problem, then turn it off again given you are already having disk space issues. There is no way to dynamically do this w/o restarting the service. rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project