On ti, 06 loka 2020, Randall Hodges via FreeIPA-users wrote:
I just started working for a new company and they handed me this IPA
replication server with an issue logging on to the web UI. I get errors
when we try to login. I have been all over the web looking for answers.
I have check the permission of all the certs and they are correct all
have 0644 on them. I have done strace on the WSGI pids with no answers.
I have no idea if this ever worked from the install since I just
started working for the company last week and the guy who built it is
no longer there. I have noticed that since it cannot authenticate it
will not write to ccache in /var/run/ipa/ccaches. Everything works from
the command line with no issue. I can also run kinit admin and put the
password in with no issues. If I run a curl from command it works no
issues. Just cant login in from the browser. I have restart ipa using
ipactl restart. All the services are running just fine. However I
noticed in the log file for the install there were errors. I don't know
if this ever worked or not. This is replicating back to known working
servers just fine. I was added and it shows up in the server.
stderr=kinit: Client 'WELLKNOWN/ANONYMOUS@.example.us' not found in Kerberos
database while getting initial credentials
CalledProcessError: Command '/usr/bin/kinit -n -c /var/run/ipa/ccaches/armor_25969 -X
X509_anchors=FILE:/var/kerberos/krb5kdc/kdc.crt -X
X509_anchors=FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem' returned non-zero exit
status 1
[root@Server ccaches]# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: admin(a)example.us
Valid starting Expires Service principal
10/06/2020 15:09:44 10/06/2020 20:56:18 HTTP/Server.US
10/05/2020 20:56:30 10/06/2020 20:56:18
I assume you have replaced proper values of your realm above with these
invalid ones (e.g. EXAMPLE.US -> example.us) and the leading dot in the
realm is a part of your replacement process.
What is the output of
ipa-pkinit-manage status
?
See
https://www.freeipa.org/page/V4/Kerberos_PKINIT for details,
including expected status for different CA configurations -- see Feature
Management and Upgrade sections.
'ipa-pkinit-manage enable' should try to request proper PKINIT
certificates for KDC from IPA CA. If it fails, it will go back
self-signed issued cert on IPA master itself. This is visible in the
'getcert list' output:
# getcert list -f /var/kerberos/krb5kdc/kdc.crt
Number of certificates and requests being tracked: 13.
Request ID '20201002134720':
status: MONITORING
stuck: no
key pair storage: type=FILE,location='/var/kerberos/krb5kdc/kdc.key'
certificate: type=FILE,location='/var/kerberos/krb5kdc/kdc.crt'
CA: IPA
issuer: CN=Certificate Authority,O=IPA.TEST
subject: CN=master.ipa.test,O=IPA.TEST
expires: 2022-10-03 13:47:20 UTC
principal name: krbtgt/IPA.TEST(a)IPA.TEST
key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-pkinit-KPKdc
profile: KDCs_PKINIT_Certs
pre-save command:
post-save command: /usr/libexec/ipa/certmonger/renew_kdc_cert
track: yes
auto-renew: yes
'issuer' above is my IPA CA. On self-signed system ('local PKINIT' in
the wiki page) you'll have CN=master.ipa.test,O=IPA.TEST instead.
A fix for IPA CA is typically to do a cycle of
ipa-pkinit-manage disable
ipa-pkinit-manage enable
For externally provided certificates, you have to use
ipa-pkinit-manage disable
so that only local PKINIT is in use. It is unlikely that your external
CA knows how to issue a certificate for KDC with the correct values as
above, including id-pkinit-KPKdc EKU and Kerberos principal of your
realm's TGT.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland