We have code to hook pre_bind in the paswword plugin but we use it only for password migrations.
We should add code to check if the password is expired in order to fail the bind. The code requires only a minimal change to do that.
Before merging the patch, following scenarios need to be investigated so that they are not broken with this change. See Nathaniel's suggestion:
My preference is to revert it and have a small project for the next release which handles all the "non-authenticated" corner cases. This would include: * Expired passwords * Password changes * Token syncing * Unauthenticated RPCs (rpcserver.py rework) * others?
Steps to reproduce:
The expectation is that bind should also fail as the password is set to expired.
Note that we do "administratively" expire passwords when a admin resets a password. And ldappasswd relies on being able to perform a bind to be able to change the password.
So we will need to make sure we can distinguish between administratively expired passwords (and allow bind in that case) and "really" expired passwords, and prevent login in that case.
NOTE: this means the user will have to ask for a password reset in order to change the password, so we may want to make this behaviour optional too.
We should reconsider addressing this bug in 3.0
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=782917
Moving to next month iteration.
Several people on the list asked about this at the same time. Moving to NEEDS_TRIAGE.
The ticket is returned into triage based on the following mail threads:
https://www.redhat.com/archives/freeipa-users/2012-September/msg00161.html
https://www.redhat.com/archives/freeipa-users/2012-September/msg00162.html
It seems that what we need to do is to respect the grace period setting. By default it would allow changing password at any moment using the expired one but if someone wants to explicitly limit it to a predefined period he would change grace period setting to a non 0 value and we should prevent changing password after that date.
Changing 3.2 priority
Basica patch to show what work needs to be done 0001-WIP-Check-for-account-pw-expiration-in-pre-bind.patch
I have attached a patch that shows what kind of change is needed here. The patch compiles but is not tested and misses handling of a special control a client may ask for.
3.4 development was shifted by one month, moving tickets to reflect reality better.
Adjusting time plan - 3.4 development was postponed as we focused on 3.3.x testing and stabilization.
Moving unfinished November tickets to January.
New patch that applies to master 0001-Check-for-password-expiration-in-pre-bind.patch
Starting review
Hi,
Quick question... now that bind will fail (as expected) if the password is expired. How can password be modified?
For some reason IPA requires non anonymous bind for password modify extended request, although this extended request gets the current and new password, which is design for this exact case and should work also being anonymously bind.
Thanks, Alon
Replying to [comment:29 alonbl]:
Hi, Quick question... now that bind will fail (as expected) if the password is expired. How can password be modified? For some reason IPA requires non anonymous bind for password modify extended request, although this extended request gets the current and new password, which is design for this exact case and should work also being anonymously bind.
The mailing list is probably a better place for these kind of questions, please redirect there any further discussion.
Password changes are still possible via kpasswd protocol (which is the preferred method).
Replying to [comment:31 simo]:
Replying to [comment:29 alonbl]: Hi, Quick question... now that bind will fail (as expected) if the password is expired. How can password be modified? For some reason IPA requires non anonymous bind for password modify extended request, although this extended request gets the current and new password, which is design for this exact case and should work also being anonymously bind. The mailing list is probably a better place for these kind of questions, please redirect there any further discussion.
I think this is an important aspect of this change, I am just pointing this out here as it may block this change as-is.
As being LDAP server please do not block the LDAP way of doing it, it had been ages until we got good LDAP support for password expiration notice and modification.
Mixing kerberos and LDAP is good to some extent, but not as something that should be enforced.
Thanks!
master:
Replying to [comment:32 alonbl]:
Replying to [comment:31 simo]: Replying to [comment:29 alonbl]: Hi, Quick question... now that bind will fail (as expected) if the password is expired. How can password be modified? For some reason IPA requires non anonymous bind for password modify extended request, although this extended request gets the current and new password, which is design for this exact case and should work also being anonymously bind. The mailing list is probably a better place for these kind of questions, please redirect there any further discussion. I think this is an important aspect of this change, I am just pointing this out here as it may block this change as-is. Password changes are still possible via kpasswd protocol (which is the preferred method). As being LDAP server please do not block the LDAP way of doing it, it had been ages until we got good LDAP support for password expiration notice and modification. Mixing kerberos and LDAP is good to some extent, but not as something that should be enforced. Thanks!
Note that I started an inquiry (thread) about the question you asked on freeipa-devel:
http://www.redhat.com/archives/freeipa-devel/2014-June/msg00148.html
As decided in the referred thread, patch reverted - there are too severe issues given we are close to GA.
We want to get back to this patch when closely planning 4.1.
I think a solution could be to define a grace period for expired passwords, in the grace time the only allowed operation would be to modify the password. The prebind plugin would detect that the bind is within the grace period and set a flag in a connection extension that it is a grace login, preop plugins for the other ops would check if it is a grace login and allow only the modification of the password.
Password modify should be enabled when using anonymous bind by providing existing password, so adding grace period is nice but not entirely related...
The FreeIPA 4.2 was already shaped (see [[milestone:FreeIPA 4.2]] milestone), this does not fit. Pushing out.
If anyone is willing to help and contribute to this one, please let us know!
Now that DS suppports it what we can do is to allow the bind but change the bind DN to be an anoynous DN and save in some connection slot data that tells who the original user was, later on if a ldappasswd operation is called we check if the oiginal bind was by a user with an expired password and allow it to operate as that user.
The only problem here is that a user would still lok like it authenticated successfully, so people that use binds to check passwords would not get a refusal, so this is not a full solution for that case.
What we shoud do is to not bind before running ldappasswd in case the password is expired, need to check what clients we need to change to conform to this. If we change our clients to do this (requires password auth in the ldappasswd call) then we can refuse binds when passwors are expired and still allow password changes.
This RFE is not planned to be implemented in 4.5.
Metadata Update from @simo: - Issue assigned to simo - Issue set to the milestone: Future Releases
Another possible way to solve this problem with less code change is to create an ldap password policy with only expiration to "on" and with a password max age similar mapped to ipa kerberos password policy, for each ipa kerberos password policy.
The only thing that has to be manipulated manually would be the passwordexpirationtime to have exactly the same value than kerberos expiration time.
Then, any ldap bind will return a password expired and we could also use the password grace time feature if needed. All of that is already coded and working in ldap password policy.
I think the complexity will be to define and mantain the exact ldap password policy for each kerberos password policy because we manage the concept of subtree password policy but not sure we manage a password policy associated to members of a group as in kerberos ipa pwd policy.
PR https://github.com/freeipa/freeipa/pulls
Metadata Update from @rcritten: - Issue close_status updated to: None
ipa-4-9:
Metadata Update from @abbra: - Issue assigned to rcritten (was: simo)
The remaining part is to document the changes merged.
Metadata Update from @frenaud: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
Metadata Update from @rcritten: - Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=782917 https://bugzilla.redhat.com/show_bug.cgi?id=2091988 (was: https://bugzilla.redhat.com/show_bug.cgi?id=782917)
ipa-4-10:
Login to comment on this ticket.