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