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

Tue Aug 23 00:09:17 CDT 2005

Hello Scott -

You need to use an AuthBy GROUP as follows:

<Handler Client-Identifier = foundry>

     # enable accounting
     AcctLogFileName %D/detail

     # keep authenticating while ACCEPT

     AuthByPolicy ContinueWhileAccept

     AuthBy LDAPBind

     <AuthBy GROUP>

         # now change to AuthByPolicy ContinueUntilAccept

         AuthByPolicy ContinueUntilAccept

         AuthBy Full

         AuthBy Read

     </AuthBy>

</Handler>

hope that helps

regards

Hugh

On 23 Aug 2005, at 10:19, Scott Ehnert wrote:

> Hello Matt,
>
> Thank you, this was a big help.  Of course, I have hit another
> stumbling block, this time with the AuthByPolicy portion.  At this
> point, I am able to authenticate the users password, then it gets sent
> to the next authby clause to match group membership.  The group has
> the defined radius attributes and they are being returned upon a
> proper match.  All as it should be... the problem now is how to get
> the AuthByPolicy to stop once it matches the correct group membership?
>  I have tried all the various AuthByPolicy options and I still get
> Access-Reject packets returned because the last AuthBy clause does not
> return a match, and is thus denied.
>
> How can I get a user with membership in 'foundryfull' to be accepted
> given the configuration below?  If I take out all references to the
> AuthBy Read group, it works just fine.  And if you invert that, how
> would I get a user with membership in 'foundryread' to be granted
> access, as with the current config they would be reject too based upon
> no membership in 'foundryfull'?
>
> I am sure I am overlooking some fairly obvious bit of config, but i
> can't find what it is.
>
> Foreground
> LogStdout
> LogDir          /var/log/radius
> DbDir           /etc/radiator/raddb
> # User a lower trace level in production systems:
> Trace           5
> BindAddress 10.255.255.241
> AuthPort 1645,1812
> AcctPort 1646,1813
> # You will probably want to add other Clients to suit your site,
> # one for each NAS you want to work with
>
> <Client 10.255.255.244>
>         Identifier foundry
>         Secret  mysecret
>         DupInterval 0
> </Client>
>         <AuthBy LDAP2>
>         Identifier LDAPBind
>         #RewriteUsername      s/^([^@]+).*/$1/
>         NoDefault
>         Host localhost
>         AuthDN cn=admin, dc=somenet, dc=net
>         AuthPassword qwe123
>         BaseDN dc=somenet, dc=net
>         Version 3
>         UsernameAttr    cn
>         PasswordAttr    passwd
>         ServerChecksPassword
>         Debug 255
>         </AuthBy>
>
>
>         <AuthBy LDAP2>
>         Identifier Full
>         NoDefault
>         Host localhost
>         AuthDN cn=admin, dc=somenet, dc=net
>         AuthPassword qwe123
>         BaseDN ou=Group, dc=somenet, dc=net
>         Version 3
>         SearchFilter (&(memberUid=%1)(|(cn=foundryfull)))
>         AuthAttrDef radiusReplyItem,GENERIC,reply
>         Debug 255
>         </AuthBy>
>
>         <AuthBy LDAP2>
>         Identifier Read
>         NoDefault
>         Host localhost
>         AuthDN cn=admin, dc=somenet, dc=net
>         AuthPassword qwe123
>         BaseDN ou=Group, dc=somenet, dc=net
>         Version 3
>         SearchFilter (&(memberUid=%1)(|(cn=foundryread)))
>         AuthAttrDef radiusReplyItem,GENERIC,reply
>         Debug 255
>         </AuthBy>
>
> <Handler Client-Identifier = foundry>
>
>     # enable accounting
>     AcctLogFileName %D/detail
>
>     # try each of the following methods, until something rejects us
>     AuthByPolicy ContinueUntilReject
>
>     AuthBy LDAPBind
>
>     AuthBy Full
>
>     AuthBy Read
> </Handler>
>
>
>
> Thanks for any assistance.
>
> Regards,
>
> -=Scott
>
>
> On 8/16/05, Matt Richard <matt.richard at fandm.edu> wrote:
>
>> 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
>>
>>
>>
>
> --
> 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.
>

NB:

Have you read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive (www.open.com.au/archives/ 
radiator)?
Have you had a quick look on Google (www.google.com)?
Have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.

--
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.