Hello all,
I have a problem with logging in to the web interface (username/pw) of one of my IPA servers, ipa2.
The installation is CA-less, without pkinit, and consists of master servers ipa1 and ipa2
Ipa1 works fine at this time, ipa2 fails with "Login failed due to an unknown reason." in the web ui.
In the httpd error log:
calledProcessError: Command '/usr/bin/kinit -n -c /var/run/ipa/ccaches/armor_11164 -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
If I try to run /kinit -n - -X X509_anchors=FILE:/var/kerberos/krb5kdc/kdc.crt -X X509_anchors=FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem
for testing on ipa2, it asks me for a password (which I don't know).
Doing the same on ipa1 will not ask for a password, but simply adds the WELLKNOWN/ANONYMOUS principal to the keyring:
[root@charon run]# LANG=C klist -a Ticket cache: KEYRING:persistent:0:krb_ccache_vscxoCZ Default principal: WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS
Valid starting Expires Service principal 22.07.2024 17:21:34 23.07.2024 17:21:34 krbtgt/NET.IDA@NET.IDA Addresses: (none)
So I guess this might be part of the problem.
Note that "kinit <user>" with a password I know works fine on ipa2.
What can I do to fix this?
I should say I had the same problem 2 years ago or so, but with reversed roles (ipa1 not allowing login, ipa2 working fine).
According to my notes from back then, a "systemctl restart sssd" fixed it that time. Unfortunately this does not seem to help this time.
Many thanks for any ideas,
Thomas Boroske
I noticed that the referenced files in /var/kerberos/krb5kdc differ. They also have quite different modification dates- On ipa1, the kdc.crt is older (22.Auf 2023), on ipa2 it is much newer (13. Jan 2024)
I looked into the certs with openssl x509 -in kdc.crt -text
These certs are not issued by our CA authority, they must be something created by IPA internally.
Comparing the certs with meld, I noticed different dates, of course, but also that the cert on the working ipa1 server has sections that are missing by the other cert, namely
X509v3 Subject Alternative Name: othername:<unsupported>, othername:<unsupported>
and X509v3 Subject Key Identifier: 46:31:70:5C:55:B6:9F:D5:EC:29:9C:54:AE:3B:53:F5:0B:91:39:3A 1.3.6.1.4.1.311.20.2: .".K.D.C.s._.P.K.I.N.I.T._.C.e.r.t.s
ISTR remember there was another thread where someone had similar issue and solved it be requesting a new cert?
I
There is my own thread from 2020 with answers from flo :-)
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
Flo always solves my IPA problems, even with a 4 year old answer :-)
Thanks again for that.
For people searching this later: The problem can be fixed using:
$ getcert list -f /var/kerberos/krb5kdc/kdc.crt (note the request Id) $ getcert resubmit -i <request id> $ getcert list -i <request id>
After that, the kdc.crt is a new one, and this one contains the Subject Alternative Name field.
And web logins immediately work again.
Thomas Boroske via FreeIPA-users wrote:
Flo always solves my IPA problems, even with a 4 year old answer :-)
Thanks again for that.
For people searching this later: The problem can be fixed using:
$ getcert list -f /var/kerberos/krb5kdc/kdc.crt (note the request Id) $ getcert resubmit -i <request id> $ getcert list -i <request id>
After that, the kdc.crt is a new one, and this one contains the Subject Alternative Name field.
And web logins immediately work again.
To throw in a little certmonger tip, you can do it all in one step:
# getcert resubmit -f /var/kerberos/krb5kdc/kdc.crt -v -w
resubmit and list can take more or less the same options. -v is verbose mode and will display the states of the request. -w will wait for it to pass or fail.
rob
freeipa-users@lists.fedorahosted.org
-
Rob Crittenden -
Thomas Boroske