Freeradius not always denying invalid users
We've been running Freeradius for a long time without any issues. We typically turn a customer off by changing the password in the passwd file. We use the passwd file for authentication. The issue is intermittent the customer is DSL so they will try to log in for a couple of hours constantly before being allowed to connect. Once the connect reseting their dsl connection forces them to login again. It will fail at this point, like it's supposed to. First before I get into posting any configs or that detail, has anyone else had similar problems? Also, the logs sometimes show invalid shell with part of the passwd file. Not necessarily the actual shell portion though. It may show the home directory, or the shell, or even part of one of those such as "/bin/fal" -- Chris Moss
Chris Moss wrote:
We've been running Freeradius for a long time without any issues. We typically turn a customer off by changing the password in the passwd file. We use the passwd file for authentication. The issue is intermittent the customer is DSL so they will try to log in for a couple of hours constantly before being allowed to connect.
What does that mean? You turn a customer off, and then they keep trying to log in before they are allowed to connect?
Once the connect reseting their dsl connection forces them to login again. It will fail at this point, like it's supposed to. First before I get into posting any configs or that detail, has anyone else had similar problems?
I don't think I understand the question.
Also, the logs sometimes show invalid shell with part of the passwd file. Not necessarily the actual shell portion though. It may show the home directory, or the shell, or even part of one of those such as "/bin/fal"
The logs sometimes show something about stuff... Can you post portions of the logs? That would seem to be more useful than vague descriptions. Alan DeKok.
Here is an example of a user who is turned off. This shows the invalid shell where it pulls out part of the passwd entry of another user. Note the username in this is all the same user. Wed Sep 3 08:33:34 2008 : Auth: rlm_unix: [username]: invalid password Wed Sep 3 08:33:34 2008 : Auth: Login incorrect: [username@vci.net/0844] (from client xx.xx.xx.xx port 3841982499 cli mdvi11100400714) Wed Sep 3 08:33:48 2008 : Auth: rlm_unix: [username]: invalid shell [*one Oak United Methodist:/home/loumc:/bin/false* Wed Sep 3 08:33:48 2008 : Auth: Login incorrect: [username@vci.net/0844] (from client xx.xx.xx.xx port 3841982499 cli mdvi11100400714) Chris Moss VCI Internet and Telephone 523 South 3rd St Paducah, Ky 42003 Tel (270)442-0060 Fax (270)444-6734 1-800-755-1239 M-Th 8am - 8pm Fri 8am - 7pm Sat 9am - 4pm Alan DeKok wrote:
Chris Moss wrote:
We've been running Freeradius for a long time without any issues. We typically turn a customer off by changing the password in the passwd file. We use the passwd file for authentication. The issue is intermittent the customer is DSL so they will try to log in for a couple of hours constantly before being allowed to connect.
What does that mean? You turn a customer off, and then they keep trying to log in before they are allowed to connect?
Once the connect reseting their dsl connection forces them to login again. It will fail at this point, like it's supposed to. First before I get into posting any configs or that detail, has anyone else had similar problems?
I don't think I understand the question.
Also, the logs sometimes show invalid shell with part of the passwd file. Not necessarily the actual shell portion though. It may show the home directory, or the shell, or even part of one of those such as "/bin/fal"
The logs sometimes show something about stuff...
Can you post portions of the logs? That would seem to be more useful than vague descriptions.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
.
Chris Moss wrote:
Here is an example of a user who is turned off. This shows the invalid shell where it pulls out part of the passwd entry of another user. Note the username in this is all the same user.
Wed Sep 3 08:33:34 2008 : Auth: rlm_unix: [username]: invalid password
The server just does system calls to get the password from /etc/passwd. If that says the user's password is incorrect, it's incorrect. No amount of poking the server will change that.
Wed Sep 3 08:33:48 2008 : Auth: rlm_unix: [username]: invalid shell [*one Oak United Methodist:/home/loumc:/bin/false*
The server just does a system call to get the user's shell, and validate that against the list of valid shells. If that says the shell is invalid, there's little the server can do. i.e. the server is relying on the OS and libraries to get information from the password file. "one Oak United.." is obviously not the correct user shell. So I'd say there's something wrong with your local system. *Unless*, of course you're using an old version of the server, and have configured it to read /etc/passwd itself. This isn't recommended even in old versions of the server. So... don't enable caching in the "unix" module. Alan DeKok.
We are running version 1.1.3. We do have thousands of users in the passwd file, could that have something to do with it? Is there a way to tell the radius server that if it can't authenticate to deny it. I'm wondering if the OS itself is getting overloaded causing this. Chris Moss Alan DeKok wrote:
Chris Moss wrote:
Here is an example of a user who is turned off. This shows the invalid shell where it pulls out part of the passwd entry of another user. Note the username in this is all the same user.
Wed Sep 3 08:33:34 2008 : Auth: rlm_unix: [username]: invalid password
The server just does system calls to get the password from /etc/passwd. If that says the user's password is incorrect, it's incorrect. No amount of poking the server will change that.
Wed Sep 3 08:33:48 2008 : Auth: rlm_unix: [username]: invalid shell [*one Oak United Methodist:/home/loumc:/bin/false*
The server just does a system call to get the user's shell, and validate that against the list of valid shells. If that says the shell is invalid, there's little the server can do.
i.e. the server is relying on the OS and libraries to get information from the password file. "one Oak United.." is obviously not the correct user shell. So I'd say there's something wrong with your local system.
*Unless*, of course you're using an old version of the server, and have configured it to read /etc/passwd itself. This isn't recommended even in old versions of the server. So... don't enable caching in the "unix" module.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
.
Is there a way to tell the radius server that if it can't authenticate to deny it.
The user attempt with "invalid" shell was rejected: Wed Sep 3 08:33:48 2008 : Auth: rlm_unix: [username]: invalid shell [*one Oak United Methodist:/home/loumc:/bin/false* Wed Sep 3 08:33:48 2008 : Auth: Login incorrect: <<=== see! [username@vci.net/0844] (from client xx.xx.xx.xx port 3841982499 cli mdvi11100400714) Ivan Kalik Kalik Informatika ISP
Chris Moss wrote:
We are running version 1.1.3. We do have thousands of users in the passwd file, could that have something to do with it?
Maybe. Did you enable "cache" in the "unix" module? If so, have you disabled it?
Is there a way to tell the radius server that if it can't authenticate to deny it.
Huh? If the server can't authenticate the user, it denies the user. Always.
I'm wondering if the OS itself is getting overloaded causing this.
No. Alan DeKok.
No, cache was not enabled. Just a thought on the denying, I thought maybe it just couldn't get a good result one way or the other so it would just allow it. Any other thoughts on would could be causing this issue? Like I said this only seems to be happening on dsl customers that constantly try to connect. Is there any other logs, configs, etc that would be of any help? I will try to get a debug of one that doesn't behave properly. Is there a way to make that debug log to the log file. So far it only outputs to terminal and it's very hard to capture it there, it it's in a log I should be able to get something worthwhile. Chris Moss Alan DeKok wrote:
Chris Moss wrote:
We are running version 1.1.3. We do have thousands of users in the passwd file, could that have something to do with it?
Maybe. Did you enable "cache" in the "unix" module? If so, have you disabled it?
Is there a way to tell the radius server that if it can't authenticate to deny it.
Huh? If the server can't authenticate the user, it denies the user. Always.
I'm wondering if the OS itself is getting overloaded causing this.
No.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
.
Chris Moss wrote:
No, cache was not enabled.
Then your OS is buggy.
Just a thought on the denying, I thought maybe it just couldn't get a good result one way or the other so it would just allow it.
Absolutely not.
Any other thoughts on would could be causing this issue?
As I said, your OS.
Like I said this only seems to be happening on dsl customers that constantly try to connect. Is there any other logs, configs, etc that would be of any help? I will try to get a debug of one that doesn't behave properly. Is there a way to make that debug log to the log file. So far it only outputs to terminal and it's very hard to capture it there, it it's in a log I should be able to get something worthwhile.
Debugging the server is a waste of time. Your OS is buggy. Alan DeKok.
Thanks for all the help on this. I finally just added those 2-3 users to the users file with REJECT. I did notice that anytime it would allow them to connect there was a simultaneous attempt from another user at the exact time. That doesn't happen very often so it must have something to do with those customer constantly trying to login and finally hitting at the same time caused some sort of bug. Chris Moss VCI Internet and Telephone 523 South 3rd St Paducah, Ky 42003 Tel (270)442-0060 Fax (270)444-6734 1-800-755-1239 M-Th 8am - 8pm Fri 8am - 7pm Sat 9am - 4pm Alan DeKok wrote:
Chris Moss wrote:
No, cache was not enabled.
Then your OS is buggy.
Just a thought on the denying, I thought maybe it just couldn't get a good result one way or the other so it would just allow it.
Absolutely not.
Any other thoughts on would could be causing this issue?
As I said, your OS.
Like I said this only seems to be happening on dsl customers that constantly try to connect. Is there any other logs, configs, etc that would be of any help? I will try to get a debug of one that doesn't behave properly. Is there a way to make that debug log to the log file. So far it only outputs to terminal and it's very hard to capture it there, it it's in a log I should be able to get something worthwhile.
Debugging the server is a waste of time. Your OS is buggy.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
.
They are most likely still rejected by freeradius but your NAS lets them in. Debug NAS and see why is that happening. Ivan Kalik Kalik Informatika ISP Dana 8/9/2008, "Chris Moss" <cmoss28@vci.net> piše:
Thanks for all the help on this. I finally just added those 2-3 users to the users file with REJECT. I did notice that anytime it would allow them to connect there was a simultaneous attempt from another user at the exact time. That doesn't happen very often so it must have something to do with those customer constantly trying to login and finally hitting at the same time caused some sort of bug.
Chris Moss VCI Internet and Telephone 523 South 3rd St Paducah, Ky 42003 Tel (270)442-0060 Fax (270)444-6734 1-800-755-1239 M-Th 8am - 8pm Fri 8am - 7pm Sat 9am - 4pm
Alan DeKok wrote:
Chris Moss wrote:
No, cache was not enabled.
Then your OS is buggy.
Just a thought on the denying, I thought maybe it just couldn't get a good result one way or the other so it would just allow it.
Absolutely not.
Any other thoughts on would could be causing this issue?
As I said, your OS.
Like I said this only seems to be happening on dsl customers that constantly try to connect. Is there any other logs, configs, etc that would be of any help? I will try to get a debug of one that doesn't behave properly. Is there a way to make that debug log to the log file. So far it only outputs to terminal and it's very hard to capture it there, it it's in a log I should be able to get something worthwhile.
Debugging the server is a waste of time. Your OS is buggy.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
.
Here is a debug of when it works: rad_recv: Access-Request packet from host XXX.XXX.XXX.X:1812, id=113, length=100 User-Name = "username@domain" User-Password = "0844" NAS-Identifier = "redback" Calling-Station-Id = "mdvi11100400714" Service-Type = Framed-User Framed-Protocol = PPP NAS-Port = 3841982477 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 47 modcall[authorize]: module "preprocess" returns ok for request 47 modcall[authorize]: module "chap" returns noop for request 47 modcall[authorize]: module "mschap" returns noop for request 47 rlm_realm: Looking up realm "domain" for User-Name = "username@domain" rlm_realm: Found realm "domain" rlm_realm: Adding Stripped-User-Name = "username" rlm_realm: Proxying request from user username to realm domain rlm_realm: Adding Realm = "domain" rlm_realm: Authentication realm is LOCAL. modcall[authorize]: module "suffix" returns noop for request 47 users: Matched entry DEFAULT at line 247 modcall[authorize]: module "files" returns ok for request 47 modcall: leaving group authorize (returns ok) for request 47 rad_check_password: Found Auth-Type System auth: type "System" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 47 rlm_unix: [username]: invalid password modcall[authenticate]: module "unix" returns reject for request 47 modcall: leaving group authenticate (returns reject) for request 47 auth: Failed to validate the user. Login incorrect: [username@domain/0844] (from client XXX.XXX.XXX.XXX port 3841982477 cli mdvi11100400714) Delaying request 47 for 3 seconds Finished request 47 Chris Moss Chris Moss wrote:
We've been running Freeradius for a long time without any issues. We typically turn a customer off by changing the password in the passwd file. We use the passwd file for authentication. The issue is intermittent the customer is DSL so they will try to log in for a couple of hours constantly before being allowed to connect. Once the connect reseting their dsl connection forces them to login again. It will fail at this point, like it's supposed to. First before I get into posting any configs or that detail, has anyone else had similar problems?
Also, the logs sometimes show invalid shell with part of the passwd file. Not necessarily the actual shell portion though. It may show the home directory, or the shell, or even part of one of those such as "/bin/fal"
participants (3)
-
Alan DeKok -
Chris Moss -
tnt＠kalik.net