Description of problem: These are all Fedora 33 machines set up as IPA clients in a local realm. When I log into the F33 machines I see a message like: Warning: your password will expire in 32767 days. The expiry time isn't always consistent. Simultaneously, on another machine I see Warning: your password will expire in 32765 days. All machines have their clocks synchronised. The password actually expires in 21 days. The inconsistency of the reported number, and the fact that the value is always a few short of 2^15, makes me wonder if this message is coming from a faulty printf() formatter somewhere. I don't see this on the Fedora 32 machines. Reporting against sssd to kick off investigation; not sure exactly which component is at fault. Version-Release number of selected component (if applicable): sssd-2.3.1-4.fc33.x86_64 pam-1.4.0-4.fc33.x86_64 freeipa-client-4.8.10-5.fc33.x86_64
Hi, thanks for the report, can you add 'debug_level = 9' to the [domain/...] section of sssd.conf, restart SSSD, log in again and look for 'exp_time:' in krb5_child.log. This should be the original timestamp in seconds returned by the KDC minus the current time in seconds since UNIX epoch. bye, Sumit
The only exp_time line I have is: (2020-10-12 11:57:56): [krb5_child[142069]] [sss_krb5_expire_callback_func] (0x2000): exp_time: [1766686] One thing I've just noticed is if I su to myself (rather than ssh to localhost), I get 'Warning: your password will expire in 0 days.' -- also not really in the spirit of correctness, since I've since disabled password expiry in my FreeIPA account (stored as a numerically zero-time expiry).
Hi, thanks, so the original expiration time seems to be correct. What makes me wonder is that the message "Warning: your password will expire in ..." does not match what SSSD's pam_sss would generate, this would look like 'Your password will expire in ...'. A message starting with 'Warning: ...' might be generated by pam_unix. Do you, by chance, have users with the same name in /etc/passwd and matching data in /etc/shadow? bye, Sumit
The user name concerned isn't present in /etc/passwd or /etc/shadow, it's purely IPA-based. I also tried clearing out the sssd cache, but the problem remains. The affected machines were set up as IPA clients by the usual means, by running ipa-client-install --mkhomedir --no-ntp. So this could be a PAM misconfiguration... do you want me to attach /etc/nsswitch.conf or something from /etc/pam.d ?
(In reply to James from comment #4) > The user name concerned isn't present in /etc/passwd or /etc/shadow, it's > purely IPA-based. > > I also tried clearing out the sssd cache, but the problem remains. > > The affected machines were set up as IPA clients by the usual means, by > running ipa-client-install --mkhomedir --no-ntp. So this could be a PAM > misconfiguration... do you want me to attach /etc/nsswitch.conf or something > from /etc/pam.d ? Hi, please check the journal (or /var/log/secure if you use this style of logging) for messages from the time of the authentication. On a tet system I can see messages like: Oct 14 12:26:21 f33.rhel75.devel sshd[9844]: pam_unix(sshd:account): password for user testsc1 will expire in 32767 days or Oct 14 12:20:11 f33.rhel75.devel su[9798]: pam_unix(su:account): password for user testsc1 will expire in 0 days which are in agreement to your observations but as can be seen really are coming from pam_unix. I'll change the component to 'pam', Iker, can you have a look, it looks like you really need F33 with pam-1.4.0 to reproduce this. bye, Sumit
The problem was already fixed by Tomas Mraz upstream and it only applies to pam-1.4.0 release. I'll port it downstream in the following days. By the way, it wasn't a format printing error but an uninitialized variable.
* master: db6b293046aee4735f3aa2d1713742ed4b533219 - Fix missing initialization of daysleft
(In reply to Iker Pedrosa from comment #6) > The problem was already fixed by Tomas Mraz upstream and it only applies to > pam-1.4.0 release. I'll port it downstream in the following days. By the > way, it wasn't a format printing error but an uninitialized variable. Thanks! Stack garbage would've been by second guess ;)
Hi, When will it be in the update repository? We are waiting for it. Thank you
(In reply to 2013temp2013temp from comment #9) > Hi, > > When will it be in the update repository? We are waiting for it. > > Thank you The fix is in pam-1.4.0-6.fc34 which is in Koji. An fc33 build should be there soon, but you can build from the same SRPM.
Hi, I know NIS/YP is old stuff but we had many releases in a row, including fedora 33 which prevents users from logging till patches are released or switching between nscd and sssd etc... I would really appreciate one test on NIS logging before releasing a new fedora. Please
FEDORA-2020-cdf799e9ec has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-cdf799e9ec
FEDORA-2020-cdf799e9ec has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-cdf799e9ec` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-cdf799e9ec See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
ok took it from testing repository works fine thanks
FEDORA-2020-cdf799e9ec has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-543e7c2021 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-543e7c2021
FEDORA-2020-543e7c2021 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-543e7c2021` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-543e7c2021 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-543e7c2021 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.