Password Policy - Expired Password - mschap

[Theparanoidone Theparanoidone]

>> If you want to change all REJECTs to ACCEPT so that 
>> authentication always succeeds, then you are effectively 
>> eliminating the requirement for 802.1x authentication for 
>> network connectivity.  If it's not required, why not just turn 
>> off port security on your switches?  
>> If it is required, why would you want to do the above?


This is not what I am asking to do... I would like to add some conditions to the 
Post-Auth-Reject to *selectively* change the the response to accept.   I am 
asking the freeradius user list if anyone can provide me with just a basic 
example to simply accept all... and then i'll add the appropriate modifications 
from there.  My attempts to modify anything in the Post-Auth-Reject have failed, 
and therefore I believe I'm doing something wrong and not interpreting the docs 
correctly.  I believe handling this in a config file would be better than 
recompiling code.   Are there any examples? 


>> It seems that what you really want is the ability to change 
>> the expired password via MSCHAP which isn't currently 
>> supported in FreeRADIUS (as I said in a previous post).  
>> If you are going to write a patch, develop one to provide this 
functionality..


We have successfully implemented a test patch.  This test patch moves away from 
implementing mschapv2 in the client connection and specifying PAP.  It changes 
the opendirectory response, and only requires two lines of code to change in 
rlm_opendirectory.c.  I include the updated block of code here:

        odResult = od_check_passwd(name, passwd);
        switch(odResult)
        {
                /*
                 * We moved eDSAuthNewPasswordRequired and 
eDSAuthPasswordExpired
                 * to the list of "okay" authentications.
                 *
                 * This allows a user to join the network, which should allow
                 * the user to complete a password update on the network through
                 * the standard client's password update cli/gui prompts.
                 *
                 * This may be a security risk to others. However, for our 
business
                 * needs, we believe a correct but expired password means the 
user did
                 * authenticate correctly, they simply just need to change their 
password
                 * at the soonest available time.  This requires them to have 
network access
                 * to do so which is why we changed this behavior.
                 *
                 * We believe this is better than having to micro-manage 
hundreds of employees
                 * password resets.
                 */
                case eDSNoErr:
                case eDSAuthNewPasswordRequired:
                case eDSAuthPasswordExpired:
                        ret = RLM_MODULE_OK;
                        break;

                case eDSAuthUnknownUser:
                case eDSAuthInvalidUserName:
                case eDSAuthAccountDisabled:
                case eDSAuthAccountExpired:
                case eDSAuthAccountInactive:
                case eDSAuthInvalidLogonHours:
                case eDSAuthInvalidComputer:
                        ret = RLM_MODULE_USERLOCK;
                        break;

                default:
                        ret = RLM_MODULE_REJECT;
                        break;
        }

The above code is tested, does work and will authenticate a user to the switch. 
 It piggybacks EAP-TTLS & PAP via opendirectory and is a proof of concept. 
 We're starting simple to see if we want to make changes to mschapv2.

Long term to make a patch like this useful... perhaps a freeradius configuration 
option called "allowExpiredPasswordsAndPasswordResets = yes" could be 
implemented.... (unless there is an easier way to do this in Post-Auth-Reject.. 
see my request above).  

Here's the catch:  We are now seeing a problem/bug on the Mac OSX client 
computer with this. The client authenticates, and is now successfully presented 
with a "new password" dialogue prompt upon login (great).  However, in-between 
the successful initial login screen, and the new password prompt screen, a 
tcpdump reveals the Mac OSX Client sends an "EAPOL Logoff" packet to the switch 
which then boots the client off the network again.  Frustrating as there is no 
reason to do this especially since the client successfully authenticated and did 
receive a full Access-Accept as expected.  Even if we have successfully patched 
the server... this may be a deal breaker due to Apple's client implementation. 
We are discussing this with Apple now.  When I get a chance, I will see if I can 
get a linux box to authenticate and prompt for a new password without sending a 
logoff packet for comparison.


I am still interested in:

1) An example Auth-Post-Reject example (basic code block and where to place it 
as my attempts have failed)

2) If anyone has any additional information about EAPOL Logoff packets being 
transmitted on client password reset prompts, I'd be interested in hearing about 
it.

3) A long term solution; I don't believe password expirations are that uncommon 
anymore with all the security requirements (HIPPA, PCI, etc etc) that depend 
upon this.

Thanks!