7:25 a.m.
On December the 30th we have updated the following packages on our IPA
servers:
Package list:
0:ipa-client-4.9.6-10.0.1.module+el8.5.0+20451+6c55862e.x86_64
0:ipa-client-common-4.9.6-10.0.1.module+el8.5.0+20451+6c55862e.noarch
0:ipa-common-4.9.6-10.0.1.module+el8.5.0+20451+6c55862e.noarch
0:ipa-selinux-4.9.6-10.0.1.module+el8.5.0+20451+6c55862e.noarch
0:ipa-server-4.9.6-10.0.1.module+el8.5.0+20451+6c55862e.x86_64
0:ipa-server-common-4.9.6-10.0.1.module+el8.5.0+20451+6c55862e.noarch
0:ipa-server-trust-ad-4.9.6-10.0.1.module+el8.5.0+20451+6c55862e.x86_64
0:python3-ipaclient-4.9.6-10.0.1.module+el8.5.0+20451+6c55862e.noarch
0:python3-ipalib-4.9.6-10.0.1.module+el8.5.0+20451+6c55862e.noarch
0:python3-ipaserver-4.9.6-10.0.1.module+el8.5.0+20451+6c55862e.noarch
0:389-ds-base-1.4.3.23-12.module+el8.5.0+20461+fe0fe228.x86_64
0:389-ds-base-libs-1.4.3.23-12.module+el8.5.0+20461+fe0fe228.x86_64
0:python3-lib389-1.4.3.23-12.module+el8.5.0+20461+fe0fe228.noarch
0:systemd-239-51.0.1.el8_5.3.x86_64
0:systemd-libs-239-51.0.1.el8_5.3.x86_64
0:systemd-pam-239-51.0.1.el8_5.3.x86_64
0:systemd-udev-239-51.0.1.el8_5.3.x86_64
0:kernel-4.18.0-348.7.1.el8_5.x86_64
0:kernel-core-4.18.0-348.7.1.el8_5.x86_64
0:kernel-modules-4.18.0-348.7.1.el8_5.x86_64
0:kernel-tools-4.18.0-348.7.1.el8_5.x86_64
0:kernel-tools-libs-4.18.0-348.7.1.el8_5.x86_64
0:kexec-tools-2.0.20-57.0.3.el8_5.1.x86_64
0:libipa_hbac-2.5.2-2.0.1.el8_5.3.x86_64
0:libsss_autofs-2.5.2-2.0.1.el8_5.3.x86_64
0:libsss_certmap-2.5.2-2.0.1.el8_5.3.x86_64
0:libsss_idmap-2.5.2-2.0.1.el8_5.3.x86_64
0:libsss_nss_idmap-2.5.2-2.0.1.el8_5.3.x86_64
0:libsss_simpleifp-2.5.2-2.0.1.el8_5.3.x86_64
0:libsss_sudo-2.5.2-2.0.1.el8_5.3.x86_64
1:openssl-1.1.1k-5.el8_5.x86_64
1:openssl-libs-1.1.1k-5.el8_5.x86_64
1:openssl-perl-1.1.1k-5.el8_5.x86_64
0:oraclelinux-release-el8-1.0-21.el8.x86_64
0:python3-libipa_hbac-2.5.2-2.0.1.el8_5.3.x86_64
0:python3-libsss_nss_idmap-2.5.2-2.0.1.el8_5.3.x86_64
0:python3-perf-4.18.0-348.7.1.el8_5.x86_64
0:python3-sss-2.5.2-2.0.1.el8_5.3.x86_64
0:python3-sss-murmur-2.5.2-2.0.1.el8_5.3.x86_64
0:python3-sssdconfig-2.5.2-2.0.1.el8_5.3.noarch
0:selinux-policy-3.14.3-80.0.2.el8_5.2.noarch
0:selinux-policy-targeted-3.14.3-80.0.2.el8_5.2.noarch
0:sssd-client-2.5.2-2.0.1.el8_5.3.x86_64
0:sssd-common-2.5.2-2.0.1.el8_5.3.x86_64
0:sssd-common-pac-2.5.2-2.0.1.el8_5.3.x86_64
0:sssd-dbus-2.5.2-2.0.1.el8_5.3.x86_64
0:sssd-ipa-2.5.2-2.0.1.el8_5.3.x86_64
0:sssd-kcm-2.5.2-2.0.1.el8_5.3.x86_64
0:sssd-krb5-common-2.5.2-2.0.1.el8_5.3.x86_64
0:sssd-nfs-idmap-2.5.2-2.0.1.el8_5.3.x86_64
0:sssd-tools-2.5.2-2.0.1.el8_5.3.x86_64
0:sssd-winbind-idmap-2.5.2-2.0.1.el8_5.3.x86_64
0:systemd-239-51.0.1.el8_5.2.x86_64
0:systemd-libs-239-51.0.1.el8_5.2.x86_64
0:systemd-pam-239-51.0.1.el8_5.2.x86_64
0:systemd-udev-239-51.0.1.el8_5.2.x86_64
0:kernel-uek-5.4.17-2136.302.6.1.el8uek.x86_64
After having updated these packages some of our ipa users (including
admin) were not able to log in anymore. Fortunately, some users still
worked allowing us to reset the passwords of the respective users.
Can this be update related or is it just a coincidence? We had to reset
the passwords and no time to hunt the problem down. But what can
possibly have caused this?
Cheers,
Ronald
8:50 a.m.
Ronald Wimmer via FreeIPA-users wrote:
On December the 30th we have updated the following packages on our
IPA
servers:
Package list:
[snip]
After having updated these packages some of our ipa users (including
admin) were not able to log in anymore. Fortunately, some users still
worked allowing us to reset the passwords of the respective users.
Can this be update related or is it just a coincidence? We had to reset
the passwords and no time to hunt the problem down. But what can
possibly have caused this?
I don't think without any sort of logging or details. What type of login
failed?
rob
9:32 a.m.
New subject: Some ipa user passwords did not work after update
On 05.01.22 15:50, Rob Crittenden via FreeIPA-users wrote:
Ronald Wimmer via FreeIPA-users wrote:
> On December the 30th we have updated the following packages on our IPA
> servers:
>
> Package list:
[snip]
> After having updated these packages some of our ipa users (including
> admin) were not able to log in anymore. Fortunately, some users still
> worked allowing us to reset the passwords of the respective users.
>
> Can this be update related or is it just a coincidence? We had to reset
> the passwords and no time to hunt the problem down. But what can
> possibly have caused this?
I don't think without any sort of logging or details. What type of login
failed?
Password-based login (IPA WebGUI, ssh, kinit) did not work. What we saw
in the logs was the same as if somebody entered the wrong password.
When we tried to give these users news passwords for some admin users
(belonging to exacly the same groups as some other admin users) "reset
password" was greyed out in the IPA WebGUI. Using "ipa user-mod someuser
--password" worked on the command line.
I'll have a look if there is a user left that still has this particular
problem. Then we can have a closer look.
Cheers,
Ronald
2:29 a.m.
New subject: Some ipa user passwords did not work after update
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
On 05.01.22 15:50, Rob Crittenden via FreeIPA-users wrote:
> Ronald Wimmer via FreeIPA-users wrote:
>> On December the 30th we have updated the following packages on our IPA
>> servers:
>>
>> Package list:
> [snip]
>> After having updated these packages some of our ipa users (including
>> admin) were not able to log in anymore. Fortunately, some users still
>> worked allowing us to reset the passwords of the respective users.
>>
>> Can this be update related or is it just a coincidence? We had to reset
>> the passwords and no time to hunt the problem down. But what can
>> possibly have caused this?
>
> I don't think without any sort of logging or details. What type of login
> failed?
>
> rob
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
>
3:55 a.m.
New subject: Some ipa user passwords did not work after update
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.
Cheers,
Ronald
10:48 a.m.
New subject: Some ipa user passwords did not work after update
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.
rob
10:53 a.m.
New subject: Some ipa user passwords did not work after update
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.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
2:47 a.m.
New subject: Some ipa user passwords did not work after update
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?
2:55 a.m.
New subject: Some ipa user passwords did not work after update
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.fedorahosted.org/thread/4S4QQDC4FBVTA4GYWWVBPKGYN3MF4UJ6/
>
>
>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.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
3:02 a.m.
New subject: Some ipa user passwords did not work after update
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
Jan 24 10:02:18 pipa08.linux.mydomain.at krb5kdc[4152](info): closing
down fd 12
Jan 24 10:02:23 pipa08.linux.mydomain.at krb5kdc[4151](info): AS_REQ (7
etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
aes256-cts-hmac-sha384-192(20), camellia256-cts-cmac(26),
aes128-cts-hmac-sha256-128(19), camellia128-cts-cmac(25),
DEPRECATED:arcfour-hmac(23)}) 10.66.16.39: NEEDED_PREAUTH:
host/as40202.linux.mydomain.at(a)LINUX.MYDOMAIN.AT for
krbtgt/LINUX.MYDOMAIN.AT(a)LINUX.MYDOMAIN.AT, Additional
pre-authentication required
Jan 24 10:02:23 pipa08.linux.mydomain.at krb5kdc[4151](info): closing
down fd 12
Jan 24 10:02:23 pipa08.linux.mydomain.at krb5kdc[4150](info): AS_REQ (7
etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
aes256-cts-hmac-sha384-192(20), camellia256-cts-cmac(26),
aes128-cts-hmac-sha256-128(19), camellia128-cts-cmac(25),
DEPRECATED:arcfour-hmac(23)}) 10.66.16.39: ISSUE: authtime 1643014943,
etypes {rep=aes256-cts-hmac-sha1-96(18),
tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)},
host/as40202.linux.mydomain.at(a)LINUX.MYDOMAIN.AT for
krbtgt/LINUX.MYDOMAIN.AT(a)LINUX.MYDOMAIN.AT
Jan 24 10:02:23 pipa08.linux.mydomain.at krb5kdc[4150](info): closing
down fd 12
Jan 24 10:02:23 pipa08.linux.mydomain.at krb5kdc[4152](info): TGS_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.16.39: ISSUE: authtime 1643014943,
etypes {rep=aes256-cts-hmac-sha1-96(18),
tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)},
host/as40202.linux.mydomain.at(a)LINUX.MYDOMAIN.AT for
ldap/pipa08.linux.mydomain.at(a)LINUX.MYDOMAIN.AT
Jan 24 10:02:23 pipa08.linux.mydomain.at krb5kdc[4152](info): closing
down fd 12
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
Jan 24 10:02:23 pipa08.linux.mydomain.at krb5kdc[4151](info): closing
down fd 12
Jan 24 10:02:23 pipa08.linux.mydomain.at krb5kdc[4151](info): AS_REQ (8
etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19),
UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23),
camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) 10.66.43.162:
NEEDED_PREAUTH: host/as13399.org.mydomain.at(a)LINUX.MYDOMAIN.AT for
krbtgt/LINUX.MYDOMAIN.AT(a)LINUX.MYDOMAIN.AT, Additional
pre-authentication required
Jan 24 10:02:23 pipa08.linux.mydomain.at krb5kdc[4151](info): closing
down fd 12
Jan 24 10:02:23 pipa08.linux.mydomain.at krb5kdc[4148](info): AS_REQ (8
etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19),
UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23),
camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) 10.66.43.162:
ISSUE: authtime 1643014943, etypes {rep=aes256-cts-hmac-sha1-96(18),
tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)},
host/as13399.org.mydomain.at(a)LINUX.MYDOMAIN.AT for
krbtgt/LINUX.MYDOMAIN.AT(a)LINUX.MYDOMAIN.AT
Jan 24 10:02:23 pipa08.linux.mydomain.at krb5kdc[4148](info): closing
down fd 12
Jan 24 10:02:23 pipa08.linux.mydomain.at krb5kdc[4150](info): TGS_REQ (8
etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19),
UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23),
camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) 10.66.43.162:
ISSUE: authtime 1643014943, etypes {rep=aes256-cts-hmac-sha1-96(18),
tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)},
host/as13399.org.mydomain.at(a)LINUX.MYDOMAIN.AT for
ldap/pipa08.linux.mydomain.at(a)LINUX.MYDOMAIN.AT
Jan 24 10:02:23 pipa08.linux.mydomain.at krb5kdc[4150](info): closing
down fd 12
3:38 a.m.
New subject: Some ipa user passwords did not work after update
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.fedorahosted.org/thread/4S4QQDC4FBVTA4GYWWVBPKGYN3MF4UJ6/
>>>
>>>
>>>
>>>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.
All these error cases generate the same PREAUTH_FAILED error.
Another possibility is that you may have set something on admin account
that prevents using SPAKE for it, like forcing hardened auth type. There
is currently a bug for it: https://pagure.io/freeipa/issue/9065 but it
would generate a different error message.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
4:07 a.m.
New subject: Some ipa user passwords did not work after update
On 24.01.22 10:38, Alexander Bokovoy wrote:
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
3:12 a.m.
New subject: Some ipa user passwords did not work after update
On 24.01.22 09:55, Alexander Bokovoy via FreeIPA-users 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.
A quick search on the web let me find this thread:
https://bugzilla.redhat.com/show_bug.cgi?id=1651278
Time is not an issue in my case. Password expiry is way below 2038.
Cheers,
Ronald
2:45 a.m.
New subject: Some ipa user passwords did not work after update
On 17.01.22 17:48, Rob Crittenden 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.
We compared the user's LDAP attributes and not a single one changed. The
password hash stayed exactly what it was and the modification timestamps
did not alter.
Running kinit with KRB5_TRACE showed:
[3947831] 1643013400.799117: Response was from master KDC
[3947831] 1643013400.799118: Received error from KDC:
-1765328360/Preauthentication failed
kinit: Password incorrect while getting initial credentials
In which SSSD section does it make sense to increase the debug_level?
Cheers,
Ronald
821
days inactive
840
days old
freeipa-users@lists.fedorahosted.org
13 comments
3 participants
participants (3)
-
Alexander Bokovoy -
Rob Crittenden -
Ronald Wimmer