[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freeradius-users
Subject:    RE: User Authorization question
From:       Larry Ross <lfross () ucdavis ! edu>
Date:       2009-03-31 22:04:38
Message-ID: 1FF77A6EABE79749A7D89BE018D5AF893C68B58AFE () XEDAMAIL2 ! ex ! ad3 ! ucdavis ! edu
[Download RAW message or body]

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

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


[prev in list] [next in list] [prev in thread] [next in thread]