Using postauth_users and Access-Reject
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. This is what I get in my radiusd -X trace: [files] postauth_users: Matched entry DEFAULT at line 30 ++[files] returns ok Sending Access-Accept of id 53 to 192.168.143.72 port 2503 Reply-Message = "Your account has been disabled." And this is what is in my postauth_users file: DEFAULT Auth-Type := REJECT Post-Auth-Type = Reject, Reply-Message = "Your account has been disabled." Checking the rlm_files.c it seems that either ok or noop are the two options returned: /* * See if we succeeded. */ if (!found) return RLM_MODULE_NOOP; /* on to the next module */ return RLM_MODULE_OK; Ideally I would assume if the Auth-Type := Reject then the return should be "RLM_MODULE_REJECT". Since otherwise I think I will need to lookup if the Reply-Message is set to disabled, and then do a reject. I'm no C developer hence why I am not offering up a patch, but I might try and see how difficult it would be. Cheers Peter
I've semi-sorted it by setting a Reply-Message and then using Unlang to lookup that message a bit ugly, but it works. In my post-auth section I have: files if ("%{reply:Reply-Message}" == "Reject") { reject } And in the postauth_users I have: DEFAULT Auth-Type := Reject Reply-Message = "Reject" Which gives me this in the trace: ++[files] returns ok ++? if ("%{reply:Reply-Message}" == "Reject") expand: %{reply:Reply-Message} -> Reject ? Evaluating ("%{reply:Reply-Message}" == "Reject") -> TRUE ++? if ("%{reply:Reply-Message}" == "Reject") -> TRUE ++- entering if ("%{reply:Reply-Message}" == "Reject") {...} +++[reject] returns reject ++- if ("%{reply:Reply-Message}" == "Reject") returns reject Using Post-Auth-Type Reject +- entering group REJECT {...} ++[reject] returns reject Sending Access-Reject of id 76 to 192.168.143.72 port 2747 Reply-Message = "Reject" On Mon, Aug 9, 2010 at 3:36 PM, Peter Lambrechtsen <plambrechtsen@gmail.com>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.
This is what I get in my radiusd -X trace:
[files] postauth_users: Matched entry DEFAULT at line 30 ++[files] returns ok Sending Access-Accept of id 53 to 192.168.143.72 port 2503 Reply-Message = "Your account has been disabled."
And this is what is in my postauth_users file:
DEFAULT Auth-Type := REJECT Post-Auth-Type = Reject, Reply-Message = "Your account has been disabled."
Checking the rlm_files.c it seems that either ok or noop are the two options returned:
/* * See if we succeeded. */ if (!found) return RLM_MODULE_NOOP; /* on to the next module */
return RLM_MODULE_OK;
Ideally I would assume if the Auth-Type := Reject then the return should be "RLM_MODULE_REJECT".
Since otherwise I think I will need to lookup if the Reply-Message is set to disabled, and then do a reject.
I'm no C developer hence why I am not offering up a patch, but I might try and see how difficult it would be.
Cheers
Peter
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.
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.
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. Alan DeKok.
On Mon, Aug 9, 2010 at 6:31 PM, Alan DeKok <aland@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
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@gmail.com> wrote:
On Mon, Aug 9, 2010 at 6:31 PM, Alan DeKok <aland@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
Peter Lambrechtsen wrote:
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.
That's pretty much what I was trying to explain earlier. When you posted another config snippet that *didn't* follow my advice, I lost interest in the thread. I have *no* idea why so many people insist on forcing Auth-Type. It causes problems in 99.9% of the situations, including this one. Alan DeKok.
On Wed, Aug 11, 2010 at 12:40 PM, Alan DeKok <aland@deployingradius.com>wrote:
Peter Lambrechtsen wrote:
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.
That's pretty much what I was trying to explain earlier. When you posted another config snippet that *didn't* follow my advice, I lost interest in the thread.
Fair enough, you do get a lot of silly setup questions which you answer most of the time ;)
I have *no* idea why so many people insist on forcing Auth-Type. It causes problems in 99.9% of the situations, including this one.
Understood, I had just taken examples off the internet about how to setup LDAP Auth, which was very misleading by having the Auth-Type being set which caused all of my issues in the first place. My offer still stands to write up a wiki entry for this, as it seems to be quite a common question and use case that could be answered with a wiki entry.
Peter Lambrechtsen wrote:
Understood, I had just taken examples off the internet about how to setup LDAP Auth, which was very misleading by having the Auth-Type being set which caused all of my issues in the first place.
And the documentation (web, manual pages, config files) says in many places that third-party "howtos" are old, out of date, and misleading.
My offer still stands to write up a wiki entry for this, as it seems to be quite a common question and use case that could be answered with a wiki entry.
Write it up && post it to the list. Alan DeKok.
participants (2)
-
Alan DeKok -
Peter Lambrechtsen