Using postauth_users and Access-Reject

[Peter Lambrechtsen]

I have figured out where my mistake was.  I needed to have the users file
being used in the authorize section, but I shouldn't have had "Auth-Type :=
Accept" at the end of each line for the Groups, otherwise if the Auth-Type
is set to Accept the authenticate section is never run through.

So now this is how I have my configuration:

In my sites-enabled/default:

authorize {
        # Update the Huntgroup-Name based on the Src IP Address IP address
LDAP object.
        update request {
            Huntgroup-Name :=
"%{ldap:ldap:///ou=Elements,ou=Applications,o=Identities?l?sub?cn=%{Packet-Src-IP-Address}}"
        }
        ldap
        files
}

authenticate {
                ldap
}

The in my users file I have:
---
DEFAULT Huntgroup-Name == GRP1, Ldap-Group ==
"cn=Generic,ou=Radius,ou=Applications,o=Identities"
        Service-Type = "Login-User",
        Cisco-AVPair = "shell:priv-lvl=15"

DEFAULT Auth-Type := Reject
---

This way the auth-type is set to Reject if it doesn't match with any group.

Then it runs through the authenticate section and checks the password for
the user.

Works a treat!!

If you want me to write a Wiki article for this I am more than happy to do
so.

On Tue, Aug 10, 2010 at 10:18 AM, Peter Lambrechtsen <
plambrechtsen at gmail.com> wrote:

> On Mon, Aug 9, 2010 at 6:31 PM, Alan DeKok <aland at deployingradius.com>wrote:
>
>> Peter Lambrechtsen wrote:
>> > Using FreeRadius 2.1.7 and trying to get the postauth_users to return an
>> > access reject however it always seems to return either a noop or ok.
>> ..
>> > And this is what is in my postauth_users file:
>> >
>> > DEFAULT Auth-Type := REJECT
>> >         Post-Auth-Type = Reject,
>>
>>   Hmm... you are trying to change the *authentication* type to reject
>> after the *authenticate* section has been executed.  This won't work.
>>
>
> Right, so this is my business use case and I think I have figured out the
> best way, but would love your input.
>
> 1) We have a centralised LDAP directory which holds all employees.  We have
> an IDM solution which provisions employees into the LDAP directory based on
> their role as driven out of the HR system.  This is a very robust and
> automated system which the team I look after maintains.
>
> 2) There a lot of Network Elements (NAS's) such as Routers, and Telco
> DSLAMs and a raft of other devices used for both customer and employees to
> login.  These need to be grouped into nas group types, so that we can AA
> customers and employees to permit them to login to those groups of devices.
> I am using Huntgroup's to group the NAS's together.  This is driven out of
> LDAP.  In my authorize section I have the following:
>
> authorize {
> update request {
>     Huntgroup-Name :=
> "%{ldap:ldap:///ou=Elements,ou=Applications,o=Identities?l?sub?cn=%{Packet-Src-IP-Address}}"
> }
>     ldap
> }
>
> This way I create Group objects as the IP address of the source NAS in the
> LDAP directory with a "location" or "L" attribute set to the Huntgroup-Name
> I want set.  This works very effectivly to set the Huntgroup name.
> I also have "ldap" so that the incoming account is also looked up to see if
> it exists.
>
> 3) We want to drive access to the elements using a user being a member of a
> certain LDAP group.
>
> 4) We want to make sure the username and password is correct for the user
> entered.  So in the authenticate we have:
> authenticate {
>         Auth-Type LDAP {
>                 ldap
>         }
> }
>
>
> 5) The NAS's have a number of different profiles (admin, r/w, r/o etc) and
> each NAS group has a different group of VSA's they want back.  So in the
> postauth_users file I have the following:
>
> DEFAULT Huntgroup-Name == NAS1, Ldap-Group ==
> "cn=admin,ou=Profiles,ou=Riverstone,ou=Applications,o=Identities", Auth-Type
> := Accept
>         Service-Type = "Login-User",
>         Riverstone-User-Level = "15"
>
> DEFAULT Huntgroup-Name == NAS1, Ldap-Group ==
> "cn=guest,ou=Profiles,ou=Riverstone,ou=Applications,o=Identities", Auth-Type
> := Accept
>         Service-Type = "Login-User",
>         Riverstone-User-Level = "1"
>
> DEFAULT Huntgroup-Name == NAS2, Ldap-Group ==
> "cn=admin,ou=Profiles,ou=Cisco,ou=Applications,o=Identities", Auth-Type :=
> Accept
>         Service-Type = "Login-User",
>         Cisco-AVPair = "shell:priv-lvl=15"
>
> And so on..
>
> The issue I had was if none of the Huntgroups matched to the user being a
> member of group x, I needed to return a access-reject.
>
> The only way I could achieve this was to add onto the end of the
> postauth_users file:
>
> DEFAULT Auth-Type := Reject
>         Reply-Message = "Reject"
>
> And in my post-auth section have:
>
> post-auth {
>
>         files
>         if ("%{reply:Reply-Message}" == "Reject") {
>                 reject
>         }
> }
>
>
>
>
>>
>> > Ideally I would assume if the Auth-Type := Reject then the return should
>> > be "RLM_MODULE_REJECT".
>>
>>   No.  Setting "Auth-Type := Reject" is useful ONLY in the "authorize"
>> section, *before* the "authentication" section has been run.  It doesn't
>> reject the user immediately.  Instead, it tells the server to run the
>> "reject" authentication method.
>>
>
> So would it be better to have the postauth_users lookup to be in the
> authorize section and rename my "postauth_users" to just "users", and do it
> at that point?
>
> The issue with having in the authorize section:
>
> authorize {
> update request {
>     Huntgroup-Name :=
> "%{ldap:ldap:///ou=Elements,ou=Applications,o=Identities?l?sub?cn=%{Packet-Src-IP-Address}}"
> }
>     ldap
>     files
> }
>
> Is that it never seems to go into the authenticate section.
>
> Any suggestions on how to best achieve this apart from how I am doing it?
>
>  > Since otherwise I think I will need to lookup if the Reply-Message is
>> > set to disabled, and then do a reject.
>>
>>   No.
>>
>>  If you want the post-auth section to return "reject", just put
>> "reject" into the list of modules to be run:
>>
>> post-auth {
>>        ...
>>        reject
>>        ...
>> }
>>
>>  See "man unlang" for details.
>>
>
> I have done that, as per my above suggestion.
>
> Cheers
>
> Peter
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20100811/45f5155c/attachment.html>