just now getting back to this, have been truncating httpd logs via cron since 
then to keep from filing up my disk.

So, does this ring any bells :)

[Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: IPA: virtual verify retrieve 
certificate
[Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: Not granted by ACI to retrieve 
certificate, looking at principal
[Wed Dec 14 00:38:39 2016] [error] ipa: INFO: 
host/phoenix-168.nym1.placeiq....@placeiq.net: 
cert_request(u'MIID4zCCAssCAQAwPTEUMBIGA1UEChMLUExBQ0VJUS5ORVQxJTAjBgNVBAMTHHBob2VuaXgtMTY4Lm55bTEucGxhY2VpcS5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDboyDDyTaP4+LxYThfy1w7C67TN2qBp8JjA7Y55gnthyUp/PUUXmm3FUQ4yG4cBqDSxZcUWzl+eA33/ceSIp0HtVl34ZkkUitY1hmUvu2nh16ReR65YC+qRqkAIypOilLdPzXIWZ7u5LbM/Xpj3/Npzm18UupAAznNXkZnojuPmAQ+ulPGypyefLnhr5my6hIaR1atTm1ZvHTG3raMJOJhFe4jMeI/tgPVdNCUfOUdEKhmmCm5KivxhTtHMEcH+8obuQnbaSokJscxlzHBLiyQGqhAn5gznXg0mlVCC0H4mwdB1g2g9cG+SxSua/7XCm+AnGXlc75MZAt594QBTc3fAgMBAAGgggFfMHsGCSqGSIb3DQEJFDFuHmwASQBQAEEAIABNAGEAYwBoAGkAbgBlACAAQwBlAHIAdABpAGYAaQBjAGEAdABlACAALQAgAHAAaABvAGUAbgBpAHgALQAxADYAOAAuAG4AeQBtADEALgBwAGwAYQBjAGUAaQBxAC4AbgBlAHQwgd8GCSqGSIb3DQEJDjGB0TCBzjCBmwYDVR0RAQEABIGQMIGNoD0GCisGAQQBgjcUAgOgLwwtaG9zdC9waG9lbml4LTE2OC5ueW0xLnBsYWNlaXEubmV0QFBMQUNFSVEuTkVUoEwGBisGAQUCAqBCMECgDRsLUExBQ0VJUS5ORVShLzAtoAMCAQGhJjAkGwRob3N0GxxwaG9lbml4LTE2OC5ueW0xLnBsYWNlaXEubmV0MAwGA1UdEwEB/wQCMAAwIAYDVR0OAQEABBYEFKDhj0rZ6mZwJfrJx3pCI12dct5WMA0GCSqGSIb3DQEBCwUAA4IBAQC/zeFtiiiJXi9bws2NWx2u/vB7aTVRci2yb9wb70dUzcpeJ3qRTqsE5I+D3MHxLYnixrG4iMEaWgEyuJy4SIWqW1YVSrHwhJZufyRnxy7luNXON+TBBBI0Gro5gICy9XiDKbA/q6clYzEbwDLe6Es/U5/h4Bl/ziV61KYCJN0P1bMWI21A73iP3EQHx2lefYxI8BJN68hJLQiK+E0IWGCqfvipTHA0bHYSQy6WFmmS96v0wr93jy783iromycZeXWzFJyx+LruVPmPOewmUOJ2Y2NJNPJv35pPYUw5Dt2hlLgWZ18po8C+XYqvMbzxM2DFlxMX3Ff+ZiwCRYSGknFI',
 principal=u'host/phoenix-168.nym1.placeiq....@placeiq.net', add=True): ACIError
[Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: response: ACIError: Insufficient 
access: Gettext('not allowed to perform this command', domain='ipa', 
localedir=None)
[Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: no session id in request, 
generating empty session data with id=9beb89831ebfca453453ad48feaaa4d0
[Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: store session: 
session_id=9beb89831ebfca453453ad48feaaa4d0 start_timestamp=2016-12-14T00:38:39 
access_timestamp=2016-12-14T00:38:39 expiration_timestamp=1970-01-01T00:00:00
[Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: finalize_kerberos_acquisition: 
xmlserver ccache_name="FILE:/tmp/krb5cc_apache_SQg9kf" 
session_id="9beb89831ebfca453453ad48feaaa4d0"
[Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: reading ccache data from file 
"/tmp/krb5cc_apache_SQg9kf"
[Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: get_credential_times: 
principal=krbtgt/placeiq....@placeiq.net, authtime=12/14/16 00:38:36, 
starttime=12/14/16 00:38:37, endtime=12/15/16 00:38:36, renew_till=01/01/70 
00:00:00
[Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: KRB5_CCache 
FILE:/tmp/krb5cc_apache_SQg9kf endtime=1481762316 (12/15/16 00:38:36)
[Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: set_session_expiration_time: 
duration_type=inactivity_timeout duration=1200 max_age=1481762016 
expiration=1481677119.46 (2016-12-14T00:58:39)
[Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: store session: 
session_id=9beb89831ebfca453453ad48feaaa4d0 start_timestamp=2016-12-14T00:38:39 
access_timestamp=2016-12-14T00:38:39 expiration_timestamp=2016-12-14T00:58:39
[Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: Destroyed connection 
context.ldap2




 <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 2, 2016, at 5:29 PM, Rob Crittenden <rcrit...@redhat.com> wrote:
> 
> 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

Reply via email to