-
-
Notifications
You must be signed in to change notification settings - Fork 909
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
providers/ldap: set password_change_date in check_pwd_last_set to avoid loop ending user sessions #11913
base: main
Are you sure you want to change the base?
Conversation
✅ Deploy Preview for authentik-storybook ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for authentik-docs ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #11913 +/- ##
==========================================
- Coverage 92.57% 92.49% -0.09%
==========================================
Files 761 761
Lines 37813 37821 +8
==========================================
- Hits 35004 34981 -23
- Misses 2809 2840 +31
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
…ethod from the base class
Our version always updates the user.password_change_date either to now or a given value
…ange after the event is logged
Details
closes #11436
Explanation:
In (ms_)check_pwd_last_set the line
if created or pwd_last_set > user.password_change_date:
test if the pw in the ldap store is newer than the authentik one. If so
user.set_unusable_password() user.save()
Is executed. Changing the user password (correctly) ends all user sessions. See https://docs.djangoproject.com/en/5.1/topics/auth/default/#:~:text=Django%20also%20provides%20views%20and,log%20out%20all%20their%20sessions.
However, since user.password_change_date is not set the next ldap_sync will lockout the user again.
I think this wasn't a problem when during login the user pw was always saved to the authentik database. Since this changed a while ago this is now a bug.
The fix is to simply set the password_change_date to the ldap date. One might argue it should be the time the ldap sync run, but I think it is easier to understand for an administrator if the ldap date and the authentik date are the same.
Checklist
ak test authentik/
)make lint-fix
)If an API change has been made
make gen-build
)If changes to the frontend have been made
make web
)If applicable
make website
)