ipa-getcert request results in CA_REJECTED, on an enrolled host

[Bo Lind]

I'm having a weird one. This has worked well on a number of other, identical hosts, but one is repeatedly giving me trouble:

root@naughtyhost:~# ipa-getcert request -f /etc/pki/tls/certs/xrdp.pem -k /etc/pki/tls/private/xrdp.key -r -w -v
New signing request "20240312125107" added.
State NEWLY_ADDED_READING_KEYINFO, stuck: no.
State SUBMITTING, stuck: no.
State CA_REJECTED, stuck: yes.

root@naughtyhost:~# ipa-getcert list
Number of certificates and requests being tracked: 1.
Request ID '20240312125107':
    status: CA_REJECTED
    ca-error: Server at https://idm0.example.local/ipa/json denied our request, giving up: 2100 (Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Credential cache is empty)).
    stuck: yes
    key pair storage: type=FILE,location='/etc/pki/tls/private/xrdp.key'
    certificate: type=FILE,location='/etc/pki/tls/certs/xrdp.pem'
    CA: IPA
    issuer: 
    subject: 
    issued: unknown
    expires: unknown
    pre-save command: 
    post-save command: 
    track: yes
    auto-renew: yes

I've tried looking in the logfiles on idm0, but couldn't really find anything useful.

[Alexander Bokovoy]

On Аўт, 12 сак 2024, Bo Lind via FreeIPA-users wrote:
> I'm having a weird one. This has worked well on a number of other, identical hosts, but one is repeatedly giving me trouble:
>
> root@naughtyhost:~# ipa-getcert request -f /etc/pki/tls/certs/xrdp.pem -k /etc/pki/tls/private/xrdp.key -r -w -v
> New signing request "20240312125107" added.
> State NEWLY_ADDED_READING_KEYINFO, stuck: no.
> State SUBMITTING, stuck: no.
> State CA_REJECTED, stuck: yes.
>
> root@naughtyhost:~# ipa-getcert list
> Number of certificates and requests being tracked: 1.
> Request ID '20240312125107':
>    status: CA_REJECTED
>    ca-error: Server at https://idm0.example.local/ipa/json denied our request, giving up: 2100 (Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Credential cache is empty)).
>    stuck: yes
>    key pair storage: type=FILE,location='/etc/pki/tls/private/xrdp.key'
>    certificate: type=FILE,location='/etc/pki/tls/certs/xrdp.pem'
>    CA: IPA
>    issuer:
>    subject:
>    issued: unknown
>    expires: unknown
>    pre-save command:
>    post-save command:
>    track: yes
>    auto-renew: yes
>
> I've tried looking in the logfiles on idm0, but couldn't really find anything useful.

I think it might be a problem with old host/service objects.
Can you check if 'ipa host-show --all --raw hostname' returns
krbCanonicalName attribute? If it is not there, you can set one with

ipa host-mod hostname --addattr krbcanonicalname=host/hostname@REALM

See https://pagure.io/freeipa/issue/9465 for some details.

[Bo Lind]

root@naughtyhost:~# ipa host-show --all --raw naughtyhost|grep -i canon
  krbcanonicalname: host/[e-mail]

Looks like that part is in order...? Does the capitalization matter?

[Bo Lind]

Just updated the machine to newest Rocky Linux 8.9 and rebooted, problem persists...

[Alexander Bokovoy]

On Аўт, 12 сак 2024, Bo Lind via FreeIPA-users wrote:
> root@naughtyhost:~# ipa host-show --all --raw naughtyhost|grep -i canon
>  krbcanonicalname: host/[e-mail]
>
> Looks like that part is in order...? Does the capitalization matter?

It does.

When you attempt to do that request, what do you see in the
/var/log/krb5kdc.log on the IPA server, related to requests from this
host?

Typically you'd see something like the sequence below. I am using
'master2.ipa2.test' which is an IPA server in itself as an example here,
but for your case host/master2.ipa2.test would be
host/naughtyhost.example.local and it would talk to your IPA server:

1. Get TGT using the host keytab:
Mar 13 09:36:00 master2.ipa2.test krb5kdc[548787](info): AS_REQ (6 etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 10.0.192.177: NEEDED_PREAUTH: host/[e-mail] for krbtgt/[e-mail], Additional pre-authentication required
Mar 13 09:36:00 master2.ipa2.test krb5kdc[548787](info): closing down fd 11
Mar 13 09:36:00 master2.ipa2.test krb5kdc[548787](info): AS_REQ (6 etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 10.0.192.177: ISSUE: authtime 1710322560, etypes {rep=aes256-cts-hmac-sha384-192(20), tkt=aes256-cts-hmac-sha384-192(20), ses=aes256-cts-hmac-sha384-192(20)}, host/[e-mail] for krbtgt/[e-mail]
Mar 13 09:36:00 master2.ipa2.test krb5kdc[548787](info): closing down fd 11

2. Request a service ticket to IPA API:
Mar 13 09:36:00 master2.ipa2.test krb5kdc[548787](info): TGS_REQ (6 etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 10.0.192.177: ISSUE: authtime 1710322560, etypes {rep=aes256-cts-hmac-sha384-192(20), tkt=aes256-cts-hmac-sha384-192(20), ses=aes256-cts-hmac-sha384-192(20)}, host/[e-mail] for HTTP/[e-mail]
Mar 13 09:36:00 master2.ipa2.test krb5kdc[548787](info): closing down fd 11

3. IPA API needs to talk to LDAP server so it needs own TGT ticket
first:
Mar 13 09:36:00 master2.ipa2.test krb5kdc[548788](info): AS_REQ (6 etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 10.0.192.177: NEEDED_PREAUTH: HTTP/[e-mail] for krbtgt/[e-mail], Additional pre-authentication required
Mar 13 09:36:00 master2.ipa2.test krb5kdc[548788](info): closing down fd 11
Mar 13 09:36:00 master2.ipa2.test krb5kdc[548787](info): AS_REQ (6 etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 10.0.192.177: ISSUE: authtime 1710322560, etypes {rep=aes256-cts-hmac-sha384-192(20), tkt=aes256-cts-hmac-sha384-192(20), ses=aes256-cts-hmac-sha384-192(20)}, HTTP/[e-mail] for krbtgt/[e-mail]
Mar 13 09:36:00 master2.ipa2.test krb5kdc[548787](info): closing down fd 11

4. And then asks for a service ticket to LDAP service on behalf of the
original Kerberos client (host requesting an operation):
Mar 13 09:36:00 master2.ipa2.test krb5kdc[548787](info): TGS_REQ (6 etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 10.0.192.177: ISSUE: authtime 1710322560, etypes {rep=aes256-cts-hmac-sha384-192(20), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha384-192(20)}, HTTP/[e-mail] for ldap/[e-mail]
Mar 13 09:36:00 master2.ipa2.test krb5kdc[548787](info): ... CONSTRAINED-DELEGATION s4u-client=host/[e-mail]
Mar 13 09:36:00 master2.ipa2.test krb5kdc[548787](info): closing down fd 11

If you'd see any breakage in those steps, show the log.

[Bo Lind]

I don't get very far. Step one is non-existant, I never get the AS_REQ, even going back several days in the log.

For step two, I get:

Mar 13 10:51:29 idm0.example.local krb5kdc[1704](info): TGS_REQ (6 etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 192.168.37.50: S4U2PROXY_MISSING_EXTENDED_KDC_SIGN_IN_EVIDENCE_TKT_PAC: authtime 1710323487, etypes {rep=UNSUPPORTED:(0)} HTTP/[e-mail] for ldap/[e-mail], KDC policy rejects request
Mar 13 10:51:29 idm0.example.local krb5kdc[1704](info): ... CONSTRAINED-DELEGATION s4u-client=<unknown>
Mar 13 10:51:29 idm0.example.local krb5kdc[1704](info): closing down fd 4

(I know that naughtyhost.example.local is not mentioned in the entry, but it happened as I attempted the request; I watched the log in realtime.)

And, obviously, we never get step three and four either.

Thanks for your continuous help, by the way!

[Bo Lind]

Update!

Our organisation has four IPA servers. I tried to edit /etc/ipa/default.conf, to point at a different one. Server two didn't work either, but server three did!

[Alexander Bokovoy]

On Срд, 13 сак 2024, Bo Lind via FreeIPA-users wrote:
> Update!
>
> Our organisation has four IPA servers. I tried to edit
> /etc/ipa/default.conf, to point at a different one. Server two didn't
> work either, but server three did!

Perhaps some of those are RHEL9?

See https://access.redhat.com/articles/7046409 for some details on what
you are seeing. It also explains what should be done and in which order.