Blank Password Problem
Guys, I'm experiencing a strange problem. I use FreeRadius to control cmd line access to my routers and switches and I've configured FreeRadius to use a MySQL back-end and thus far it works fine except for one condition. If i supply a blank password when authenticating, FreeRadius allows the request and authenticates me once my username is correct. Why is this happening? Is there any way to have FreeRadius keep on prompting if a blank password is supplied or reject the request altogether? Thanks for your help. Radius debug is below: Ready to process requests. rad_recv: Access-Request packet from host 192.168.1.1 port 1645, id=215, length=104 User-Name = "john.doe" Reply-Message = "Password: " User-Password = "" NAS-Port = 1 NAS-Port-Id = "tty1" NAS-Port-Type = Virtual Calling-Station-Id = "192.168.1.1" NAS-IP-Address = 192.168.1.1 +- entering group authorize ++[preprocess] returns ok rlm_sql (sql): - sql_xlat expand: %{User-Name} -> john.doe rlm_sql (sql): sql_set_user escaped user --> 'john.doe' expand: SELECT groupname FROM radhuntgroup WHERE nasipaddress="%{NAS-IP-Address}" AND nasportid LIKE IF (SUBSTRING("%{NAS-Port-Id}", 1, 3) = 'tty', 'tty', "%{NAS-Port-Id}") AND usergroup IN (SELECT groupname FROM radusergroup where username LIKE "%{User-Name}") -> SELECT groupname FROM radhuntgroup WHERE nasipaddress="192.168.1.1" AND nasportid LIKE IF (SUBSTRING("tty1", 1, 3) = 'tty', 'tty', "tty1") AND usergroup IN (SELECT groupname FROM radusergroup where username LIKE "john.doe") rlm_sql (sql): Reserving sql socket id: 3 rlm_sql (sql): - sql_xlat finished rlm_sql (sql): Released sql socket id: 3 expand: %{sql:SELECT groupname FROM radhuntgroup WHERE nasipaddress="%{NAS-IP-Address}" AND nasportid LIKE IF (SUBSTRING("%{NAS-Port-Id}", 1, 3) = 'tty', 'tty', "%{NAS-Port-Id}") AND usergroup IN (SELECT groupname FROM radusergroup where username LIKE "%{User-Name}") } -> admin ++[request] returns ok ++[chap] returns noop ++[mschap] returns noop rlm_realm: No '@' in User-Name = "john.doe", looking up realm NULL rlm_realm: No such realm "NULL" ++[suffix] returns noop rlm_eap: No EAP-Message, not doing EAP ++[eap] returns noop ++[unix] returns notfound users: Matched entry DEFAULT at line 204 ++[files] returns ok expand: %{User-Name} -> john.doe rlm_sql (sql): sql_set_user escaped user --> 'john.doe' rlm_sql (sql): Reserving sql socket id: 2 expand: SELECT id, username, attribute, value, op FROM radcheck WHERE username = '%{SQL-User-Name}' ORDER BY id -> SELECT id, username, attribute, value, op FROM radcheck WHERE username = 'john.doe' ORDER BY id rlm_sql (sql): User found in radcheck table expand: SELECT id, username, attribute, value, op FROM radreply WHERE username = '%{SQL-User-Name}' ORDER BY id -> SELECT id, username, attribute, value, op FROM radreply WHERE username = 'john.doe' ORDER BY id expand: SELECT groupname FROM radusergroup WHERE username = '%{SQL-User-Name}' ORDER BY priority -> SELECT groupname FROM radusergroup WHERE username = 'john.doe' ORDER BY priority expand: SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = '%{Sql-Group}' ORDER BY id -> SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = 'engineeringadmin' ORDER BY id rlm_sql (sql): User found in group engineeringadmin expand: SELECT id, groupname, attribute, value, op FROM radgroupreply WHERE groupname = '%{Sql-Group}' ORDER BY id -> SELECT id, groupname, attribute, value, op FROM radgroupreply WHERE groupname = 'engineeringadmin' ORDER BY id rlm_sql (sql): Released sql socket id: 2 ++[sql] returns ok ++[expiration] returns noop ++[logintime] returns noop rlm_pap: Normalizing SHA-Password from hex encoding rlm_pap: Found existing Auth-Type, not changing it. ++[pap] returns noop rad_check_password: Found Auth-Type Accept rad_check_password: Auth-Type = Accept, accepting the user Login OK: [john.doe] (from client routerA port 1 cli 192.168.1.1) +- entering group post-auth ++[exec] returns noop Sending Access-Accept of id 215 to 192.168.1.1 port 1645 Service-Type := Administrative-User Cisco-AVPair := "shell:priv-lvl=15" Finished request 0. Going to the next request Waking up in 4.9 seconds. Cleaning up request 0 ID 215 with timestamp +9 Ready to process requests.
Hi,
users: Matched entry DEFAULT at line 204 ++[files] returns ok
whats on line 204 or your users file? the reason why I ask is because......
rlm_pap: Found existing Auth-Type, not changing it. ++[pap] returns noop rad_check_password: Found Auth-Type Accept rad_check_password: Auth-Type = Accept, accepting the user Login OK: [john.doe] (from client routerA port 1 cli 192.168.1.1)
see that? the system has been told that the Auth-Type is Accept. the only place it picked that yup from is the users file. alan
Line 204 in my users file is the following: DEFAULT Auth-Type := Reject My MySQL databse also stores huntgroup information for the FreeRadius server. I want to reject authentication by default on all my nas devices unless the usergroup which the user belongs to is allowed to access that huntgroup. I've basically followed this guide: http://wiki.freeradius.org/SQL_Huntgroup_HOWTO my radhuntgroup config: +----+-----------+----------------+----------------+------------------+ | id | groupname | nasipaddress | nasportid | usergroup | +----+-----------+----------------+----------------+------------------+ | 1 | admin | 192.168.1.1 | tty | engineeringadmin | my radgroupcheck config: +----+------------------+----------------+----+----------------+ | id | groupname | attribute | op | value | +----+------------------+----------------+----+----------------+ | 5 | engineeringadmin | Huntgroup-Name | == | admin | | 6 | engineeringadmin | Auth-Type | := | Accept | On Thu, Jan 21, 2010 at 6:21 PM, Alan Buxey <A.L.M.Buxey@lboro.ac.uk> wrote:
Hi,
users: Matched entry DEFAULT at line 204 ++[files] returns ok
whats on line 204 or your users file? the reason why I ask is because......
rlm_pap: Found existing Auth-Type, not changing it. ++[pap] returns noop rad_check_password: Found Auth-Type Accept rad_check_password: Auth-Type = Accept, accepting the user Login OK: [john.doe] (from client routerA port 1 cli 192.168.1.1)
see that? the system has been told that the Auth-Type is Accept. the only place it picked that yup from is the users file.
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Satyam Mathura <satz.sm@gmail.com> writes:
Line 204 in my users file is the following: DEFAULT Auth-Type := Reject
You don't want that. It removes the server's ability to figure it out by itself.
my radgroupcheck config: +----+------------------+----------------+----+----------------+ | id | groupname | attribute | op | value | +----+------------------+----------------+----+----------------+ | 5 | engineeringadmin | Huntgroup-Name | == | admin | | 6 | engineeringadmin | Auth-Type | := | Accept |
Why? This will make the server act as you describe: Any username in the engineeringadmin group will be accepted regardless of password. Bjørn
The reason i had those configs was because they were outlined as steps to reject authentication by default in the guide i was using. http://wiki.freeradius.org/SQL_Huntgroup_HOWTO "Note: If you want to reject authentication by default then edit the raddb/users file and add this: DEFAULT Auth-Type := Reject Then add Auth-Type Accept with := as op in radgroupcheck for each group" I've commented out the DEFAULT Auth-Type := Reject in the users file and removed the Auth-Type := Accept from the radgroupcheck table and the server no longer accepts a blank password. Guide is incorrect or needs updating? Thanks for the help guys. On Thu, Jan 21, 2010 at 6:58 PM, Bjørn Mork <bjorn@mork.no> wrote:
Satyam Mathura <satz.sm@gmail.com> writes:
Line 204 in my users file is the following: DEFAULT Auth-Type := Reject
You don't want that. It removes the server's ability to figure it out by itself.
my radgroupcheck config: +----+------------------+----------------+----+----------------+ | id | groupname | attribute | op | value | +----+------------------+----------------+----+----------------+ | 5 | engineeringadmin | Huntgroup-Name | == | admin | | 6 | engineeringadmin | Auth-Type | := | Accept |
Why? This will make the server act as you describe: Any username in the engineeringadmin group will be accepted regardless of password.
Bjørn
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Quick update. Although the radius server no longer accepts blank passwords, i now have a problem where users who belong to groups which are not allowed to access nas devices in certain huntgroups can now do so. Any ideas? On Thu, Jan 21, 2010 at 7:14 PM, Satyam Mathura <satz.sm@gmail.com> wrote:
The reason i had those configs was because they were outlined as steps to reject authentication by default in the guide i was using.
http://wiki.freeradius.org/SQL_Huntgroup_HOWTO
"Note: If you want to reject authentication by default then edit the raddb/users file and add this:
DEFAULT Auth-Type := Reject
Then add Auth-Type Accept with := as op in radgroupcheck for each group"
I've commented out the DEFAULT Auth-Type := Reject in the users file
and removed the Auth-Type := Accept from the radgroupcheck table and the server no longer accepts a blank password.
Guide is incorrect or needs updating?
Thanks for the help guys.
On Thu, Jan 21, 2010 at 6:58 PM, Bjørn Mork <bjorn@mork.no> wrote:
Satyam Mathura <satz.sm@gmail.com> writes:
Line 204 in my users file is the following: DEFAULT Auth-Type := Reject
You don't want that. It removes the server's ability to figure it out by itself.
my radgroupcheck config: +----+------------------+----------------+----+----------------+ | id | groupname | attribute | op | value | +----+------------------+----------------+----+----------------+ | 5 | engineeringadmin | Huntgroup-Name | == | admin | | 6 | engineeringadmin | Auth-Type | := | Accept |
Why? This will make the server act as you describe: Any username in the engineeringadmin group will be accepted regardless of password.
Bjørn
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
OK i'm back to my original question. How do i get FreeRadius working with a MySQL back-end to do the following: a. Reject a user if that user is in a group which is not allowed to access devices in a specific huntgroup. b. Allow a user if that user is in the appropriate group which is allowed to access devices in a specific huntgroup. c. Do not allow blank passwords for users. As stated before my huntgroup & radgroupcheck configs look like my radhuntgroup config: +----+-----------+------------ ----+----------------+------------------+ | id | groupname | nasipaddress | nasportid | usergroup | +----+-----------+----------------+----------------+------------------+ | 1 | admin | 192.168.1.1 | tty | engineeringadmin | my radgroupcheck config: +----+------------------+----------------+----+----------------+ | id | groupname | attribute | op | value | +----+------------------+----------------+----+----------------+ | 5 | engineeringadmin | Huntgroup-Name | == | admin | | 6 | engineeringadmin | Auth-Type | := | Accept | Based on the help of previous posters, Rule 6 in radgroupcheck allows users to access a nas once their username is correct even if they supply a blank password. There must be a way around this. What am i doing wrong? On Thu, Jan 21, 2010 at 7:28 PM, Satyam Mathura <satz.sm@gmail.com> wrote:
Quick update. Although the radius server no longer accepts blank passwords, i now have a problem where users who belong to groups which are not allowed to access nas devices in certain huntgroups can now do so. Any ideas?
On Thu, Jan 21, 2010 at 7:14 PM, Satyam Mathura <satz.sm@gmail.com> wrote:
The reason i had those configs was because they were outlined as steps to reject authentication by default in the guide i was using.
http://wiki.freeradius.org/SQL_Huntgroup_HOWTO
"Note: If you want to reject authentication by default then edit the raddb/users file and add this:
DEFAULT Auth-Type := Reject
Then add Auth-Type Accept with := as op in radgroupcheck for each group"
I've commented out the DEFAULT Auth-Type := Reject in the users file
and removed the Auth-Type := Accept from the radgroupcheck table and the server no longer accepts a blank password.
Guide is incorrect or needs updating?
Thanks for the help guys.
On Thu, Jan 21, 2010 at 6:58 PM, Bjørn Mork <bjorn@mork.no> wrote:
Satyam Mathura <satz.sm@gmail.com> writes:
Line 204 in my users file is the following: DEFAULT Auth-Type := Reject
You don't want that. It removes the server's ability to figure it out by itself.
my radgroupcheck config: +----+------------------+----------------+----+----------------+ | id | groupname | attribute | op | value | +----+------------------+----------------+----+----------------+ | 5 | engineeringadmin | Huntgroup-Name | == | admin | | 6 | engineeringadmin | Auth-Type | := | Accept |
Why? This will make the server act as you describe: Any username in the engineeringadmin group will be accepted regardless of password.
Bjørn
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
a little help here guys??? On Fri, Jan 22, 2010 at 9:58 AM, Satyam Mathura <satz.sm@gmail.com> wrote:
OK i'm back to my original question. How do i get FreeRadius working with a MySQL back-end to do the following: a. Reject a user if that user is in a group which is not allowed to access devices in a specific huntgroup. b. Allow a user if that user is in the appropriate group which is allowed to access devices in a specific huntgroup. c. Do not allow blank passwords for users.
As stated before my huntgroup & radgroupcheck configs look like
my radhuntgroup config: +----+-----------+------------ ----+----------------+------------------+ | id | groupname | nasipaddress | nasportid | usergroup | +----+-----------+----------------+----------------+------------------+ | 1 | admin | 192.168.1.1 | tty | engineeringadmin |
my radgroupcheck config: +----+------------------+----------------+----+----------------+ | id | groupname | attribute | op | value | +----+------------------+----------------+----+----------------+ | 5 | engineeringadmin | Huntgroup-Name | == | admin | | 6 | engineeringadmin | Auth-Type | := | Accept |
Based on the help of previous posters, Rule 6 in radgroupcheck allows users to access a nas once their username is correct even if they supply a blank password. There must be a way around this. What am i doing wrong?
On Thu, Jan 21, 2010 at 7:28 PM, Satyam Mathura <satz.sm@gmail.com> wrote:
Quick update. Although the radius server no longer accepts blank passwords, i now have a problem where users who belong to groups which are not allowed to access nas devices in certain huntgroups can now do so. Any ideas?
On Thu, Jan 21, 2010 at 7:14 PM, Satyam Mathura <satz.sm@gmail.com>wrote:
The reason i had those configs was because they were outlined as steps to reject authentication by default in the guide i was using.
http://wiki.freeradius.org/SQL_Huntgroup_HOWTO
"Note: If you want to reject authentication by default then edit the raddb/users file and add this:
DEFAULT Auth-Type := Reject
Then add Auth-Type Accept with := as op in radgroupcheck for each group"
I've commented out the DEFAULT Auth-Type := Reject in the users file
and removed the Auth-Type := Accept from the radgroupcheck table and the server no longer accepts a blank password.
Guide is incorrect or needs updating?
Thanks for the help guys.
On Thu, Jan 21, 2010 at 6:58 PM, Bjørn Mork <bjorn@mork.no> wrote:
Satyam Mathura <satz.sm@gmail.com> writes:
Line 204 in my users file is the following: DEFAULT Auth-Type := Reject
You don't want that. It removes the server's ability to figure it out by itself.
my radgroupcheck config: +----+------------------+----------------+----+----------------+ | id | groupname | attribute | op | value | +----+------------------+----------------+----+----------------+ | 5 | engineeringadmin | Huntgroup-Name | == | admin | | 6 | engineeringadmin | Auth-Type | := | Accept |
Why? This will make the server act as you describe: Any username in the engineeringadmin group will be accepted regardless of password.
Bjørn
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (3)
-
Alan Buxey -
Bjørn Mork -
Satyam Mathura