[chromad] password change done remotely takes too long to notify chromebook and user to update |
|||||||
Issue descriptionChrome OS Version: 69 A user or an admin changing a password for a user in AD should force the user very quickly to update there Chromebook password. If this does not happen, then a user could be using an old password to login, logout, lock/unlock Chromebook, while a different password is used for web apps leading to a poor experience and a security concern if a user should not be logging in an all if the admin wanted to lock the user out from that Chrome device. What steps will reproduce the problem? (1) Change password and force user to change password (2) Wait on Chromebook for 12 minutes or longer What is the expected result? User gets notification that password is expired and needs to be updated What happens instead? Nothing See feedback log: "Chromad aluong password" #85689268043
,
Sep 28
I'm trying to understand the specific issue. What is the current behavior in Windows machines? If you request a password change, does it immediately alert a user or does it happen when the user next reboots/logs out? In my own experience, I've only see the latter. Does AD send out an immediate signal or does it happen when a user tries to login, checks AD and the device is then told the password has been changed? Or are you saying the problem is that if you logout of a Chromebook and try to login, it doesn't know the password has changed for more than 12 minutes? e.g. different behavior than Windows
,
Sep 30
,
Oct 7
,
Oct 8
Confirmed expected behavior is the following: If user tries to sign in, a password change should be registered immediately if connected to AD server If password changes on AD server while user is signed in, Chrome will check for a password change every 60 mins and notify the user that their password needs to be changed Please clarify if there is a bug in your testing or if we need to flag this as an FR to change the 60 min check period
,
Oct 17
,
Dec 11
,
Jan 11
This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this.
,
Yesterday
(44 hours ago)
Alex, anything needs to be done? |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by alu...@chromium.org
, Sep 27