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