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!