Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1530659

Summary: message of expired password in RHEL 7.5 Beta
Product: Red Hat Enterprise Linux 7 Reporter: Oliver Ilian <oliver>
Component: gnome-settings-daemonAssignee: Ray Strode [halfline] <rstrode>
Status: CLOSED ERRATA QA Contact: Desktop QE <desktop-qa-list>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.5CC: bugreports2005, jeff.burrell, jkoten, mcepl, oliver, ovasik, rstrode, tpelka
Target Milestone: rcKeywords: Regression
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: gnome-settings-daemon-3.26.2-7.el7 accountsservice-0.6.45-6.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-04-10 13:10:18 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1527213    
Attachments:
Description Flags
password expired notification none

Description Oliver Ilian 2018-01-03 15:20:24 UTC
Created attachment 1376469 [details]
password expired notification

Description of problem:
After a fresh installation of RHEL CSB (Red Hat internal config for employees), a notification pops up saying that a password has expired. Clicking on the notification does not have an effect, and it doe snot say at all which password has expired (log in to gnome is via sssd and kerberos password, so it can not be this). This happens only with users that use sssd. If I log in as root I do not get the error.

This did not happen on RHEL 7.4 or before

Version-Release number of selected component (if applicable):
gnome-shell-3.26.2-2.el7.x86_64

How reproducible:
Fresh installed RHEL CSB

Steps to Reproduce:
1. Log in as user with a fresh install (user needs to set up to auth via sssd)


Actual results:
Notification that only shows that the password has expired (no further info)

Expected results:
No notification, or a notification with more context.

Comment 2 Matěj Cepl 2018-01-04 17:03:14 UTC
> This happens only with users that use sssd.

I don't think this is true. I have no sssd running and sssd.service is disabled, and yet I have the same meaningless message showing up.

Using RHEL-7.5 Nightly.

Comment 3 Tomas Pelka 2018-01-17 21:16:36 UTC
*** Bug 1535651 has been marked as a duplicate of this bug. ***

Comment 5 Ray Strode [halfline] 2018-01-29 18:41:51 UTC
probably a problem in the feature added in bug 1314443.

can you guys post the results of

$ gdbus call --system --dest org.freedesktop.Accounts --object-path /org/freedesktop/Accounts/User$(id -u) --method org.freedesktop.Accounts.User.GetPasswordExpirationPolicy

(run as the user seeing the problem)

Comment 6 Matěj Cepl 2018-01-30 14:40:07 UTC
(In reply to Ray Strode [halfline] from comment #5)
matej@mitmanek: ~$ gdbus call --system --dest org.freedesktop.Accounts --object-path /org/freedesktop/Accounts/User$(id -u) --method org.freedesktop.Accounts.User.GetPasswordExpirationPolicy
(int64 -1, int64 -1, int64 0, int64 99999, int64 7, int64 -1)
matej@mitmanek: ~$

Comment 7 Matěj Cepl 2018-01-30 14:44:50 UTC
(In reply to Ray Strode [halfline] from comment #5)
> probably a problem in the feature added in bug 1314443.

If it is so, then I would say it is a horrible UI bug. This message essentially tells me “There is something seriously wrong with the security of your system, but I won’t tell you what, and so you won’t know what to do about it.” That looks to me like an attempt to torture users.

Comment 8 Ray Strode [halfline] 2018-01-30 15:17:59 UTC
Problem seems to be this code:

        if (manager->priv->last_change_time <= 0) {•
                password_already_expired = TRUE;•
                goto out;•
        }•

it should instead say:

        if (manager->priv->last_change_time == 0) {•
                password_already_expired = TRUE;•
                goto out;•
        }•

Comment 12 Ray Strode [halfline] 2018-02-07 14:10:34 UTC
Oliver, can you post the results of:

$ gdbus call --system --dest org.freedesktop.Accounts --object-path /org/freedesktop/Accounts/User$(id -u) --method org.freedesktop.Accounts.User.GetPasswordExpirationPolicy

(run as the user seeing the problem)

Comment 13 Oliver Ilian 2018-02-07 14:25:05 UTC
[ohaessle@ohaessle Desktop]$ gdbus call --system --dest org.freedesktop.Accounts --object-path /org/freedesktop/Accounts/User$(id -u) --method org.freedesktop.Accounts.User.GetPasswordExpirationPolicy
(int64 0, int64 0, int64 0, int64 0, int64 0, int64 0)
[ohaessle@ohaessle Desktop]$

Comment 14 Tomas Pelka 2018-02-07 14:58:50 UTC
I know I was not asked :) but getting different output

$ gdbus call --system --dest org.freedesktop.Accounts --object-path /org/freedesktop/Accounts/User$(id -u) --method org.freedesktop.Accounts.User.GetPasswordExpirationPolicy
(int64 -1, int64 -1, int64 0, int64 99999, int64 7, int64 -1)

Comment 15 Tomas Pelka 2018-02-07 14:59:23 UTC
(In reply to Tomas Pelka from comment #14)
> I know I was not asked :) but getting different output
> 
> $ gdbus call --system --dest org.freedesktop.Accounts --object-path
> /org/freedesktop/Accounts/User$(id -u) --method
> org.freedesktop.Accounts.User.GetPasswordExpirationPolicy
> (int64 -1, int64 -1, int64 0, int64 99999, int64 7, int64 -1)

Oh and I'm not seeing the issue.

Comment 16 Ray Strode [halfline] 2018-02-07 15:35:30 UTC
(In reply to Oliver Haessler from comment #13)
> [ohaessle@ohaessle Desktop]$ gdbus call --system --dest
> org.freedesktop.Accounts --object-path /org/freedesktop/Accounts/User$(id
> -u) --method org.freedesktop.Accounts.User.GetPasswordExpirationPolicy
> (int64 0, int64 0, int64 0, int64 0, int64 0, int64 0)
> [ohaessle@ohaessle Desktop]$

Hmm, unless I'm misunderstanding something you're shadow file says:

This user last changed their password today.  We allow them to change it again right away if they want.  We also require them to change it today.  We don't warn  ahead of time that they need to change it.  The account will go inactive today.  The password expired Jan 1, 1970.

It seems like the banner is "right" unless i'm misunderstanding something.

I'm confused why you aren't getting forced to change your password at log in time, though, so maybe I am misunderstanding something.

Can you post your /etc/pam.d files?

Comment 17 Ray Strode [halfline] 2018-02-07 15:38:01 UTC
also can you post the output of:

╎❯ sudo getent shadow $(whoami)

Comment 18 Ray Strode [halfline] 2018-02-07 15:41:25 UTC
(make sure your password is throwaway before doing comment 17)

Comment 19 Oliver Ilian 2018-02-07 15:43:27 UTC
well, the username ohaessle is not on the shadows file, as this is a user set up with sssd. Maybe thats the issue here?

The user us created during set up of the machine, and uses kerberos auth to authenticate

Comment 20 Ray Strode [halfline] 2018-02-07 16:10:02 UTC
so the problem, I guess, is we're not returning a NOT_SUPPORTED error to control-center in the case that the shadow file is unavailable.

Comment 21 Ray Strode [halfline] 2018-02-07 16:11:59 UTC
(i mean g-s-d not control-center in comment 20 obviously)

Comment 22 Tomas Pelka 2018-02-08 10:10:33 UTC
Oliver does it work for you now?

Comment 23 Ray Strode [halfline] 2018-02-08 16:47:11 UTC
*** Bug 1543537 has been marked as a duplicate of this bug. ***

Comment 24 bugreports2005 2018-02-12 11:31:06 UTC
In our environment the user database is configured through sssd to use a mix of AD and LDAP. Clients can't see the shadow information.

getent shadow returns without output.
gdbus command from above returns this:
(int64 0, int64 0, int64 0, int64 0, int64 0, int64 0)

As of gnome-settings-daemon-3.26.2-3.el7.x86_64, everyone is getting a notice after login that their password has expired. Which is not nice.

I'm not entirely sure how to obtain the gnome-settings-daemon 3.26.2-7 mentioned above, access.redhat.com seems to only carry 3.26.2-5. Did not try that.

Comment 25 Tomas Pelka 2018-02-12 12:31:25 UTC
(In reply to bugreports2005 from comment #24)
> In our environment the user database is configured through sssd to use a mix
> of AD and LDAP. Clients can't see the shadow information.
> 
> getent shadow returns without output.
> gdbus command from above returns this:
> (int64 0, int64 0, int64 0, int64 0, int64 0, int64 0)
> 
> As of gnome-settings-daemon-3.26.2-3.el7.x86_64, everyone is getting a
> notice after login that their password has expired. Which is not nice.
> 
> I'm not entirely sure how to obtain the gnome-settings-daemon 3.26.2-7
> mentioned above, access.redhat.com seems to only carry 3.26.2-5. Did not try
> that.

As RHEL7.5 was not released yet so you can get mentioned package only in case you as a customer is part of HTB (High Touch Beta) program or you usually get snapshots too.

Fixed package should be part of Snapshot-3 I guess.

If you want still want to get these fixed packages please contact your TAM or person from CEE (former GSS or support team) you usually communicate with. They should be able to help you. Or you need to wait for RHEL7.5 release date.

Comment 26 Oliver Ilian 2018-02-15 11:47:22 UTC
7.5 Snapshot 3 does not have the notification anymore

Comment 27 Tomas Pelka 2018-02-15 11:48:58 UTC
Thanks Oliver, moving to verified.

Comment 30 errata-xmlrpc 2018-04-10 13:10:18 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0770