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

[Scott Ehnert]

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.