Freeradius/MySql problem
I currently run ver.0.9.3 I have MySql database that is used with FreeRadius. What were are having a problem with is that if the user logs in with UPPER-NAME or lower-name either one works. I have tried lower_user & lower_pass before/after/no and the radius system still authenticates all UPPER-CASE. With this we are getting double billed by our wholesale provider because they run unix based also and it sees both as valid log ins because we authenticated them. When we built our MySql we use with the setup in FreeRadius. Has anyone else had this and how did you fix this to keep everyone lower case. Thanks Bob Ross
In the config file you can set it to force all lower case. I had this problem and solved it by changing it in the config. Nick Marino - IT Solutions ----- Original Message ----- From: "Radius" <radius@kingmanaz.net> To: <freeradius-users@lists.freeradius.org> Sent: Saturday, July 02, 2005 12:10 PM Subject: [radius] Freeradius/MySql problem
I currently run ver.0.9.3
I have MySql database that is used with FreeRadius.
What were are having a problem with is that if the user logs in with UPPER-NAME or lower-name either one works.
I have tried lower_user & lower_pass before/after/no and the radius system still authenticates all UPPER-CASE.
With this we are getting double billed by our wholesale provider because they run unix based also and it sees both as valid log ins because we authenticated them.
When we built our MySql we use with the setup in FreeRadius.
Has anyone else had this and how did you fix this to keep everyone lower case.
Thanks Bob Ross
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.8/37 - Release Date: 7/1/2005
-- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.8/37 - Release Date: 7/1/2005
In the radius.conf under lower_user & lower_pass I tried all three. before/after/no and they will still authenticate all UPPER CASE. What other config file are you talking about? Thanks Nick Marino wrote:
In the config file you can set it to force all lower case.
I had this problem and solved it by changing it in the config.
Nick Marino - IT Solutions ----- Original Message ----- From: "Radius" <radius@kingmanaz.net> To: <freeradius-users@lists.freeradius.org> Sent: Saturday, July 02, 2005 12:10 PM Subject: [radius] Freeradius/MySql problem
I currently run ver.0.9.3
I have MySql database that is used with FreeRadius.
What were are having a problem with is that if the user logs in with UPPER-NAME or lower-name either one works.
I have tried lower_user & lower_pass before/after/no and the radius system still authenticates all UPPER-CASE.
With this we are getting double billed by our wholesale provider because they run unix based also and it sees both as valid log ins because we authenticated them.
When we built our MySql we use with the setup in FreeRadius.
Has anyone else had this and how did you fix this to keep everyone lower case.
Thanks Bob Ross
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.8/37 - Release Date: 7/1/2005
Let me look at my files and find the exact entry. Nick Marino - IT Solutions ----- Original Message ----- From: "Radius" <radius@kingmanaz.net> To: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Saturday, July 02, 2005 12:36 PM Subject: Re: [radius] Freeradius/MySql problem
In the radius.conf under lower_user & lower_pass
I tried all three. before/after/no and they will still authenticate all UPPER CASE.
What other config file are you talking about?
Thanks
Nick Marino wrote:
In the config file you can set it to force all lower case.
I had this problem and solved it by changing it in the config.
Nick Marino - IT Solutions ----- Original Message ----- From: "Radius" <radius@kingmanaz.net> To: <freeradius-users@lists.freeradius.org> Sent: Saturday, July 02, 2005 12:10 PM Subject: [radius] Freeradius/MySql problem
I currently run ver.0.9.3
I have MySql database that is used with FreeRadius.
What were are having a problem with is that if the user logs in with UPPER-NAME or lower-name either one works.
I have tried lower_user & lower_pass before/after/no and the radius system still authenticates all UPPER-CASE.
With this we are getting double billed by our wholesale provider because they run unix based also and it sees both as valid log ins because we authenticated them.
When we built our MySql we use with the setup in FreeRadius.
Has anyone else had this and how did you fix this to keep everyone lower case.
Thanks Bob Ross
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.8/37 - Release Date: 7/1/2005
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.8/37 - Release Date: 7/1/2005
-- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.8/37 - Release Date: 7/1/2005
Forcing to lower case is not the problem. When a user logs in over our wholesale providers network we need to deny UPPER case logins. MySql does not care if it's upper or lower and they get authenticated I want to just deny UPPER letter logins will be the easiest. I have looked at the MySql table settings, and how they say to change this, but it also says you do one thing wrong you will corrupt the database. Don't want that. Nick Marino wrote:
Let me look at my files and find the exact entry.
Nick Marino - IT Solutions ----- Original Message ----- From: "Radius" <radius@kingmanaz.net> To: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Saturday, July 02, 2005 12:36 PM Subject: Re: [radius] Freeradius/MySql problem
In the radius.conf under lower_user & lower_pass
I tried all three. before/after/no and they will still authenticate all UPPER CASE.
What other config file are you talking about?
Thanks
Nick Marino wrote:
In the config file you can set it to force all lower case.
I had this problem and solved it by changing it in the config.
Nick Marino - IT Solutions ----- Original Message ----- From: "Radius" <radius@kingmanaz.net> To: <freeradius-users@lists.freeradius.org> Sent: Saturday, July 02, 2005 12:10 PM Subject: [radius] Freeradius/MySql problem
I currently run ver.0.9.3
I have MySql database that is used with FreeRadius.
What were are having a problem with is that if the user logs in with UPPER-NAME or lower-name either one works.
I have tried lower_user & lower_pass before/after/no and the radius system still authenticates all UPPER-CASE.
With this we are getting double billed by our wholesale provider because they run unix based also and it sees both as valid log ins because we authenticated them.
When we built our MySql we use with the setup in FreeRadius.
Has anyone else had this and how did you fix this to keep everyone lower case.
Thanks Bob Ross
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.8/37 - Release Date: 7/1/2005
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.8/37 - Release Date: 7/1/2005
OK, let me try this way, when our wholesale provider receives a realm, they know where to send the request. If the user sends RADIUS@kingmanaz.net or radius@kingmanaz.net our radius regardless if I have lower_user before/after/no They will be authenticated either way. If we force it lower on our end, does not force lower on their end. It's a mess. They said only this month they were going to issue credits and that I needed to get my end to deny UPPER case logins. I set the lower_user lower and lower_pass to no and a user will all RADOUS@kingmanaz.net will be authenticated. I guess mysql doesn't care if it's upper or lower. Nick Marino wrote:
In the config file you can set it to force all lower case.
I had this problem and solved it by changing it in the config.
Nick Marino - IT Solutions ----- Original Message ----- From: "Radius" <radius@kingmanaz.net> To: <freeradius-users@lists.freeradius.org> Sent: Saturday, July 02, 2005 12:10 PM Subject: [radius] Freeradius/MySql problem
I currently run ver.0.9.3
I have MySql database that is used with FreeRadius.
What were are having a problem with is that if the user logs in with UPPER-NAME or lower-name either one works.
I have tried lower_user & lower_pass before/after/no and the radius system still authenticates all UPPER-CASE.
With this we are getting double billed by our wholesale provider because they run unix based also and it sees both as valid log ins because we authenticated them.
When we built our MySql we use with the setup in FreeRadius.
Has anyone else had this and how did you fix this to keep everyone lower case.
Thanks Bob Ross
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.8/37 - Release Date: 7/1/2005
This is what I have and it works. Also there are some options in the sql.conf that relate to this make sure you have the right lines uncommented in there. Open sql.conf and search for lower. Are you sure their is not something in your realms section overriding this? # This is as close as we can get to case insensitivity. It is # the admin's job to ensure that the username on the auth # db side is *also* lowercase to make this work # # Default is 'no' (don't lowercase values) # Valid values = "before" / "after" / "no" # lower_user = before lower_pass = before Nick Marino - IT Solutions ----- Original Message ----- From: "Radius" <radius@kingmanaz.net> To: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Saturday, July 02, 2005 12:42 PM Subject: Re: [radius] Freeradius/MySql problem
OK, let me try this way, when our wholesale provider receives a realm, they know where to send the request.
If the user sends RADIUS@kingmanaz.net or radius@kingmanaz.net
our radius regardless if I have lower_user before/after/no
They will be authenticated either way.
If we force it lower on our end, does not force lower on their end.
It's a mess. They said only this month they were going to issue credits and that I needed to get my end to deny UPPER case logins.
I set the lower_user lower and lower_pass to no and a user will all RADOUS@kingmanaz.net will be authenticated. I guess mysql doesn't care if it's upper or lower.
Nick Marino wrote:
In the config file you can set it to force all lower case.
I had this problem and solved it by changing it in the config.
Nick Marino - IT Solutions ----- Original Message ----- From: "Radius" <radius@kingmanaz.net> To: <freeradius-users@lists.freeradius.org> Sent: Saturday, July 02, 2005 12:10 PM Subject: [radius] Freeradius/MySql problem
I currently run ver.0.9.3
I have MySql database that is used with FreeRadius.
What were are having a problem with is that if the user logs in with UPPER-NAME or lower-name either one works.
I have tried lower_user & lower_pass before/after/no and the radius system still authenticates all UPPER-CASE.
With this we are getting double billed by our wholesale provider because they run unix based also and it sees both as valid log ins because we authenticated them.
When we built our MySql we use with the setup in FreeRadius.
Has anyone else had this and how did you fix this to keep everyone lower case.
Thanks Bob Ross
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.8/37 - Release Date: 7/1/2005
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.8/37 - Release Date: 7/1/2005
-- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.8/37 - Release Date: 7/1/2005
Yes, I found what you mention below in the radius.conf I will look through the sql. file also. I understand this. but if I force lower to RADIUS@kingmanaz.net our upstream sees this as an authentication. If the user logs in with radius@kingmanaz.net our upstream sees this also as an authentication. I get double billed. If I put lower_user & lower_pass to no they still get authenticated. I need to deny UPPER case. Nick Marino wrote:
This is what I have and it works. Also there are some options in the sql.conf that relate to this make sure you have the right lines uncommented in there.
Open sql.conf and search for lower.
Are you sure their is not something in your realms section overriding this?
# This is as close as we can get to case insensitivity. It is # the admin's job to ensure that the username on the auth # db side is *also* lowercase to make this work # # Default is 'no' (don't lowercase values) # Valid values = "before" / "after" / "no" # lower_user = before lower_pass = before
Nick Marino - IT Solutions ----- Original Message ----- From: "Radius" <radius@kingmanaz.net> To: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Saturday, July 02, 2005 12:42 PM Subject: Re: [radius] Freeradius/MySql problem
OK, let me try this way, when our wholesale provider receives a realm, they know where to send the request.
If the user sends RADIUS@kingmanaz.net or radius@kingmanaz.net
our radius regardless if I have lower_user before/after/no
They will be authenticated either way.
If we force it lower on our end, does not force lower on their end.
It's a mess. They said only this month they were going to issue credits and that I needed to get my end to deny UPPER case logins.
I set the lower_user lower and lower_pass to no and a user will all RADOUS@kingmanaz.net will be authenticated. I guess mysql doesn't care if it's upper or lower.
Nick Marino wrote:
In the config file you can set it to force all lower case.
I had this problem and solved it by changing it in the config.
Nick Marino - IT Solutions ----- Original Message ----- From: "Radius" <radius@kingmanaz.net> To: <freeradius-users@lists.freeradius.org> Sent: Saturday, July 02, 2005 12:10 PM Subject: [radius] Freeradius/MySql problem
I currently run ver.0.9.3
I have MySql database that is used with FreeRadius.
What were are having a problem with is that if the user logs in with UPPER-NAME or lower-name either one works.
I have tried lower_user & lower_pass before/after/no and the radius system still authenticates all UPPER-CASE.
With this we are getting double billed by our wholesale provider because they run unix based also and it sees both as valid log ins because we authenticated them.
When we built our MySql we use with the setup in FreeRadius.
Has anyone else had this and how did you fix this to keep everyone lower case.
Thanks Bob Ross
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.8/37 - Release Date: 7/1/2005
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.8/37 - Release Date: 7/1/2005
First you need to have a standard for your accounts you need to decide if they should all be uppercase or lower case then restrict the oppisite. I am not understanding if you are saying you have accounts that some are uppercase and some are lower case? What is your standard? Nick Marino - IT Solutions ----- Original Message ----- From: "Radius" <radius@kingmanaz.net> To: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Saturday, July 02, 2005 1:23 PM Subject: Re: [radius] Freeradius/MySql problem
Yes, I found what you mention below in the radius.conf
I will look through the sql. file also.
I understand this. but if I force lower to RADIUS@kingmanaz.net our upstream sees this as an authentication. If the user logs in with radius@kingmanaz.net our upstream sees this also as an authentication.
I get double billed.
If I put lower_user & lower_pass to no they still get authenticated.
I need to deny UPPER case.
Nick Marino wrote:
This is what I have and it works. Also there are some options in the sql.conf that relate to this make sure you have the right lines uncommented in there.
Open sql.conf and search for lower.
Are you sure their is not something in your realms section overriding this?
# This is as close as we can get to case insensitivity. It is # the admin's job to ensure that the username on the auth # db side is *also* lowercase to make this work # # Default is 'no' (don't lowercase values) # Valid values = "before" / "after" / "no" # lower_user = before lower_pass = before
Nick Marino - IT Solutions ----- Original Message ----- From: "Radius" <radius@kingmanaz.net> To: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Saturday, July 02, 2005 12:42 PM Subject: Re: [radius] Freeradius/MySql problem
OK, let me try this way, when our wholesale provider receives a realm, they know where to send the request.
If the user sends RADIUS@kingmanaz.net or radius@kingmanaz.net
our radius regardless if I have lower_user before/after/no
They will be authenticated either way.
If we force it lower on our end, does not force lower on their end.
It's a mess. They said only this month they were going to issue credits and that I needed to get my end to deny UPPER case logins.
I set the lower_user lower and lower_pass to no and a user will all RADOUS@kingmanaz.net will be authenticated. I guess mysql doesn't care if it's upper or lower.
Nick Marino wrote:
In the config file you can set it to force all lower case.
I had this problem and solved it by changing it in the config.
Nick Marino - IT Solutions ----- Original Message ----- From: "Radius" <radius@kingmanaz.net> To: <freeradius-users@lists.freeradius.org> Sent: Saturday, July 02, 2005 12:10 PM Subject: [radius] Freeradius/MySql problem
I currently run ver.0.9.3
I have MySql database that is used with FreeRadius.
What were are having a problem with is that if the user logs in with UPPER-NAME or lower-name either one works.
I have tried lower_user & lower_pass before/after/no and the radius system still authenticates all UPPER-CASE.
With this we are getting double billed by our wholesale provider because they run unix based also and it sees both as valid log ins because we authenticated them.
When we built our MySql we use with the setup in FreeRadius.
Has anyone else had this and how did you fix this to keep everyone lower case.
Thanks Bob Ross
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.8/37 - Release Date: 7/1/2005
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.8/37 - Release Date: 7/1/2005
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.8/37 - Release Date: 7/1/2005
-- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.8/37 - Release Date: 7/1/2005
They are all lower case. In all the databases they are lower case. But when someone logs in on our wholesale service and they put UPPER case regardless how I have radius set they still authenticate either way. Since the provider requires chap, we use mysql. On our local number is PAP, so anyone that logs in with upper would get refused unless we force to lower, but then were right back where we started. To avoid being billed for both the upper log in and lower logins with our whole seller, I need to deny anything that shows up with UPPER case. Nick Marino wrote:
First you need to have a standard for your accounts you need to decide if they should all be uppercase or lower case then restrict the oppisite.
I am not understanding if you are saying you have accounts that some are uppercase and some are lower case?
What is your standard?
Nick Marino - IT Solutions ----- Original Message ----- From: "Radius" <radius@kingmanaz.net> To: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Saturday, July 02, 2005 1:23 PM Subject: Re: [radius] Freeradius/MySql problem
Yes, I found what you mention below in the radius.conf
I will look through the sql. file also.
I understand this. but if I force lower to RADIUS@kingmanaz.net our upstream sees this as an authentication. If the user logs in with radius@kingmanaz.net our upstream sees this also as an authentication.
I get double billed.
If I put lower_user & lower_pass to no they still get authenticated.
I need to deny UPPER case.
Nick Marino wrote:
This is what I have and it works. Also there are some options in the sql.conf that relate to this make sure you have the right lines uncommented in there.
Open sql.conf and search for lower.
Are you sure their is not something in your realms section overriding this?
# This is as close as we can get to case insensitivity. It is # the admin's job to ensure that the username on the auth # db side is *also* lowercase to make this work # # Default is 'no' (don't lowercase values) # Valid values = "before" / "after" / "no" # lower_user = before lower_pass = before
Nick Marino - IT Solutions ----- Original Message ----- From: "Radius" <radius@kingmanaz.net> To: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Saturday, July 02, 2005 12:42 PM Subject: Re: [radius] Freeradius/MySql problem
OK, let me try this way, when our wholesale provider receives a realm, they know where to send the request.
If the user sends RADIUS@kingmanaz.net or radius@kingmanaz.net
our radius regardless if I have lower_user before/after/no
They will be authenticated either way.
If we force it lower on our end, does not force lower on their end.
It's a mess. They said only this month they were going to issue credits and that I needed to get my end to deny UPPER case logins.
I set the lower_user lower and lower_pass to no and a user will all RADOUS@kingmanaz.net will be authenticated. I guess mysql doesn't care if it's upper or lower.
Nick Marino wrote:
In the config file you can set it to force all lower case.
I had this problem and solved it by changing it in the config.
Nick Marino - IT Solutions ----- Original Message ----- From: "Radius" <radius@kingmanaz.net> To: <freeradius-users@lists.freeradius.org> Sent: Saturday, July 02, 2005 12:10 PM Subject: [radius] Freeradius/MySql problem
I currently run ver.0.9.3
I have MySql database that is used with FreeRadius.
What were are having a problem with is that if the user logs in with UPPER-NAME or lower-name either one works.
I have tried lower_user & lower_pass before/after/no and the radius system still authenticates all UPPER-CASE.
With this we are getting double billed by our wholesale provider because they run unix based also and it sees both as valid log ins because we authenticated them.
When we built our MySql we use with the setup in FreeRadius.
Has anyone else had this and how did you fix this to keep everyone lower case.
Thanks Bob Ross
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.8/37 - Release Date: 7/1/2005
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.8/37 - Release Date: 7/1/2005
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.8/37 - Release Date: 7/1/2005
I tried the case sensitive attributes in the sql.conf but that didn't help. Looks as if it's going to be in MySql that I'll have to have set. That is not going to be fun at all. Nick Marino wrote:
This is what I have and it works. Also there are some options in the sql.conf that relate to this make sure you have the right lines uncommented in there.
Open sql.conf and search for lower.
Are you sure their is not something in your realms section overriding this?
# This is as close as we can get to case insensitivity. It is # the admin's job to ensure that the username on the auth # db side is *also* lowercase to make this work # # Default is 'no' (don't lowercase values) # Valid values = "before" / "after" / "no" # lower_user = before lower_pass = before
Nick Marino - IT Solutions ----- Original Message ----- From: "Radius" <radius@kingmanaz.net> To: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Saturday, July 02, 2005 12:42 PM Subject: Re: [radius] Freeradius/MySql problem
OK, let me try this way, when our wholesale provider receives a realm, they know where to send the request.
If the user sends RADIUS@kingmanaz.net or radius@kingmanaz.net
our radius regardless if I have lower_user before/after/no
They will be authenticated either way.
If we force it lower on our end, does not force lower on their end.
It's a mess. They said only this month they were going to issue credits and that I needed to get my end to deny UPPER case logins.
I set the lower_user lower and lower_pass to no and a user will all RADOUS@kingmanaz.net will be authenticated. I guess mysql doesn't care if it's upper or lower.
Nick Marino wrote:
In the config file you can set it to force all lower case.
I had this problem and solved it by changing it in the config.
Nick Marino - IT Solutions ----- Original Message ----- From: "Radius" <radius@kingmanaz.net> To: <freeradius-users@lists.freeradius.org> Sent: Saturday, July 02, 2005 12:10 PM Subject: [radius] Freeradius/MySql problem
I currently run ver.0.9.3
I have MySql database that is used with FreeRadius.
What were are having a problem with is that if the user logs in with UPPER-NAME or lower-name either one works.
I have tried lower_user & lower_pass before/after/no and the radius system still authenticates all UPPER-CASE.
With this we are getting double billed by our wholesale provider because they run unix based also and it sees both as valid log ins because we authenticated them.
When we built our MySql we use with the setup in FreeRadius.
Has anyone else had this and how did you fix this to keep everyone lower case.
Thanks Bob Ross
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.8/37 - Release Date: 7/1/2005
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.8/37 - Release Date: 7/1/2005
On Sat, Jul 02, 2005 at 10:42:44AM -0700, Radius wrote:
OK, let me try this way, when our wholesale provider receives a realm, they know where to send the request.
If the user sends RADIUS@kingmanaz.net or radius@kingmanaz.net
our radius regardless if I have lower_user before/after/no
They will be authenticated either way.
If we force it lower on our end, does not force lower on their end.
It's a mess. They said only this month they were going to issue credits and that I needed to get my end to deny UPPER case logins.
I set the lower_user lower and lower_pass to no and a user will all RADOUS@kingmanaz.net will be authenticated. I guess mysql doesn't care if it's upper or lower.
For what you want to do, you need to set lower_user to 'no', and check your authorize_check_query to be sure you're using the one that has "STRCMP(Username, '%{SQL-User-Name}')" and not the one that has "Username = '%{SQL-User-Name}'". ie (this is in 1.0.4, and doesn't work with mysql 4 onwards.) # Use these for case sensitive usernames. WARNING: Slower queries! authorize_check_query = "SELECT id,UserName,Attribute,Value,op FROM ${authcheck_table} WHERE STRCMP(Username, '%{SQL-User-Name}') = 0 ORDER BY id" authorize_reply_query = "SELECT id,UserName,Attribute,Value,op FROM ${authreply_table} WHERE STRCMP(Username, '%{SQL-User-Name}') = 0 ORDER BY id" # authorize_check_query = "SELECT id,UserName,Attribute,Value,op FROM ${authcheck_table} WHERE Username = '%{SQL-User-Name}' ORDER BY id" # authorize_reply_query = "SELECT id,UserName,Attribute,Value,op FROM ${authreply_table} WHERE Username = '%{SQL-User-Name}' ORDER BY id" rather than the default. # Use these for case sensitive usernames. WARNING: Slower queries! # authorize_check_query = "SELECT id,UserName,Attribute,Value,op FROM ${authcheck_table} WHERE STRCMP(Username, '%{SQL-User-Name}') = 0 ORDER BY id" # authorize_reply_query = "SELECT id,UserName,Attribute,Value,op FROM ${authreply_table} WHERE STRCMP(Username, '%{SQL-User-Name}') = 0 ORDER BY id" authorize_check_query = "SELECT id,UserName,Attribute,Value,op FROM ${authcheck_table} WHERE Username = '%{SQL-User-Name}' ORDER BY id" authorize_reply_query = "SELECT id,UserName,Attribute,Value,op FROM ${authreply_table} WHERE Username = '%{SQL-User-Name}' ORDER BY id" (That's only moving the #s, not changing the query itself.) This is the joy of mySQL, it's not case-sensitive for string comparisons by default. ^_^ Alternatively, change the radcheck table's UserName column to be 'BINARY', see http://dev.mysql.com/doc/mysql/en/case-sensitivity.html for details. (Although that's mySQL 4.1. If you're using a packaged mySQL from a distribution, check A.5.1 in the included manual for more specific details.) In fact, I'd be interested to know if authorize_check_query = "SELECT id,UserName,Attribute,Value,op FROM ${authcheck_table} WHERE BINARY Username = '%{SQL-User-Name}' ORDER BY id" authorize_reply_query = "SELECT id,UserName,Attribute,Value,op FROM ${authreply_table} WHERE BINARY Username = '%{SQL-User-Name}' ORDER BY id" fixes it, and if it works for mySQL < 4, because it's more future-proofed than STRCMP, which has already changed semantics. -- Paul "TBBle" Hampson, on an alternate email client.
After updated to 1.04 and making the changes again what you recommend below and when I try to run radtest I get all kinds of these dup error. radclient: dict_init: /usr/local/radius/share/freeradius/dictionary.acc[110]: dict_addvalue: Duplicate value name Administrative-reset for attribute Acc-Reason-Code But it's in a lot of the dictionary files. I find all the dups and it just keeps going. I tried to go back to 0.9.3, but something happened. It is now wanting to run 1.04 all the time. So far people are still loggin in so it hasn't been misconfigured to bad. Paul Hampson wrote:
On Sat, Jul 02, 2005 at 10:42:44AM -0700, Radius wrote:
OK, let me try this way, when our wholesale provider receives a realm, they know where to send the request.
If the user sends RADIUS@kingmanaz.net or radius@kingmanaz.net
our radius regardless if I have lower_user before/after/no
They will be authenticated either way.
If we force it lower on our end, does not force lower on their end.
It's a mess. They said only this month they were going to issue credits and that I needed to get my end to deny UPPER case logins.
I set the lower_user lower and lower_pass to no and a user will all RADOUS@kingmanaz.net will be authenticated. I guess mysql doesn't care if it's upper or lower.
For what you want to do, you need to set lower_user to 'no', and check your authorize_check_query to be sure you're using the one that has "STRCMP(Username, '%{SQL-User-Name}')" and not the one that has "Username = '%{SQL-User-Name}'".
ie (this is in 1.0.4, and doesn't work with mysql 4 onwards.)
# Use these for case sensitive usernames. WARNING: Slower queries! authorize_check_query = "SELECT id,UserName,Attribute,Value,op FROM ${authcheck_table} WHERE STRCMP(Username, '%{SQL-User-Name}') = 0 ORDER BY id" authorize_reply_query = "SELECT id,UserName,Attribute,Value,op FROM ${authreply_table} WHERE STRCMP(Username, '%{SQL-User-Name}') = 0 ORDER BY id"
# authorize_check_query = "SELECT id,UserName,Attribute,Value,op FROM ${authcheck_table} WHERE Username = '%{SQL-User-Name}' ORDER BY id" # authorize_reply_query = "SELECT id,UserName,Attribute,Value,op FROM ${authreply_table} WHERE Username = '%{SQL-User-Name}' ORDER BY id"
rather than the default.
# Use these for case sensitive usernames. WARNING: Slower queries! # authorize_check_query = "SELECT id,UserName,Attribute,Value,op FROM ${authcheck_table} WHERE STRCMP(Username, '%{SQL-User-Name}') = 0 ORDER BY id" # authorize_reply_query = "SELECT id,UserName,Attribute,Value,op FROM ${authreply_table} WHERE STRCMP(Username, '%{SQL-User-Name}') = 0 ORDER BY id"
authorize_check_query = "SELECT id,UserName,Attribute,Value,op FROM ${authcheck_table} WHERE Username = '%{SQL-User-Name}' ORDER BY id" authorize_reply_query = "SELECT id,UserName,Attribute,Value,op FROM ${authreply_table} WHERE Username = '%{SQL-User-Name}' ORDER BY id"
(That's only moving the #s, not changing the query itself.)
This is the joy of mySQL, it's not case-sensitive for string comparisons by default. ^_^
Alternatively, change the radcheck table's UserName column to be 'BINARY', see http://dev.mysql.com/doc/mysql/en/case-sensitivity.html for details. (Although that's mySQL 4.1. If you're using a packaged mySQL from a distribution, check A.5.1 in the included manual for more specific details.)
In fact, I'd be interested to know if authorize_check_query = "SELECT id,UserName,Attribute,Value,op FROM ${authcheck_table} WHERE BINARY Username = '%{SQL-User-Name}' ORDER BY id" authorize_reply_query = "SELECT id,UserName,Attribute,Value,op FROM ${authreply_table} WHERE BINARY Username = '%{SQL-User-Name}' ORDER BY id" fixes it, and if it works for mySQL < 4, because it's more future-proofed than STRCMP, which has already changed semantics.
Radius <radius@kingmanaz.net> wrote:
After updated to 1.04 and making the changes again what you recommend below and when I try to run radtest I get all kinds of these dup error.
radclient: dict_init: /usr/local/radius/share/freeradius/dictionary.acc[110]: dict_addvalue: Duplicate value name Administrative-reset for attribute Acc-Reason-Code
You need to point /etc/raddb/dictionary to the new 1.0.4 dictionaries.q See raddb/dictionary in the 1.0.4 source distribution. Alan DeKok.
OK,, I'm confused $ cp ./raddb/dictionary /etc/raddb/dictionary I have a directory /etc/raddb/dictonary Do I also need to create ./raddb/dictonary ? Thanks Alan DeKok wrote:
Radius <radius@kingmanaz.net> wrote:
After updated to 1.04 and making the changes again what you recommend below and when I try to run radtest I get all kinds of these dup error.
radclient: dict_init: /usr/local/radius/share/freeradius/dictionary.acc[110]: dict_addvalue: Duplicate value name Administrative-reset for attribute Acc-Reason-Code
You need to point /etc/raddb/dictionary to the new 1.0.4 dictionaries.q
See raddb/dictionary in the 1.0.4 source distribution.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Radius <radius@kingmanaz.net> wrote:
I have a directory /etc/raddb/dictonary
FreeRADIUS never created that. It should be a file.
See raddb/dictionary in the 1.0.4 source distribution.
it says in there that they are at /usr/local/share/freeradius/
and they are there. I did the default installation.
What you missed is that the dictionary in /etc/raddb/dictionary should be nothing more than a reference to the /usr/local/share/freeradius files.
When I edit and delete the dups, it just keeps going one file after the other.
Don't edit the dictionaries! This whole problem came about because when you upgraded the "make install" process told you what you would have to do next, and you ignored it. You then went and edited mor ethings without understanding them, making random changes in the hopes that something would work.
I'll have to pull 0.93 from an old backup. This seems to be getting worse as I try to make adjustments.
Exactly. Your "adjustments" are based on incomplete knowledge, and as a result, are wrong. The simple solution is to re-install 1.0.4, but this time do: $ ./configure --prefix=/opt/freeradius $ make $ make install Since you don't already have a "/opt/freeradius" directory, it will make one, install itself, and the version of the server in /opt/freeradius WILL WORK. You can then update the configuration files in /opt/freeradius/etc/raddb to match your local configuration. And DON'T EDIT THE DICTIONARY FILES. Alan DeKok.
Alan DeKok wrote:
Radius <radius@kingmanaz.net> wrote:
I have a directory /etc/raddb/dictonary
FreeRADIUS never created that.
It should be a file.
It was a file. I should have been more clear.
See raddb/dictionary in the 1.0.4 source distribution.
it says in there that they are at /usr/local/share/freeradius/
and they are there. I did the default installation.
What you missed is that the dictionary in /etc/raddb/dictionary should be nothing more than a reference to the /usr/local/share/freeradius files.
Yep it did.
When I edit and delete the dups, it just keeps going one file after the other.
Exactly. Your "adjustments" are based on incomplete knowledge, and as a result, are wrong.
The simple solution is to re-install 1.0.4, but this time do:
$ ./configure --prefix=/opt/freeradius $ make $ make install
This is what I did do the first time when all the troubles started. The second and third time I installed, I left it out figuring that caused the problem.
Since you don't already have a "/opt/freeradius" directory, it will make one, install itself, and the version of the server in /opt/freeradius WILL WORK.
Nope, it never got created there. I checked. Nothing in that directory. Yes I'm logged in as user root.
You can then update the configuration files in /opt/freeradius/etc/raddb to match your local configuration.
And DON'T EDIT THE DICTIONARY FILES.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Sorry, I take that back.... I used ./configure --localstatedir=/var --sysconfdir=/etc because when I went to 0.93 last year I was using Cistron. Alan DeKok wrote:
Radius <radius@kingmanaz.net> wrote:
I have a directory /etc/raddb/dictonary
FreeRADIUS never created that.
It should be a file.
See raddb/dictionary in the 1.0.4 source distribution.
it says in there that they are at /usr/local/share/freeradius/
and they are there. I did the default installation.
What you missed is that the dictionary in /etc/raddb/dictionary should be nothing more than a reference to the /usr/local/share/freeradius files.
When I edit and delete the dups, it just keeps going one file after the other.
Don't edit the dictionaries! This whole problem came about because when you upgraded the "make install" process told you what you would have to do next, and you ignored it. You then went and edited mor ethings without understanding them, making random changes in the hopes that something would work.
I'll have to pull 0.93 from an old backup. This seems to be getting worse as I try to make adjustments.
Exactly. Your "adjustments" are based on incomplete knowledge, and as a result, are wrong.
The simple solution is to re-install 1.0.4, but this time do:
$ ./configure --prefix=/opt/freeradius $ make $ make install
Since you don't already have a "/opt/freeradius" directory, it will make one, install itself, and the version of the server in /opt/freeradius WILL WORK.
You can then update the configuration files in /opt/freeradius/etc/raddb to match your local configuration.
And DON'T EDIT THE DICTIONARY FILES.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
I re-ran the install as you said below. I think it's working, I just have to get used to adding /opt/freeradius in the command lines. Been watching with the radiusd -x and can even run a radtest But now I'm back to the original problem to deny anything with UPPER CASE letters to prevent double billing by our provider. Alan DeKok wrote:
Radius <radius@kingmanaz.net> wrote:
I have a directory /etc/raddb/dictonary
FreeRADIUS never created that.
It should be a file.
See raddb/dictionary in the 1.0.4 source distribution.
it says in there that they are at /usr/local/share/freeradius/
and they are there. I did the default installation.
What you missed is that the dictionary in /etc/raddb/dictionary should be nothing more than a reference to the /usr/local/share/freeradius files.
When I edit and delete the dups, it just keeps going one file after the other.
Don't edit the dictionaries! This whole problem came about because when you upgraded the "make install" process told you what you would have to do next, and you ignored it. You then went and edited mor ethings without understanding them, making random changes in the hopes that something would work.
I'll have to pull 0.93 from an old backup. This seems to be getting worse as I try to make adjustments.
Exactly. Your "adjustments" are based on incomplete knowledge, and as a result, are wrong.
The simple solution is to re-install 1.0.4, but this time do:
$ ./configure --prefix=/opt/freeradius $ make $ make install
Since you don't already have a "/opt/freeradius" directory, it will make one, install itself, and the version of the server in /opt/freeradius WILL WORK.
You can then update the configuration files in /opt/freeradius/etc/raddb to match your local configuration.
And DON'T EDIT THE DICTIONARY FILES.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Radius <radius@kingmanaz.net> wrote:
I re-ran the install as you said below.
I think it's working, I just have to get used to adding /opt/freeradius in the command lines.
Been watching with the radiusd -x and can even run a radtest
Exactly. The problem, as evidenced by your multiple recent emails, is that you weren't sure what you had done, or what you were doing. As a result, your progress was less than speedy. In general, you NEVER upgrade production servers until you've upgraded your testing server, and validated the configuration. You do have a testing server, don't you? Or do you always make updates to your live config, and hope it doesn't break anything?
But now I'm back to the original problem to deny anything with UPPER CASE letters to prevent double billing by our provider.
A recent post explained how to fix this. I suggest going back, and reading all of the messages in this thread. Alan DeKok.
Alan DeKok wrote:
Radius <radius@kingmanaz.net> wrote:
I re-ran the install as you said below.
I think it's working, I just have to get used to adding /opt/freeradius in the command lines.
Been watching with the radiusd -x and can even run a radtest
Exactly. The problem, as evidenced by your multiple recent emails, is that you weren't sure what you had done, or what you were doing. As a result, your progress was less than speedy.
In general, you NEVER upgrade production servers until you've upgraded your testing server, and validated the configuration.
You do have a testing server, don't you? Or do you always make updates to your live config, and hope it doesn't break anything?
But now I'm back to the original problem to deny anything with UPPER CASE letters to prevent double billing by our provider.
A recent post explained how to fix this. I suggest going back, and reading all of the messages in this thread.
The uncomment of the lines under sql.conf and putting the lower_user & lower_pass to "no" did not fix it. It still allows UPPER case logins. I can't mess with mysql. That was installed by me and it worked. Used your mysql import and that's the way it's been for over a year. Never been touched since it's installation. Radius is the only thing that uses the mysql setup. Nothing else does. The only reason I updated was I was told I needed to for this to work or I would have not done it. Last year when I went with FreeRadius was because I was told I needed to. Cistron did not play well with mysql, and I didn't want to be adding all those people to the users file for the chap logins. But this time those errors came up when I went back to a previous install. Other wise I don't do enough changes to our server for a test machine. This is the first time in a year I touched anything on the server at all except to get the realms working back in March. I have mirror backups no older than 24 hours, so I was to a point of putting in the mirror drive in and reboot and have everything back where it was yesterday with the only loss being emails and one days accounting. Very easy to update. Mount the old, move the mail/billing files over. I could have crashed the system and be running again in less than 10 minutes. The servers only do radius/web/email/billing/support backroom. Nothing else. Usually when I get ready to change the kernel installation, I then build a full new server and install it and move things over to it that way after it burns for 6 month's. New machines always break the first 4 month's if they are going to break at all. At the end of two years I pull and replace. These turn in to kids machines. They usually go bad in 6 month's or so. I think I just about figured MTF on the machines. Been doing it this way since the start in 1995. Never had a computer crash. Have had hard drives go bad, but have the mirror backups. I use all the same drives etc. I only have to do that once every couple years when I replace all the servers. Otherwise, I have not changed things that effects system operation. Any programs that I use are stand alone and they don't have anything to do with system operation so if they go wrong it's only the program that goes wrong not my system. They don't run as root. They are a hidden user that does those. Never needs to be root. The ones I write are only for my user billing and back room for our support people to read the different info/radius/billing files for each user and simple web pages but people offer those to me free so it's easy to test those first anyway. Even our signup scripts are 11 years old. Still use the same ones with minor adjustments when things went to shadow passwords. So no never needed a test server in 11 years of doing internet.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Radius <radius@kingmanaz.net> wrote:
A recent post explained how to fix this. I suggest going back, and reading all of the messages in this thread.
The uncomment of the lines under sql.conf and putting the lower_user & lower_pass to "no"
did not fix it.
Because that's not the problem. The problem is that the MySQL queries are case-insensitive, and you don't want that. So you have to do case-insensitive queries in MySQL. Read the MySQL documentation for details. Or, go back and read ALL of the messages in this thread. ALL.
I can't mess with mysql. That was installed by me and it worked. Used your mysql import and that's the way it's been for over a year. Never been touched since it's installation.
You don't have to touch MySQL. One of the reasons you're having so much difficulty solving the problem is that you have a hard time following instructions.
So no never needed a test server in 11 years of doing internet.
You've been either very lucky, or you don't mind losing data, or you don't mind shutting customers out for a time. Alan DeKok.
Before I touch anything of these errors, I'm asking here. This shows up in the logs when radius is started. Mon Jul 4 12:15:33 2005 : Error: rlm_attr_filter: Authorize method will be deprecated. Alan DeKok wrote:
Radius <radius@kingmanaz.net> wrote:
A recent post explained how to fix this. I suggest going back, and reading all of the messages in this thread.
The uncomment of the lines under sql.conf and putting the lower_user & lower_pass to "no"
did not fix it.
Because that's not the problem.
The problem is that the MySQL queries are case-insensitive, and you don't want that. So you have to do case-insensitive queries in MySQL. Read the MySQL documentation for details.
Or, go back and read ALL of the messages in this thread.
ALL.
I can't mess with mysql. That was installed by me and it worked. Used your mysql import and that's the way it's been for over a year. Never been touched since it's installation.
You don't have to touch MySQL.
One of the reasons you're having so much difficulty solving the problem is that you have a hard time following instructions.
So no never needed a test server in 11 years of doing internet.
You've been either very lucky, or you don't mind losing data, or you don't mind shutting customers out for a time.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
I have just found out no chap logins are working since the update to 1.0.4 Here is what they are showing in the radius -x This is only happening with those that are logging in through our wholesale service. Anyone logs in locally with the realm does fine. Some log errors
Warning: Found 2 auth-types on request for user 'rniclh' Any idea what this is about? I seem to be getting this on most of the logins. Even the ones that work.
rlm_unix: Attribute "User-Password" is required for authentication. Cannot use "CHAP-Password". Login incorrect: [rniclh/<CHAP-Password>] (from client usa1 port 228 cli 5208778389) rad_recv: Access-Request packet from host 216.127.146.29:52982, id=50, length=213 User-Name = "rniclh@surftheusa.com"
CHAP-Password = 0x014d582cee62362d9063da8b99c2f83c94
Why is it coming through like this?
NAS-IP-Address = 63.215.26.191 NAS-Port = 228 Service-Type = Framed-User Framed-Protocol = PPP Ascend-Data-Rate = 31200 Ascend-Calling-Id-Type-Of-Num = Unknown Ascend-Calling-Id-Number-Plan = Unknown Ascend-Xmit-Rate = 46667 Called-Station-Id = "5208294055" Calling-Station-Id = "5208778389" NAS-Identifier = "nas8.tcs1.Level3.net" Acct-Session-Id = "436987031" NAS-Port-Type = Async Ascend-NAS-Port-Format = 2_4_5_5 Attr-102 = 0x6c33 rlm_chap: Setting 'Auth-Type := CHAP'
Warning: Found 2 auth-types on request for user 'rniclh'
But when I do it from another system and radtest it seems to work. rad_recv: Access-Request packet from host 64.240.77.3:33574, id=228, length=73 User-Name = "rniclh@surftheusa.com" User-Password = "deleted" NAS-IP-Address = 255.255.255.255 NAS-Port = 500 rlm_sql (sql): Reserving sql socket id: 4
Now it's something different. But it's not telling me where it's at. I checked the users file and they are all == The attrs have some that have =* in them. The log files and the radiusd -xx are not telling me enough where to look or what to look for. Sending Access-Accept of id 87 to 64.240.76.5:1645 Slipstream-Auth = "false" Service-Type = Framed-User Framed-IP-Address = 255.255.255.254 Framed-MTU = 1500 Framed-Protocol = PPP Framed-Compression = Van-Jacobson-TCP-IP rad_recv: Accounting-Request packet from host 64.240.76.5:1645, id=88, length=209 Acct-Session-Id = "040000c5" User-Name = " kj20" NAS-IP-Address = 64.240.76.5 NAS-Port = 17 Acct-Status-Type = Start Acct-Authentic = RADIUS USR-Connect-Speed = 46666-BPS USR-Modulation-Type = v90Analog USR-Simplified-MNP-Levels = v42Etc2 USR-Simplified-V42bis-Usage = none USR-Chassis-Call-Slot = 0 USR-Chassis-Call-Span = 0 USR-Chassis-Call-Channel = 12 USR-Unauthenticated-Time = 25 NAS-Identifier = "ras1" NAS-Port-Type = Async Service-Type = Framed-User Framed-Protocol = PPP Framed-IP-Address = 64.240.76.45 Acct-Delay-Time = 0 Invalid operator for item Suffix: reverting to '==' Invalid operator for item Suffix: reverting to '==' Invalid operator for item Suffix: reverting to '==' Invalid operator for item Suffix: reverting to '==' Invalid operator for item Suffix: reverting to '==' Invalid operator for item Suffix: reverting to '==' Invalid operator for item Suffix: reverting to '==' Sending Accounting-Response of id 88 to 64.240.76.5:1645
These warnings also after what I posted below. rlm_acct_unique: WARNING: Attribute NAS-Port-Id was not found in request, unique ID MAY be inconsistent Radius wrote:
Now it's something different. But it's not telling me where it's at. I checked the users file and they are all ==
The attrs have some that have =* in them.
The log files and the radiusd -xx are not telling me enough where to look or what to look for.
Sending Access-Accept of id 87 to 64.240.76.5:1645 Slipstream-Auth = "false" Service-Type = Framed-User Framed-IP-Address = 255.255.255.254 Framed-MTU = 1500 Framed-Protocol = PPP Framed-Compression = Van-Jacobson-TCP-IP rad_recv: Accounting-Request packet from host 64.240.76.5:1645, id=88, length=209 Acct-Session-Id = "040000c5" User-Name = " kj20" NAS-IP-Address = 64.240.76.5 NAS-Port = 17 Acct-Status-Type = Start Acct-Authentic = RADIUS USR-Connect-Speed = 46666-BPS USR-Modulation-Type = v90Analog USR-Simplified-MNP-Levels = v42Etc2 USR-Simplified-V42bis-Usage = none USR-Chassis-Call-Slot = 0 USR-Chassis-Call-Span = 0 USR-Chassis-Call-Channel = 12 USR-Unauthenticated-Time = 25 NAS-Identifier = "ras1" NAS-Port-Type = Async Service-Type = Framed-User Framed-Protocol = PPP Framed-IP-Address = 64.240.76.45 Acct-Delay-Time = 0 Invalid operator for item Suffix: reverting to '==' Invalid operator for item Suffix: reverting to '==' Invalid operator for item Suffix: reverting to '==' Invalid operator for item Suffix: reverting to '==' Invalid operator for item Suffix: reverting to '==' Invalid operator for item Suffix: reverting to '==' Invalid operator for item Suffix: reverting to '==' Sending Accounting-Response of id 88 to 64.240.76.5:1645
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
radius@kingmanaz.net wrote:
Now it's something different. But it's not telling me where it's at. I checked the users file and they are all ==
The attrs have some that have =* in them.
The log files and the radiusd -xx are not telling me enough where to look or what to look for.
[...]
Invalid operator for item Suffix: reverting to '==' Invalid operator for item Suffix: reverting to '==' Invalid operator for item Suffix: reverting to '==' Invalid operator for item Suffix: reverting to '==' Invalid operator for item Suffix: reverting to '==' Invalid operator for item Suffix: reverting to '==' Invalid operator for item Suffix: reverting to '=='
Check the file raddb/hints. -- Nicolas Baradakis
It would seem it's still reading the old dictionary file from 0.93 radclient: dict_init: /usr/local/freeradius-9.3/share/freeradius/dictionary.acc[110]: dict_addvalue: Duplicate value name Administrative-reset for attribute Acc-Reason-Code This happened when I tried to run radzap to remove an entry of someone not on-line. /opt/freeradius/bin/radzap -N 63.215.26.209 S19525 ragers@kingmanaz.net It still seems to be reading the old files. Alan DeKok wrote:
Radius <radius@kingmanaz.net> wrote:
I re-ran the install as you said below.
I think it's working, I just have to get used to adding /opt/freeradius in the command lines.
Been watching with the radiusd -x and can even run a radtest
Exactly. The problem, as evidenced by your multiple recent emails, is that you weren't sure what you had done, or what you were doing. As a result, your progress was less than speedy.
In general, you NEVER upgrade production servers until you've upgraded your testing server, and validated the configuration.
You do have a testing server, don't you? Or do you always make updates to your live config, and hope it doesn't break anything?
But now I'm back to the original problem to deny anything with UPPER CASE letters to prevent double billing by our provider.
A recent post explained how to fix this. I suggest going back, and reading all of the messages in this thread.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Some log in errors
Warning: Found 2 auth-types on request for user 'rniclh' Any idea what this is about? I seem to be getting this on most of the logins. Even the ones that work.
rlm_unix: Attribute "User-Password" is required for authentication. Cannot use "CHAP-Password". Login incorrect: [rniclh/<CHAP-Password>] (from client usa1 port 228 cli 5208778389) rad_recv: Access-Request packet from host 216.127.146.29:52982, id=50, length=213 User-Name = "rniclh@surftheusa.com"
CHAP-Password = 0x014d582cee62362d9063da8b99c2f83c94
Why is it coming through like this?
NAS-IP-Address = 63.215.26.191 NAS-Port = 228 Service-Type = Framed-User Framed-Protocol = PPP Ascend-Data-Rate = 31200 Ascend-Calling-Id-Type-Of-Num = Unknown Ascend-Calling-Id-Number-Plan = Unknown Ascend-Xmit-Rate = 46667 Called-Station-Id = "5208294055" Calling-Station-Id = "5208778389" NAS-Identifier = "nas8.tcs1.Level3.net" Acct-Session-Id = "436987031" NAS-Port-Type = Async Ascend-NAS-Port-Format = 2_4_5_5 Attr-102 = 0x6c33 rlm_chap: Setting 'Auth-Type := CHAP'
Warning: Found 2 auth-types on request for user 'rniclh'
But when I do it from another system and radtest it seems to work. rad_recv: Access-Request packet from host 64.240.77.3:33574, id=228, length=73 User-Name = "rniclh@surftheusa.com" User-Password = "deleted" NAS-IP-Address = 255.255.255.255 NAS-Port = 500 rlm_sql (sql): Reserving sql socket id: 4 Alan DeKok wrote:
Radius <radius@kingmanaz.net> wrote:
I re-ran the install as you said below.
I think it's working, I just have to get used to adding /opt/freeradius in the command lines.
Been watching with the radiusd -x and can even run a radtest
Exactly. The problem, as evidenced by your multiple recent emails, is that you weren't sure what you had done, or what you were doing. As a result, your progress was less than speedy.
In general, you NEVER upgrade production servers until you've upgraded your testing server, and validated the configuration.
You do have a testing server, don't you? Or do you always make updates to your live config, and hope it doesn't break anything?
But now I'm back to the original problem to deny anything with UPPER CASE letters to prevent double billing by our provider.
A recent post explained how to fix this. I suggest going back, and reading all of the messages in this thread.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Alan DeKok wrote:
Radius <radius@kingmanaz.net> wrote:
After updated to 1.04 and making the changes again what you recommend below and when I try to run radtest I get all kinds of these dup error.
radclient: dict_init: /usr/local/radius/share/freeradius/dictionary.acc[110]: dict_addvalue: Duplicate value name Administrative-reset for attribute Acc-Reason-Code
You need to point /etc/raddb/dictionary to the new 1.0.4 dictionaries.q
See raddb/dictionary in the 1.0.4 source distribution.
it says in there that they are at /usr/local/share/freeradius/ and they are there. I did the default installation. When I edit and delete the dups, it just keeps going one file after the other. I'll have to pull 0.93 from an old backup. This seems to be getting worse as I try to make adjustments.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Well, actually it was ver 1.01 But after loading the backup, I now get the same errors. Well, I guess I just hosed a production server now. It was all working fine before I tried to make the update. That will teach me to fix something not broke. Radius wrote:
Alan DeKok wrote:
Radius <radius@kingmanaz.net> wrote:
After updated to 1.04 and making the changes again what you recommend below and when I try to run radtest I get all kinds of these dup error.
radclient: dict_init: /usr/local/radius/share/freeradius/dictionary.acc[110]: dict_addvalue: Duplicate value name Administrative-reset for attribute Acc-Reason-Code
You need to point /etc/raddb/dictionary to the new 1.0.4 dictionaries.q
See raddb/dictionary in the 1.0.4 source distribution.
it says in there that they are at /usr/local/share/freeradius/
and they are there. I did the default installation.
When I edit and delete the dups, it just keeps going one file after the other.
I'll have to pull 0.93 from an old backup. This seems to be getting worse as I try to make adjustments.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
I did get back to 0.93 but I still get the same errors with a local radtest. But at least people can log in and get authenticated. Why did they have to mess with directories. It was working fine where they had it, now this system is totally hosed because I can find what else they embedded in the system. I just replaced all the /usr/local & /etc directories from the back up and that crazy error is still there. It's saying radtest can't read the radiusd.conf file. Alan DeKok wrote:
Radius <radius@kingmanaz.net> wrote:
After updated to 1.04 and making the changes again what you recommend below and when I try to run radtest I get all kinds of these dup error.
radclient: dict_init: /usr/local/radius/share/freeradius/dictionary.acc[110]: dict_addvalue: Duplicate value name Administrative-reset for attribute Acc-Reason-Code
You need to point /etc/raddb/dictionary to the new 1.0.4 dictionaries.q
See raddb/dictionary in the 1.0.4 source distribution.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (5)
-
Alan DeKok -
Nick Marino -
Nicolas Baradakis -
Paul.Hampson＠PObox.com -
Radius