restricting access for users
Hi there, Im a newby here so forgive if I ask obvious questions. Im trying to setup, wel actually I did setup FreeRADIUS Version 1.0.2 on a Linux Debian machine and it is working fine :) But I need to achieve the following setup: We have # cisco routers and switches who are locally managed by on site engineers. So these local engineers have to be able to log in to their devices and not be allowed to log in to devices on other sites. Next to these different site engineers there is a group called NOC. The NOC engineers need to access all devices on all sites. Ive tried several setups by using the huntgroups and using system as authentication method but I can't get the huntgroup validation to work. It looks like the huntgroups are just ignored. Everyone can just enter any device as soon as their usrname and password is matched on the system. Did someone do a similar setup where users where restricted and with a general group that needs access everywhere or can someone tell me how I should take this on. It should be fairly easy I thought Thanks for your help, it is highly appreciated, Martial _________________________________________________________________ Free blogging with MSN Spaces http://spaces.msn.com/?mkt=nl-be
Hi Alan, thank you for replying, this is how I tried this before, I will try to keep this as short as possible. 1) users: bob Password == "bob", Huntgroup-name == "diegem" Login-Service = 0, Vendor-Specific = 9, Reply-Message = "Hello, bob", Cisco-AVpair = "shell:priv-lvl=15", Service-Type = NAS-Prompt-User, huntgroups: diegem NAS-IP-Address == 10.5.x.x diegem NAS-IP-Address == 10.5.x.x diegem NAS-IP-Address == 10.5.x.x brussels NAS-IP-Address == 10.2.x.x I hoped that the nas ip addresses belonging to diegem where only accessable for users who had Huntgroup-name == "diegem" in their config. But this did not seem to make a difference. ************************************************************************** 2) users: DEFAULT Auth-Type = System Login-Service = 0, Vendor-Specific = 9, Service-Type = NAS-Prompt-User, Cisco-AVpair = "shell:priv-lvl=15", $enab15$ bob bobke huntgroups: diegem NAS-IP-Address == 10.5.x.x diegem NAS-IP-Address == 10.5.x.x diegem NAS-IP-Address == 10.5.x.x Group == NOC, brussels NAS-IP-Address == 10.2.x.x I made bob and bobke local users on my machine and added them to # groups. bob to NOC and bobke to brussels. bob:x:1005:1005::/home/bob: bobke:x:1006:1006::/home/bobke: NOC:x:1005: brussels:x:1006: If the user was not a member of group NOC he would be refused on the NAS servers belonging to huntgroup diegem.Because diegem is linked to group NOC (Group == NOC). This did not work either. In both cases every user was allowed access as soon as the username and passwords checked out. I also had problems with nas ip addresses belonging to more that 1 group. It looked like the groups are processed from top to bottom and as soon as it hits the first entry of that address freeradius allowes access. But for my problem to be solved it should cache information like Group = NOC or for example user_pool = diegem. And compare this information agains an entry in the users file like: user_pool=diegem or checking if on the system bob's primary group is NOC. I did several more combinations but I think one of these 2 should work. Perhaps I made a configuration error ? Big thank you in advance ony for reading and getting into this problem. If I was not clear enough please let me know. Martial
Yes this is my experience as well. Running v 1.0.2 there was nothing in the change log for 1.0.3 >to say this was fixed either. Just as a note when I posted these findings nothing came back.
I was using an ldap backend as well. It would be great to have a detailed explaination of this one >and maybe confirmation that it is not working or wheather is it syntax that causes the problem
Alan
From: "Martial VdB" <mdbnoc@hotmail.com> Reply-To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> To: freeradius-users@lists.freeradius.org Subject: restricting access for users Date: Mon, 13 Jun 2005 09:22:14 +0200
Hi there,
Im a newby here so forgive if I ask obvious questions.
Im trying to setup, wel actually I did setup FreeRADIUS Version 1.0.2 on a Linux Debian machine and it is working fine :) But I need to achieve the following setup:
We have # cisco routers and switches who are locally managed by on site engineers. So these local engineers have to be able to log in to their devices and not be allowed to log in to devices on other sites. Next to these different site engineers there is a group called NOC. The NOC engineers need to access all devices on all sites.
Ive tried several setups by using the huntgroups and using system as authentication method but I can't get the huntgroup validation to work. It looks like the huntgroups are just ignored. Everyone can just enter any device as soon as their usrname and password is matched on the system.
Did someone do a similar setup where users where restricted and with a general group that needs access everywhere or can someone tell me how I should take this on. It should be fairly easy I thought
Thanks for your help, it is highly appreciated,
Martial
_________________________________________________________________ Free blogging with MSN Spaces http://spaces.msn.com/?mkt=nl-be
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
_________________________________________________________________ Is your PC infected? Get a FREE online computer virus scan from McAfee® Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
Try this. huntgroups
diegem NAS-IP-Address == 10.5.x.x diegem NAS-IP-Address == 10.5.x.x diegem NAS-IP-Address == 10.5.x.x brussels NAS-IP-Address == 10.2.x.x
users file #note: there is no default auth-type = system here DEFAULT Group == NOC, Auth-Type := System replyattrs = replyvalues bob Huntgroup-Name == diegem, Auth-Type := System replyattrs = replyvalues... somebrusselluser Huntgroup-Name == brussells, Auth-Type := System reply attrs DEFAULT Auth-Type := Reject That means: If user is in group NOC, match here and authorize the user using system If user bob is coming from huntgroup diegam, match here and authorize user If user somebrusselluser is coming from huntgroup brussells, match If no matches on above, reject the user I suspect that your DEFAULT Auth-Type = system entry is at the top of your users file. Then you have some matching rules. You have a user that comes in but won't match any of your matching rules, so it will default to the auth-type = system entry that it matched at first and simply authorize the user with system. What I have above, specifies to use system when it matches each user entry or the group entry. If there is no match, then it tells you to reject the user.
Thank you Dustin this works!! I'll be making a detailled description on how it works now. Maybe it can be posted? if not just send me an email and I will send it to anyone who wants it. Maybe I can contribute back this way Thanks again!!! Martial
From: Dustin Doris <freeradius@mail.doris.cc> Reply-To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: RE: restricting access for users Date: Mon, 13 Jun 2005 09:49:00 -0400 (EDT)
Try this.
huntgroups
diegem NAS-IP-Address == 10.5.x.x diegem NAS-IP-Address == 10.5.x.x diegem NAS-IP-Address == 10.5.x.x brussels NAS-IP-Address == 10.2.x.x
users file
#note: there is no default auth-type = system here
DEFAULT Group == NOC, Auth-Type := System replyattrs = replyvalues
bob Huntgroup-Name == diegem, Auth-Type := System replyattrs = replyvalues...
somebrusselluser Huntgroup-Name == brussells, Auth-Type := System reply attrs
DEFAULT Auth-Type := Reject
That means:
If user is in group NOC, match here and authorize the user using system If user bob is coming from huntgroup diegam, match here and authorize user If user somebrusselluser is coming from huntgroup brussells, match If no matches on above, reject the user
I suspect that your DEFAULT Auth-Type = system entry is at the top of your users file. Then you have some matching rules. You have a user that comes in but won't match any of your matching rules, so it will default to the auth-type = system entry that it matched at first and simply authorize the user with system.
What I have above, specifies to use system when it matches each user entry or the group entry. If there is no match, then it tells you to reject the user.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
_________________________________________________________________ Free blogging with MSN Spaces http://spaces.msn.com/?mkt=nl-be
Well, as promised here is the way I'm implementing it. I only did a small scale test. The big test and implementation will be for the next comming weeks. So far everything worked the way it should. hope I can help someone with this explenation. First install debian via net Than install freeradius #Apt-get install freeradius How it works: Routers and switches are defined in the file: clients.conf Users are defined in the file: users Huntgroups are used to restrict access: huntgroups Debugging freeradius s -X The client connects to the radius server, radius first goes to clients.conf to see if the client is in his list. Clients.conf: client 127.0.0.1 { secret = testing123 shortname = localhost nastype = other # localhost isn't usually a NAS... } client 10.5.x.x { secret = CISCOTEST shortname = namedevice nastype = cisco } client 10.5.x.x { secret = CISCOTEST shortname = namedevice nastype = cisco If it is, freeradius takes the users file and checks the passw and name of the client. If Auth-Type := System he will check the system files: /etc/shadow, /etc/group and /etc/passw. If the password is set in this user file, he will validate against this password. Users: DEFAULT Group == NOC, Auth-Type := System Login-Service = 0, Vendor-Specific = 9, Service-Type = NAS-Prompt-User, Cisco-AVpair = "shell:priv-lvl=15", #to give immediate enable access, which #makes it easier for us to manage enable passwords # bob Huntgroup-Name == diegem, Auth-Type := System Reply-Message = "Hello Bob", Cisco-AVpair = "shell:priv-lvl=15", Service-Type = NAS-Prompt-User, Login-Service = 0, Vendor-Specific = 9, # bobke Huntgroup-Name == brussels, Auth-Type := System Reply-Message = "Hello Bob", Cisco-AVpair = "shell:priv-lvl=15", Service-Type = NAS-Prompt-User, Login-Service = 0, Vendor-Specific = 9, # DEFAULT Auth-Type := Reject Some explanation here: If user is in group NOC (on the system), match here and authorize the user using system. So all users belonging to group NOC will have access to all devices if they provide the correct password. No need for their user name to be written in the users file. But if the users do not belong to the system group NOC they will have to be validated in huntgroups. If user bob is coming from huntgroup diegem, match here and authorize user. So if the user does not belong to group NOC but is a member of an active huntgroup he will also be validated against the system. Only if the client is also a member of that same huntgroup. If user bobke is coming from huntgroup brussells, match. If no matches on above, reject the user. DEFAULT Auth-Type := Reject This specifies to use system when it matches each user entry or the group entry. If there is no match, then it tells you to reject the user. Huntgroups: diegem NAS-IP-Address == 10.5.x.x diegem NAS-IP-Address == 10.5.x.x # brussels NAS-IP-Address == 10.2.x.x brussels NAS-IP-Address == 10.5.x.x Logging: has to be enabled in radiusd.conf (see below) /var/log/freeradius/radacct/10.5.240.247/auth-detail-20050614 radiusd.conf general config file # If you want to have a log of authentication requests, # un-comment the following line, and the 'detail auth_log' # section, above. # auth_log *************************************************** authorize { # # The preprocess module takes care of sanitizing some bizarre # attributes in the request, and turning them into attributes # which are more standard. # # It takes care of processing the 'raddb/hints' and the # 'raddb/huntgroups' files. # # It also adds the %{Client-IP-Address} attribute to the request. preprocess # # If you want to have a log of authentication requests, # un-comment the following line, and the 'detail auth_log' # section, above. auth_log # attr_filter # # The chap module will set 'Auth-Type := CHAP' if we are # handling a CHAP request and Auth-Type has not already been set chap # # If the users are logging in with an MS-CHAP-Challenge # attribute for authentication, the mschap module will find # the MS-CHAP-Challenge attribute, and add 'Auth-Type := MS-CHAP' # to the request, which will cause the server to then use # the mschap module for authentication. mschap # # If you have a Cisco SIP server authenticating against # FreeRADIUS, uncomment the following line, and the 'digest' # line in the 'authenticate' section. # digest # # Look for IPASS style 'realm/', and if not found, look for # '@realm', and decide whether or not to proxy, based on # that. # IPASS # # If you are using multiple kinds of realms, you probably # want to set "ignore_null = yes" for all of them. # Otherwise, when the first style of realm doesn't match, # the other styles won't be checked. # suffix # ntdomain # # This module takes care of EAP-MD5, EAP-TLS, and EAP-LEAP # authentication. # # It also sets the EAP-Type attribute in the request # attribute list to the EAP type from the packet. eap # # Read the 'users' file files # # Look in an SQL database. The schema of the database # is meant to mirror the "users" file. # # See "Authorization Queries" in sql.conf # sql # If you are using /etc/smbpasswd, and are also doing # mschap authentication, the un-comment this line, and # configure the 'etc_smbpasswd' module, above. # etc_smbpasswd # # The ldap module will set Auth-Type to LDAP if it has not # already been set # ldap # # Enforce daily limits on time spent logged in. # daily # # Use the checkval module # checkval } # Authentication. # # # This section lists which modules are available for authentication. # Note that it does NOT mean 'try each module in order'. It means # that a module from the 'authorize' section adds a configuration # attribute 'Auth-Type := FOO'. That authentication type is then # used to pick the apropriate module from the list below. # # In general, you SHOULD NOT set the Auth-Type attribute. The server # will figure it out on its own, and will do the right thing. The # most common side effect of erroneously setting the Auth-Type # attribute is that one authentication method will work, but the # others will not. # # The common reasons to set the Auth-Type attribute by hand # is to either forcibly reject the user, or forcibly accept him. # authenticate { # # PAP authentication, when a back-end database listed # in the 'authorize' section supplies a password. The # password can be clear-text, or encrypted. Auth-Type PAP { pap } # # Most people want CHAP authentication # A back-end database listed in the 'authorize' section # MUST supply a CLEAR TEXT password. Encrypted passwords # won't work. Auth-Type CHAP { chap } # # MSCHAP authentication. Auth-Type MS-CHAP { mschap } # # If you have a Cisco SIP server authenticating against # FreeRADIUS, uncomment the following line, and the 'digest' # line in the 'authorize' section. # digest # # Pluggable Authentication Modules. # pam # # See 'man getpwent' for information on how the 'unix' # module checks the users password. Note that packets # containing CHAP-Password attributes CANNOT be authenticated # against /etc/passwd! See the FAQ for details. # unix # Uncomment it if you want to use ldap for authentication # # Note that this means "check plain-text password against # the ldap database", which means that EAP won't work, # as it does not supply a plain-text password. # Auth-Type LDAP { # ldap # } # # Allow EAP authentication. eap } _________________________________________________________________ Free blogging with MSN Spaces http://spaces.msn.com/?mkt=nl-be
"Martial VdB" <mdbnoc@hotmail.com> wrote:
Ive tried several setups by using the huntgroups and using system as authentication method but I can't get the huntgroup validation to work. It looks like the huntgroups are just ignored. Everyone can just enter any device as soon as their usrname and password is matched on the system.
The huntgroups don't appear to work in 1.0.x Alan DeKok.
participants (3)
-
Alan DeKok -
Dustin Doris -
Martial VdB