Good Afternoon Ivan; Thank you for your reply. I have looked into passwd, however it appears that this only works for accounts within the local machine. I am authenticating accounts held within a remote Kerberos realm, thus the accounts are not local to the machine. I have loaded the passwd module in the module sections as seen below. Module Section passwd noc_group { filename = /etc/raddb/group format = "~Group-Name:*,User-Name" hashsize = 50 ignorenislike = yes allowmultiplekeys = yes delimiter = ":" } Authorize secitoin #Testing Config to use custom Group File noc_group /etc/group file, one group defined, two testing users. NOC:ez073973,jttester Users file. For first round testing I would like to reject. Once I have this all squared away I will begin more detaile dconfig. DEFAULT Group-Name = "NOC", Auth-Type = Reject Reply-Message = "FAIL", Fall-Through = no DEFAULT Auth-Type = krb5 Fall-Through = 1 DEFAULT Auth-Type = System When an account that is local to the machine tries to authenticate it fails accordingly thus it appears the machine is still using the internal user/group mechanism, not the custom file. (notice how I am not using the default group file, I am using something separate to ensure that things remain... separate). Accounts not local to the machine authenticates and is given an access accept, unfortunatley it should fail them. Thank you -----Original Message----- From: freeradius-users-bounces+lfross=ucdavis.edu@lists.freeradius.org [mailto:freeradius-users-bounces+lfross=ucdavis.edu@lists.freeradius.org] On Behalf Of tnt@kalik.net Sent: Friday, March 27, 2009 2:50 AM To: FreeRadius users mailing list Subject: Re: User Authorization question

I am looking at different ways to authorize users using local resources. I would like to create various Text files (like foundry.acl, juniper.acl etc etc) with a list of kerberos principles contained within (each principle separated by new line). When a user attempts to authenticate from a given IP range the radius engine will authorize the user against the appropriate acl file, if the user is contained within the acl file then they are allowed and certain vendor specific attrs are sent back with the acess accept. Basically I would like to create "groups" to authorize access to different devices accross the network, LDAP is not an option and moving forward with a SQL db seems a bit over kill.

See passwd module. Ivan Kalik Kalik Informatika ISP - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Config now reads #DEFAULT Auth-Type = System Still not working though Gonna run through a couple iterations here as I do not think I am expressing the problem properly. First I would like to lay the ground rules. 1: Compare Attribute "User-Name" to a list of usernames in a text file. Format of text file "GROUP-NAME:Usernamea,Usernameb,usernamec" ex "TEST:Noc1,Noc2" Here we have two usernames Noc1 and Noc2 they are in "group" TEST 2: Assign "Group-Name" attributes to the Auth request. IN this ex Noc1 and Noc2 usernames would have Group-Name field set to "TEST" 3: Use "Group-Name" as a flag to assign privileges. ex. When you log onto our Foundry switch gear it places you in a non admin role. To become an admin the Radius server must send a flag back to the switch as part of the authentication process. We have devices other than the Foundry gear that behaves the same way. We will have multiple groups with different members all accounts will be members of more than one group so I will need to perform some logic using the Authenticating device as well as group membership, so based on which device is asking for Auth and what the users accounts is a member of will dictate what flags are sent back. Right now I am on step 2. I have one account on the machine (its my Linux dev box so I only need my account on it..) and have Kerberos up and running to auth campus accounts. Lets call my account "usernamea" which resides locally AND remotely in Kerberos with different passwords, however the accounts from a string compare standpoint are identical (ie on the linux box my username is "usernamea" my campus kerberos principal is also "usernamea") The second Username "usernameb" is not local to my machine and thus only resides in remote kerberos. Lets look at some Debug output, see attached file Initialization.txt Lets look at some auth attmepts. See attached files. I think the way I am trying to implement this is way off base. If I could have my way I would rock it from clients.conf. ie Place the logic in the clients configuration, that way when a client auths against radius all the group logic and radius reply attribute logic is performed on a client by client basis (ie have a client group for the foundry gear, if your username is in the foundry group you get access. Another group for hte packshaper group, they log into the shaper, they are in the packeteer group, bam they get access to said device (with approprite reply flags). Hope this is possible. Thank you

D'Oh. Its what Cent 5 installed (being a touch lazy... Sorry will rectify and touch base when on current code) -----Original Message----- From: freeradius-users-bounces+lfross=ucdavis.edu@lists.freeradius.org [mailto:freeradius-users-bounces+lfross=ucdavis.edu@lists.freeradius.org] On Behalf Of tnt@kalik.net Sent: Tuesday, March 31, 2009 1:58 PM To: FreeRadius users mailing list Subject: RE: User Authorization question

Config now reads #DEFAULT Auth-Type = System Still not working though

Erm, what is not working?

Gonna run through a couple iterations here as I do not think I am expressing the problem properly. First I would like to lay the ground rules.

1: Compare Attribute "User-Name" to a list of usernames in a text file. Format of text file "GROUP-NAME:Usernamea,Usernameb,usernamec" ex "TEST:Noc1,Noc2" Here we have two usernames Noc1 and Noc2 they are in "group" TEST 2: Assign "Group-Name" attributes to the Auth request. IN this ex Noc1 and Noc2 usernames would have Group-Name field set to "TEST"

You have done that.

3: Use "Group-Name" as a flag to assign privileges. ex. When you log onto our Foundry switch gear it places you in a non admin role. To become an admin the Radius server must send a flag back to the switch as part of the authentication process. We have devices other than the Foundry gear that behaves the same way. We will have multiple groups with different members all accounts will be members of more than one group so I will need to perform some logic using the Authenticating device as well as group membership, so based on which device is asking for Auth and what the users accounts is a member of will dictate what flags are sent back.

Tht is going to be very complicated on this ancient server version. Any reason you are not doing this with current version? 3. would be so much easier using unlang. Also this:

I think the way I am trying to implement this is way off base. If I could have my way I would rock it from clients.conf. ie Place the logic in the clients configuration, that way when a client auths against radius all the group logic and radius reply attribute logic is performed on a client by client basis (ie have a client group for the foundry gear, if your username is in the foundry group you get access. Another group for hte packshaper group, they log into the shaper, they are in the packeteer group, bam they get access to said device (with approprite reply flags).

Ivan Kalik Kalik Informatika ISP - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html