On Mon, Aug 9, 2010 at 6:31 PM, Alan DeKok <al...@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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
