On ma, 24 tammi 2022, Ronald Wimmer wrote:
> On 24.01.22 09:55, Alexander Bokovoy wrote:
>> On ma, 24 tammi 2022, Ronald Wimmer wrote:
>>> On 17.01.22 17:53, Alexander Bokovoy wrote:
>>>> On ma, 17 tammi 2022, Rob Crittenden via FreeIPA-users wrote:
>>>>> Ronald Wimmer via FreeIPA-users wrote:
>>>>>> On 13.01.22 09:29, Ronald Wimmer via FreeIPA-users wrote:
>>>>>>> Today the problem reappeared. I cannot login with the admin
>>>>>>> user. The
>>>>>>> error message I get is "The password or username you
entered is
>>>>>>> incorrect". kinit also does not work.
>>>>>>>
>>>>>>> It seems that the password has changed somehow without user
>>>>>>> interaction.
>>>>>>>
>>>>>>> How can we debug this?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Ronald
>>>>>>
>>>>>> We could verify that the user is neither locked nor disabled.
The
>>>>>> password has not changed since we reset it. There is no obvious
>>>>>> reason
>>>>>> why the password is not accepted anymore.
>>>>>>
>>>>>> Whats strange is the fact that a particular IPA server says
'Failed
>>>>>> logins: 0' but shows a 'Last failed authentication'
timestamp
>>>>>> that is
>>>>>> later than the 'Last successful authentication'
timestamp.
>>>>>
>>>>> I suppose what I would do, as DM, is to take a snapshot of one of
the
>>>>> broken entries, because you want the userPassword,
>>>>> krbPrincipalKey, etc.
>>>>> Then reset the password. If it breaks again compare the stored and
>>>>> new
>>>>> entry to see what, if anything, is different.
>>>>>
>>>>> Including things like logs for a failing kinit would be useful as
>>>>> well.
>>>>>
>>>>> For login failures, following the sssd troubleshooting guide to
>>>>> bump up
>>>>> the devel level.
>>>>
>>>> I wonder if this is similar to
>>>>
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>>>>
>>>>
>>>>
>>>>
>>>> but can't confirm without krb5kdc logs.
>>>
>>> Which debug level should I set?
>>
>> There is no separate debug level. You either see an error message
>> around SIDs being different or not.
>
> That's what I see:
> Jan 24 10:02:18 pipa08.linux.mydomain.at krb5kdc[4152](info): AS_REQ
> (7 etypes {aes256-cts-hmac-sha1-96(18),
> aes256-cts-hmac-sha384-192(20), camellia256-cts-cmac(26),
> aes128-cts-hmac-sha1-96(17), aes128-cts-hmac-sha256-128(19),
> camellia128-cts-cmac(25), DEPRECATED:arcfour-hmac(23)}) 10.66.39.142:
> NEEDED_PREAUTH: admin(a)LINUX.MYDOMAIN.AT for
> krbtgt/LINUX.MYDOMAIN.AT(a)LINUX.MYDOMAIN.AT, Additional
> pre-authentication required
This is just a normal request by KDC that a user (admin) must
use a pre-authentication method. This is normal for all Kerberos
principals today, to protect their communication with KDC. Typically,
either encrypted timestamp or SPAKE is used for that, but it is also a
Kerberos way of saying 'secure communication is needed, please use one'
and any of actual authentication methods use pre-authentication
mechanism framework in Kerberos to perform own steps. E.g. password auth
is done over encrypted timestamp or SPAKE (two different pre-auth
mechanisms), PKINIT is done with PKINIT, OTP is done with OTP mechanism
in a secure channel created with FAST, all within pre-authentication
mechanisms.
> Jan 24 10:02:23 pipa08.linux.mydomain.at krb5kdc[4151](info): preauth
> (spake) verify failure: Preauthentication failed
> Jan 24 10:02:23 pipa08.linux.mydomain.at krb5kdc[4151](info): AS_REQ
> (7 etypes {aes256-cts-hmac-sha1-96(18),
> aes256-cts-hmac-sha384-192(20), camellia256-cts-cmac(26),
> aes128-cts-hmac-sha1-96(17), aes128-cts-hmac-sha256-128(19),
> camellia128-cts-cmac(25), DEPRECATED:arcfour-hmac(23)}) 10.66.39.142:
> PREAUTH_FAILED: admin(a)LINUX.MYDOMAIN.AT for
> krbtgt/LINUX.MYDOMAIN.AT(a)LINUX.MYDOMAIN.AT, Preauthentication failed
This one responds that SPAKE pre-authentication failed for the admin
user, for whatever reason. SPAKE is preferred over encrypted timestamp
method because it is actually more secure. If SPAKE verification failed,
there might be few reasons that would differ by an error message after
'verify failure'.
'Preauthentication failed' comes from KRB5KDC_ERR_PREAUTH_FAILED error
internally. There are multiple reasons why this could happen:
- client sent a cookie different to what KDC sent as a challange
- client did not sent a cookie at all
- values used by the client to encrypt response factor field are
different to what KDC is using. This is the most closest to 'client
used wrong password'
- client used different elliptic curve group configuration than the
KDC. SPAKE preauthentication can use one of four elliptic curve
groups for its password-authenticated key exchange. The recommended
group is edwards25519; three NIST curves (P-256, P-384, and P-521)
are also supported.
The latter is configured as stated on
https://web.mit.edu/kerberos/krb5-devel/doc/admin/spake.html and this is
what IPA defaults to.
OK. I think we can rule out number 4. Number 3 means wrong
password. How
can I verify if number 1 or 2 in order to rule them out?
I do really doubt that number 3 was an OSI layer 8 problem but we'll
see. In order to verify that I will change the admin user's password to
a secret that only I am aware of and check back in a week.
Just two more questions:
Could a user be locked and I would not see that with ipa user-show
someuser --all?)
In case of a password change is the client IP address logged somewhere?
(I would have to modify the apache config if it happend over the WebGUI
because apache would only see the loadbalancer IP by default.)
Cheers,
Ronald