Password Policy - Expired Password - mschap
Greetings~ We are using FreeRadius 2.1.3 (on snow leopard server). All users are authenticating with vlan assignments correctly; however, if you enable the ldap/(opendirectory) option to "require user to change password on next login" the client is unable to connect. The client login screen will not proceed to prompt the user for a new password; it's simply rejected. If you remove the password policy forcing a password reset, then the user can authenticate. In other words, it appears radius (mschap / ntlm_auth) is specifically rejecting the user if the user has a password reset flag set. Here is a snippet from the radius server debug log: Failed auth: ======= Found Auth-Type = MSCHAP +- entering group MS-CHAP {...} [mschap] No Cleartext-Password configured. Cannot create LM-Password. [mschap] No Cleartext-Password configured. Cannot create NT-Password. [mschap] No NT-Password configured. Trying OpenDirectory Authentication. [mschap] OD username_string = adouglas, OD shortUserName=adouglas (length = 8) rlm_mschap: authentication failed -14161 ++[mschap] returns reject Failed to authenticate the user. } # server inner-tunnel [ttls] Got tunneled reply code 3 Tunnel-Type:0 = VLAN Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Private-Group-Id:0 = "142" [ttls] Got tunneled Access-Reject [eap] Handler failed in EAP/ttls [eap] Failed in EAP select ++[eap] returns invalid Failed to authenticate the user. Using Post-Auth-Type Reject +- entering group REJECT {...} [attr_filter.access_reject] expand: %{User-Name} -> adouglas attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] returns updated Delaying reject of request 15 for 1 seconds Going to the next request Waking up in 0.9 seconds. Sending delayed reject for request 15 Sending Access-Reject of id 245 to 10.0.200.3 port 53907 EAP-Message = 0x04030004 Message-Authenticator = 0x00000000000000000000000000000000 ======= Success auth: ======= Found Auth-Type = MSCHAP +- entering group MS-CHAP {...} [mschap] No Cleartext-Password configured. Cannot create LM-Password. [mschap] No Cleartext-Password configured. Cannot create NT-Password. [mschap] No NT-Password configured. Trying OpenDirectory Authentication. [mschap] OD username_string = adouglas, OD shortUserName=adouglas (length = 8) [mschap] dsDoDirNodeAuth returns stepbuff: S=67322D06B7A0A7BB9EBC681EAAEE6FB197CDDCB2 (len=40) ++[mschap] returns ok } # server inner-tunnel [ttls] Got tunneled reply code 2 Tunnel-Type:0 = VLAN Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Private-Group-Id:0 = "142" MS-CHAP2-Success = 0xa9533d36373332324430364237413041374242394542433638314541414545364642313937434444434232 [ttls] Got tunneled Access-Accept ======= One last thing to note, if we specifically allow all users to authenticate (as described in the FAQ with DEFAULT AuthType := Accept), the client login screen will proceed to prompt the user to update a new password. Is there a way to handle password policies (either by ignoring it during mschap, or adding a pre/post filter of some sort)? Any help would greatly be appreciated, thanks in advance, --jsmith
if you enable the ldap/(opendirectory) option to "require user to change password on next login" the client is unable to connect.
FreeRADIUS doesn't support password changes via MSCHAP. Historically, Samba didn't even support it until a couple of years ago. I believe support for this functionality was added to Samba 3.0.24 using a new helper protocol called ntlm-change-password-1. I posted something to the list asking if there was interest quite a while ago. Implementing this new helper protocol is not a trivial change to FreeRADIUS. Unfortunately, I haven't had enough free time to devote to implementing it yet. If you have the time to create the patch, I'll be one of the testers ;-)
Greetings~ We are working on a patch. We're of the opinion that Apple's version rlm_mschap / opendir included with freeradius is missing something. It appears they were only considering someone entering a failed login/password combo... not a user with a password reset or an expired password. Here is the line from opendir.c: ====== if (status != eDSNoErr) { errno = EACCES; radlog(L_ERR, "rlm_mschap: authentication failed %d", status); /* <-- returns -14091 (eDSAuthMethodNotSupported) -14090 */ return RLM_MODULE_REJECT; } ====== The comment provided makes it seem like they only expected error -14090... -14090: eDSAuthFailed 0: eDSNoErr But what about? -14161: eDSAuthNewPasswordRequired -14162: eDSAuthPasswordExpired Possible solutions: --------------------------- Solution 1) Edit the opendir.c module to simple detect error status -14161 and -14162... and simply set the status to 0 instead. This should be "good enough" because we know the original password supplied was correct therefore... let the user proceed to full login through use of the login screens built in password prompt. (This assumes a user is authenticating to a networked home login, and probably requires the client to be a Mac OS X client). Solution 2) Try and rig up something in Post-Auth-Type REJECT {...} to override the failed login and force the response to Auth-Accept. Perhaps, some pseudo conf code that says if reject-message == -14162 || reject-message == -14161 ... then "ok update auth-type := accept Can anyone provide a sample Post-Auth-Type Reject example to do this? Thanks in advance. (PS... looks like this has been an issue for awhile??? we are new to freeradius... but I found your post here: http://www.opensubscriber.com/message/freeradius-devel@lists.freeradius.org/... from 3 years ago ... are we the only few interested in port security and a password policy?) ----- Original Message ---- From: "Garber, Neal" <Neal.Garber@energyeast.com> To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Sent: Wed, August 11, 2010 8:32:07 PM Subject: RE: Password Policy - Expired Password - mschap
if you enable the ldap/(opendirectory) option to "require user to change password on next login" the client is unable to connect.
FreeRADIUS doesn't support password changes via MSCHAP. Historically, Samba didn't even support it until a couple of years ago. I believe support for this functionality was added to Samba 3.0.24 using a new helper protocol called ntlm-change-password-1. I posted something to the list asking if there was interest quite a while ago. Implementing this new helper protocol is not a trivial change to FreeRADIUS. Unfortunately, I haven't had enough free time to devote to implementing it yet. If you have the time to create the patch, I'll be one of the testers ;-) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Theparanoidone Theparanoidone wrote:
We are working on a patch.
Good, thanks.
We're of the opinion that Apple's version rlm_mschap / opendir included with freeradius is missing something.
It appears they were only considering someone entering a failed login/password combo... not a user with a password reset or an expired password. Here is the line from opendir.c:
Pretty much, yes. Expired passwords, or password resets are "failed logins", just like incorrect passwords.
====== if (status != eDSNoErr) { errno = EACCES; radlog(L_ERR, "rlm_mschap: authentication failed %d", status); /* <-- returns -14091 (eDSAuthMethodNotSupported) -14090 */ return RLM_MODULE_REJECT; } ======
The comment provided makes it seem like they only expected error -14090...
So? It's a comment. It doesn't affect the way that the code operates.
-14090: eDSAuthFailed 0: eDSNoErr
But what about?
-14161: eDSAuthNewPasswordRequired -14162: eDSAuthPasswordExpired
They all fall into the same class: failed authentication.
Possible solutions: --------------------------- Solution 1) Edit the opendir.c module to simple detect error status -14161 and -14162... and simply set the status to 0 instead.
Absolutely not. Expired passwords are *not* OK.
Solution 2) Try and rig up something in Post-Auth-Type REJECT {...} to override the failed login and force the response to Auth-Accept. Perhaps, some pseudo conf code that says if reject-message == -14162 || reject-message == -14161 ... then "ok update auth-type := accept
No. That's just as bad.
(PS... looks like this has been an issue for awhile??? we are new to freeradius... but I found your post here: http://www.opensubscriber.com/message/freeradius-devel@lists.freeradius.org/... from 3 years ago ... are we the only few interested in port security and a password policy?)
Nonsense. That is not a good conclusion. The real reason is that very few people do password changes via MS-CHAP. Most people do it via Active Directory, LDAP, web pages, etc. Alan DeKok.
Greetings Alan~
Possible solutions: --------------------------- Solution 1) Edit the opendir.c module to simple detect error status -14161 and
-14162... and simply set the status to 0 instead.
Absolutely not. Expired passwords are *not* OK.
Solution 2) Try and rig up something in Post-Auth-Type REJECT {...} to override
the failed login and force the response to Auth-Accept. Perhaps, some pseudo
conf code that says if reject-message == -14162 || reject-message == -14161 ...
then "ok update auth-type := accept
No. That's just as bad. The real reason is that very few people do password changes via MS-CHAP. Most people do it via Active Directory, LDAP, web pages, etc. We are more than happy to perform the password change via LDAP(or apple's opendirectory)... however, the client computer is unable to connect to the network if they receive a failed authentication in the first step of 802.1x port security. In otherwords, the switch does not unlock the port until you successfully authenticate, and therefore it appears the client login screen doesn't know how to handle this case and is unable to display a password update screen or communicate on the network. Am I missing some configuration to allow LDAP to takeover? I agree that expired passwords are bad, but in the case where the client computer is completely blocked out due to a routine password expiration... perhaps a configuration option to allow expired passwords / and password resets is acceptable should a sysadmin choose to override this setting simply for radius. After all, there is only one password that will allow a user to unlock there account to update their old password... i.e. the user must present their old password one more time (which means technically the old password is still valid/good for one last task: updating the user password). Understanding the security risks... is there an example of setting Post-Auth-Type REJECT {...} to override the reject force the response to Auth-Accept? I've tried a number of combinations in the default virtual terminal (as another post said it is not processed in the inner tunnel), but I have been unable to get it to work. Any examples? Thank you!
Understanding the security risks... is there an example of setting Post-Auth-Type REJECT {...} to override the reject force the response to Auth-Accept?
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? 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..
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!
Theparanoidone Theparanoidone wrote:
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:
You are welcome to maintain this patch locally. i.e. on your system. "git" makes this easy. However, it cannot be added to the server.
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).
Check the password by hand, using a shell script.
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)
You can't turn a reject into an accept.
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.
No one else does password changes that way.
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.
Password change is not part of RADIUS. Alan DeKok.
Hi Alan~ Thank you for the reply; your response helps saves me some time.
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.
Password change is not part of RADIUS.
I am new to radius, and although it is now clear that "expired passwords == user is blocked until they can authenticate from some other computer" ... I'm just surprised. I guess an alternate method is to implement login scripts to check if a users password expiration is approaching, and if so... prompt the user to update it before it expires (via, email, popup, whatever). Is that what the rest of radius users do / a best practice? Thanks for all your help... all and all, freeradius is awesome. Thanks! ----- Original Message ---- From: Alan DeKok <aland@deployingradius.com> To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Sent: Thu, August 12, 2010 2:52:43 PM Subject: Re: Password Policy - Expired Password - mschap Theparanoidone Theparanoidone wrote:
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:
You are welcome to maintain this patch locally. i.e. on your system. "git" makes this easy. However, it cannot be added to the server.
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).
Check the password by hand, using a shell script.
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)
You can't turn a reject into an accept.
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.
No one else does password changes that way.
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.
Password change is not part of RADIUS. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Theparanoidone Theparanoidone wrote:
Password change is not part of RADIUS.
I am new to radius, and although it is now clear that "expired passwords == user is blocked until they can authenticate from some other computer" ... I'm just surprised.
RADIUS is a protocol which controls network access. If the users password has expired, it means that it is no longer valid for network access. Any other interpretation results in "password expiry" losing all meaning.
I guess an alternate method is to implement login scripts to check if a users password expiration is approaching, and if so... prompt the user to update it before it expires (via, email, popup, whatever).
Or, have the user call IT, and reset the password.
Is that what the rest of radius users do / a best practice?
They don't use password expiry, *or* they require users to reset their password before it expires.
Thanks for all your help... all and all, freeradius is awesome.
Thanks. Alan DeKok.
participants (3)
-
Alan DeKok -
Garber, Neal -
Theparanoidone Theparanoidone