RADIUS proxies will probably be mostly used for one time password systems which may or may not manage the "static" user-specific password prefix.
If a user only is authenticated using a RADIUS proxy, in most cases it doesnt make sense to prompt him to change his IPA password.
Also, the password change wont succeed, because it uses the user-entered one-time-password twice to check the "old password", which of course doesnt work. So if the user is prompted for a new password the old password should only be checked once, because its probably valid only once, or, even better: 2 consecutive passwords should be checked once.
I think we need to limit password expiration checks for radius case, indeed, when --user-auth is only 'radius', we have no means to check or change a password, especially for radius-based OTP codes.
I think if RADIUS server is capable to report password expiration for the user, we need to propagate it properly but changing password should be left for the RADIUS provider itself.
The problem with RADIUS protocol is that the password/PIN change AFAIR is done via Access-Challenge response from the server to the RADIUS client. That response would contain a message attribute - the prompt that needs to be shown to the user. User should read the prompt and reply to it with some input. RADIUS server and client usually do not know how to interpret it - only the real authentication server configured behind the RADIUS server knows what this reply is about based on the state of the session. I do not think there is an easy way to detect allow change of the password/PIN all the way through. For RADIUS case it should be single transaction operation - no multistage authentication possible.
AFAIR by OTP design if RADIUS is configured for a user his local Kerberos password is shadowed i.e. ignored and never used or checked in the authentication sequence. So the client should never get any password change prompt in the first place. If this is not the case it is a bug.
I don't believe we have any plan to handle password-changes over RADIUS.
However, the bug here seems to be something different: namely kdb is reporting that the (FreeIPA) password is expired when only RADIUS is configured. This is a real bug.
http://www.redhat.com/archives/freeipa-devel/2014-May/msg00014.html
master:
Metadata Update from @esgr: - Issue assigned to npmccallum - Issue set to the milestone: FreeIPA 4.0 - 2014/05
Login to comment on this ticket.