Hi All, Is there anyway if the radius client can determine, if the user authentication failed due to user locked/user-not-existing. I think the RADIUS doesnt have a field in the response codes to indicate this information. This might be correct in the sense intruder doesnt know the actual reason for authentication failure. I just wanted to clarify that the information such as locked-state/passwdexpired,... cant be obtained through radius client. Thanks and Best Regards,
Reply-Message attribute. Ivan Kalik Kalik Informatika ISP Dana 15/9/2008, "Sudarshan Soma" <sudarshan12s@gmail.com> piše:
Hi All, Is there anyway if the radius client can determine, if the user authentication failed due to user locked/user-not-existing.
I think the RADIUS doesnt have a field in the response codes to indicate this information. This might be correct in the sense intruder doesnt know the actual reason for authentication failure.
I just wanted to clarify that the information such as locked-state/passwdexpired,... cant be obtained through radius client.
Thanks and Best Regards, - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Thanks a lot Ivan. Could you please correct me if the following are valid. 1. For determining session expiry, i can see the Reply-Message for session timeout from rlm_expiration module. But for determining locked users, i think rlm_unix doesnt pass RLM_MODULE_USERLOCK as part of Reply-Message. 2. For determining if user named xyz has typed wrong passwd and his privilage level, , i will keep /etc/raddb/users entry as xyz Auth-Type := Reject , User-password =~ "*" Reply-Message = "Invalid passwd for xyz(level 2)." I can parse Reply-Message to determine the privilage. Is this the right way to determine the user privilage? 3. For determining if the user is a valid radius user, i will keep this entry at the end in the /etc/raddb/users : DEFAULT Auth-Type := Reject Reply-Message = "Invalid user" Thanks and Regards, Pavan 2008/9/15 <tnt@kalik.net>:
Reply-Message attribute.
Ivan Kalik Kalik Informatika ISP
Dana 15/9/2008, "Sudarshan Soma" <sudarshan12s@gmail.com> piše:
Hi All, Is there anyway if the radius client can determine, if the user authentication failed due to user locked/user-not-existing.
I think the RADIUS doesnt have a field in the response codes to indicate this information. This might be correct in the sense intruder doesnt know the actual reason for authentication failure.
I just wanted to clarify that the information such as locked-state/passwdexpired,... cant be obtained through radius client.
Thanks and Best Regards, - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
1. For determining session expiry, i can see the Reply-Message for session timeout from rlm_expiration module. But for determining locked users, i think rlm_unix doesnt pass RLM_MODULE_USERLOCK as part of Reply-Message.
No. But have a look at "man unlang" and module return codes. You can use unlang to set Reply-Message in such cases.
2. For determining if user named xyz has typed wrong passwd and his privilage level, , i will keep /etc/raddb/users entry as
xyz Auth-Type := Reject , User-password =~ "*" Reply-Message = "Invalid passwd for xyz(level 2)."
I am not quite sure what you mean. Does your user have multiple entries where privilege level is determined by password? Like: xyz User-Password 1 Priv-Level 1 xyz User-Password 2 Priv-Level 2 You will not be able to determine which (level) password he wanted to use if he misses. You can remove password attribute from check line and level from the reply entry.
I can parse Reply-Message to determine the privilage. Is this the right way to determine the user privilage?
3. For determining if the user is a valid radius user, i will keep this entry at the end in the /etc/raddb/users :
DEFAULT Auth-Type := Reject Reply-Message = "Invalid user"
That's fine. Ivan Kalik Kalik Informatika ISP
On Tue, Sep 16, 2008 at 2:23 PM, <tnt@kalik.net> wrote:
1. For determining session expiry, i can see the Reply-Message for session timeout from rlm_expiration module. But for determining locked users, i think rlm_unix doesnt pass RLM_MODULE_USERLOCK as part of Reply-Message.
No. But have a look at "man unlang" and module return codes. You can use unlang to set Reply-Message in such cases.
[Pavan] Thanks, I will try this.
2. For determining if user named xyz has typed wrong passwd and his privilage level, , i will keep /etc/raddb/users entry as
xyz Auth-Type := Reject , User-password =~ "*" Reply-Message = "Invalid passwd for xyz(level 2)."
I am not quite sure what you mean. Does your user have multiple entries where privilege level is determined by password? Like:
xyz User-Password 1 Priv-Level 1
xyz User-Password 2 Priv-Level 2
You will not be able to determine which (level) password he wanted to use if he misses. You can remove password attribute from check line and level from the reply entry.
[Pavan] I am sorry for the confsion. I will rewrite my query : My intention here was to determine user privilage who has entered a wrong password. I need this privilage level for the user so that i can take appropriate action to lock user at NAS level. /ets/raddb/users have first entry for each user with correct passwd, followed by wrong passwd(kept it as regular expression *) xyz Auth-Type := Local , User-password = "xyz" Reply-Message = "successfull level(2)." xyz Auth-Type := Reject , User-password =~ "*" Reply-Message = "Invalid passwd for xyz(level 2)."
I can parse Reply-Message to determine the privilage. Is this the right way to determine the user privilage?
3. For determining if the user is a valid radius user, i will keep this entry at the end in the /etc/raddb/users :
DEFAULT Auth-Type := Reject Reply-Message = "Invalid user"
That's fine.
Ivan Kalik Kalik Informatika ISP
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Thanks so much. Pavan
First a few basic things. Are you using a very old version of the server? If you are, unlang is not going to work. If you are not, don't use Auth-Type Local and User-Password but Cleartext-Password as per instructions in users file. You can't pass priv level in Reply-Message. You need to consult your NAS documentation to see how it's done. It's usually passed in vendor specific attributes like Cisco avpairs.
/ets/raddb/users have first entry for each user with correct passwd, followed by wrong passwd(kept it as regular expression *)
xyz Auth-Type := Local , User-password = "xyz" Reply-Message = "successfull level(2)."
xyz Auth-Type := Reject , User-password =~ "*" Reply-Message = "Invalid passwd for xyz(level 2)."
You don't need regexp there. If user entries with passwords weren't matched it means that password is - wrong. No need to check for that. Ivan Kalik Kalik Informatika ISP
Hi Ivan, Please see my quick queries inline. I will read more on this and will let you know, meanwhile if you think iam starting in completely wrong way, please advise. On Tue, Sep 16, 2008 at 3:45 PM, <tnt@kalik.net> wrote:
First a few basic things. Are you using a very old version of the server? If you are, unlang is not going to work. If you are not, don't use Auth-Type Local and User-Password but Cleartext-Password as per instructions in users file. [Pavan] I was trying with older Radius Server (1.series)
You can't pass priv level in Reply-Message. You need to consult your NAS documentation to see how it's done. It's usually passed in vendor specific attributes like Cisco avpairs.
[Pavan] YES Agreed. I plan to add such attributes specific to my NAS.
/ets/raddb/users have first entry for each user with correct passwd, followed by wrong passwd(kept it as regular expression *)
xyz Auth-Type := Local , User-password = "xyz" Reply-Message = "successfull level(2)."
xyz Auth-Type := Reject , User-password =~ "*" Reply-Message = "Invalid passwd for xyz(level 2)."
You don't need regexp there. If user entries with passwords weren't matched it means that password is - wrong. No need to check for that.
[Pavan] If NAS has a requirement that - user with privilage level > 2 should not be locked on 4 consecutive invalid attempts. In this case i need the privilage level even if authentication fails to determine if he can be locked or not. Is this the correct way to do this? -- Does maintaining a database of users invalid attemtps count in NAS make sense -- Does the above entry look like an invalid/inconsistent entry.
Ivan Kalik Kalik Informatika ISP
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
[Pavan] If NAS has a requirement that - user with privilage level > 2 should not be locked on 4 consecutive invalid attempts. In this case i need the privilage level even if authentication fails to determine if he can be locked or not.
Is this the correct way to do this? -- Does maintaining a database of users invalid attemtps count in NAS make sense
I would upgrade to latest version and use something like perl to authenticate. Your requirements are not standard stuff. Invalid attempts are not logged by freeradius by default. You will have to count that yourself. Your NAS might have facility to lock out users after a certain number of failed attempts for local user database but not very likely when using radius. http://wiki.freeradius.org/Rlm_perl Ivan Kalik Kalik Informatika ISP
Thanks Ivan for your valuable inputs. I would look at rlm_perl, if i have to lock radius users. On Tue, Sep 16, 2008 at 6:06 PM, <tnt@kalik.net> wrote:
[Pavan] If NAS has a requirement that - user with privilage level > 2 should not be locked on 4 consecutive invalid attempts. In this case i need the privilage level even if authentication fails to determine if he can be locked or not.
Is this the correct way to do this? -- Does maintaining a database of users invalid attemtps count in NAS make sense
I would upgrade to latest version and use something like perl to authenticate. Your requirements are not standard stuff. Invalid attempts are not logged by freeradius by default. You will have to count that yourself. Your NAS might have facility to lock out users after a certain number of failed attempts for local user database but not very likely when using radius.
http://wiki.freeradius.org/Rlm_perl
Ivan Kalik Kalik Informatika ISP
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (2)
-
Sudarshan Soma -
tnt＠kalik.net