> 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.

*** Bug 1535651 has been marked as a duplicate of this bug. ***

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)

(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: ~$

(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.

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;•
        }•

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)

[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]$

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)

(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.

(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?

also can you post the output of:

╎❯ sudo getent shadow $(whoami)

(make sure your password is throwaway before doing comment 17)

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

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.

(i mean g-s-d not control-center in comment 20 obviously)

Oliver does it work for you now?

*** Bug 1543537 has been marked as a duplicate of this bug. ***

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.

(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.

7.5 Snapshot 3 does not have the notification anymore

Thanks Oliver, moving to verified.

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