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 = {
kdc = sso-110.nym1.placeiq.net:88
master_kdc = sso-110.nym1.placeiq.net:88
admin_server = sso-110.nym1.placeiq.net:749
default_domain = 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.
_ldap._tcp IN SRV 0 100 389 sso-110.nym1.placeiq.net.
;kerberos realm
_kerberos IN TXT PLACEIQ.NET
; kerberos servers
_kerberos._tcp IN SRV 0 100 88 sso-109.nym1.placeiq.net.
_kerberos._tcp IN SRV 0 100 88 sso-110.nym1.placeiq.net.
_kerberos._udp IN SRV 0 100 88 sso-109.nym1.placeiq.net.
_kerberos._udp IN SRV 0 100 88 sso-110.nym1.placeiq.net.
_kerberos-master._tcp IN SRV 0 100 88 sso-109.nym1.placeiq.net.
_kerberos-master._udp IN SRV 0 100 88 sso-109.nym1.placeiq.net.
_kerberos-adm._tcp IN SRV 0 100 749 sso-109.nym1.placeiq.net.
_kerberos-adm._udp IN SRV 0 100 749 sso-109.nym1.placeiq.net.
_kpasswd._tcp IN SRV 0 100 464 sso-109.nym1.placeiq.net.
_kpasswd._tcp IN SRV 0 100 464 sso-110.nym1.placeiq.net.
_kpasswd._udp IN SRV 0 100 464 sso-109.nym1.placeiq.net.
_kpasswd._udp IN SRV 0 100 464 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',token='NSS Certificate DB'
certificate: type=NSSDB,location='/etc/pki/nssdb',nickname='IPA Machine
Certificate - phoenix-142.nym1.placeiq.net',token='NSS Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=PLACEIQ.NET
subject: CN=phoenix-142.nym1.placeiq.net,O=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 :)
<http://www.placeiq.com/> <http://www.placeiq.com/> <http://www.placeiq.com/>
Jim Richard <https://twitter.com/placeiq> <https://twitter.com/placeiq>
<https://twitter.com/placeiq> <https://www.facebook.com/PlaceIQ>
<https://www.facebook.com/PlaceIQ> <https://www.linkedin.com/company/placeiq>
<https://www.linkedin.com/company/placeiq>
SYSTEM ADMINISTRATOR III
(646) 338-8905
<http://placeiq.com/2016/10/26/the-making-of-a-location-data-industry-milestone/>
> On Dec 1, 2016, at 10:56 PM, Rob Crittenden <rcrit...@redhat.com> wrote:
>
> Jim Richard wrote:
>> I think I know what the issue is.
>>
>> I had 2 IPA servers, both with CA’s
>>
>> I dropped one and rebuilt without the CA but a bunch of clients are
>> still pointing at this one server that now is without a CA.
>>
>> Will rebuild that one with a CA and almost sure that will fix.
>
> I'm rather skeptical of that. Not having a CA should not result in an
> ACI error. It should internally forward any cert requests to an IPA
> server that does have a CA and relay the result back to the requester.
>
> rob
>
>>
>> <http://www.placeiq.com/><http://www.placeiq.com/><http://www.placeiq.com/>
>> Jim Richard
>> <https://twitter.com/placeiq><https://twitter.com/placeiq><https://twitter.com/placeiq>
>> <https://www.facebook.com/PlaceIQ><https://www.facebook.com/PlaceIQ>
>> <https://www.linkedin.com/company/placeiq><https://www.linkedin.com/company/placeiq>
>> SYSTEM ADMINISTRATOR III
>> /(646) 338-8905 /
>>
>>
>> PlaceIQ:Alibaba
>> <http://placeiq.com/2016/10/26/the-making-of-a-location-data-industry-milestone/>
>>
>>
>>
>>
>>> On Nov 28, 2016, at 2:39 PM, Rob Crittenden <rcrit...@redhat.com
>>> <mailto:rcrit...@redhat.com>> wrote:
>>>
>>> Jim Richard wrote:
>>>> Honestly Im not even sure if something is not working correctly :)
>>>>
>>>> All I know is that my httpd, access and krb5 logs are filling up all my
>>>> disk space extremely quickly and I have no idea why.
>>>>
>>>> Centos 6.8 + IPA 3.0
>>>>
>>>> One master and one replica.
>>>>
>>>> Are these things related?
>>>>
>>>> How do I fix, where do I even start?
>>>>
>>>> Thanks !
>>>>
>>>> On the replica the httpd log is constantly getting spammed with:
>>>>
>>>> [Thu Nov 24 05:55:18 2016] [error] ipa: INFO:
>>>> host/phoenix-153.nym1.placeiq....@placeiq.net
>>>> <mailto:host/phoenix-153.nym1.placeiq....@placeiq.net>:
>>>> cert_request(uactual cert removed
>>> .. , add=True): ACIError
>>>>
>>>> and on the master the access log is filling up quickly with:
>>>>
>>>> 10.1.41.110 - - [24/Nov/2016:06:09:54 +0000] "POST
>>>> /ca/agent/ca/displayBySerial HTTP/1.1" 200 10106
>>>
>>> Looks like certmonger trying to renew the per-client SSL certificate.
>>> You can confirm by pulling out the CSR and poking at it with openssl req.
>>>
>>> On the client you can try running: ipa-getcert list
>>>
>>> This may show more details on why the request was rejected.
>>>
>>> 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
