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.
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.
root@naughtyhost:~# ipa host-show --all --raw naughtyhost|grep -i canon krbcanonicalname: host/naughtyhost.example.local@EXAMPLE.LOCAL
Looks like that part is in order...? Does the capitalization matter?
Just updated the machine to newest Rocky Linux 8.9 and rebooted, problem persists...
On Аўт, 12 сак 2024, Bo Lind via FreeIPA-users wrote:
root@naughtyhost:~# ipa host-show --all --raw naughtyhost|grep -i canon krbcanonicalname: host/naughtyhost.example.local@EXAMPLE.LOCAL
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/master2.ipa2.test@IPA2.TEST for krbtgt/IPA2.TEST@IPA2.TEST, 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/master2.ipa2.test@IPA2.TEST for krbtgt/IPA2.TEST@IPA2.TEST 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/master2.ipa2.test@IPA2.TEST for HTTP/master2.ipa2.test@IPA2.TEST 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/master2.ipa2.test@IPA2.TEST for krbtgt/IPA2.TEST@IPA2.TEST, 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/master2.ipa2.test@IPA2.TEST for krbtgt/IPA2.TEST@IPA2.TEST 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/master2.ipa2.test@IPA2.TEST for ldap/master2.ipa2.test@IPA2.TEST Mar 13 09:36:00 master2.ipa2.test krb5kdc[548787](info): ... CONSTRAINED-DELEGATION s4u-client=host/master2.ipa2.test@IPA2.TEST 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.
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/idm0.example.local@EXAMPLE.LOCAL for ldap/idm0.example.local@EXAMPLE.LOCAL, 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!
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!
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.
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
Bo Lind