Without trying it, I think your user factor script could remove the cookie from disk and to force a re-auth; it could also do some jiggery-pokery in Kerberos to disable or remove the principal.
A better (cleaner) solution might be to rename your primary factor to, for example, UMICH-PREAUTH, and then have the user factor check that the password's not expired and that the PREAUTH factor is fulfilled before it issues your old primary factor. There are probably other ways to do this too; those are the two that quickly spring to mind. -- Jorj Sent from my iPhone > On Sep 10, 2015, at 10:04 PM, Liam Hoekenga <li...@umich.edu> wrote: > > Our CSO has mandated that we implement password expiry. > Cosign uses kerberos for it's credential store, but the password policies > will be stored in LDAP. > > If the user logs in, and their password is in a warning period, cosign will > report that the user's password is expiring soon, and give them the option to > either continue to their service, or change their password now. > > If the user logs in, and their password has "expire", cosign will tell the > user that their password has expired, and send them on the password > management application. > > We're using the userfactor stuff to handle this. The userfactor invokes a > script that checks the cosign service, and the user's password status via a > webservice. > > If the user is in the warning period or their password has expired, we > requires the "pw_expiry" factor. (If the cosign service they're trying to > access is the pw management application, we just let them through). > > The pw_expiry factor is satisfied by stuff in the pw expiry UI element. > > We'd like to prevent users whose passwords have expired from accessing any > services until they've changed their password, resetting those results > returned by the webservice. > > What we've got now works ok, but if someone has satisfied the pw_expiry > factor, the next time they access a cosign protected service, they're passed > right through. > > To get the desired behavior, it seems like we'd need to unset the pw_expiry > factor. > Any suggestions on how to implement this without unsetting the factor? Or > how we might implement unsetting the factor (maybe logging that factor out)? > > thanks! > Liam > ------------------------------------------------------------------------------ > _______________________________________________ > Cosign-discuss mailing list > Cosign-discuss@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/cosign-discuss ------------------------------------------------------------------------------ _______________________________________________ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
