(RADIATOR) Attributes, AuthBy LDAP, and differentiated access levels

[Matt Richard]

Hi, Scott,

You will want to have separate authentication sections for each set 
of switches.

Make several LDAP group for each switch, one with each access level 
that you use.  You can place the foundry-privilege-level attributes 
in the group itself, and just return the search results in the 
packet.  Or you can use several authby sections and manually set the 
access level in the reply packet.

Then you will have one set of handlers for each group of RADIUS 
clients (switches/routers) where you will use AuthByPolicy 
ContinueUntilReject.  Then first try a bind for authentication.  Then 
try the search for authorization.

In case this is as clear as mud, I'm attaching an example version of 
my config file.  I'm not doing exactly what you are, but I am 
handling users differently depending on what kind of device they log 
in to.

Hope this helps,

Matt

At 2:33 PM -0700 8/10/05, Scott Ehnert wrote:
>Hello,
>
>We are using AuthBy LDAP in order to centralize our user database.  I
>have run into a hitch with this that I am unsure of how to work
>around.
>
>We have several different "classes" of device based on their function.
>  For instance, we have foundry switches, some are classified "core"
>some are "edge" etc.  We want to restrict user privilege level by the
>class of device.  The problem is that if a user has
>foundry-privilege-level=0 access to "edge" but has
>foundry-privilege-level=5 access to "core" how do I send the
>appropriate attribute based on which type of device?
>
>I can see working around this by using AuthBy FILE and defining
>different files on a per-realm basis, and then assigning each class to
>a different Realm, but this defeats the centralized management
>function.
>
>Any assistance is appreciated.
>
>Thanks!
>
>-=Scott
>
>--
>Archive at http://www.open.com.au/archives/radiator/
>Announcements on radiator-announce at open.com.au
>To unsubscribe, email 'majordomo at open.com.au' with
>'unsubscribe radiator' in the body of the message.


-- 
Matt Richard
Access and Security Coordinator
Computing Services
Franklin & Marshall College
matt.richard at fandm.edu
(717) 291-4157
-------------- next part --------------
A non-text attachment was scrubbed...
Name: radius-ldap-example.cfg
Type: application/octet-stream
Size: 4005 bytes
Desc: not available
URL: <http://www.open.com.au/pipermail/radiator/attachments/20050816/58fc36e8/attachment.obj>