something like huntgroups?
Greetings! Our Cisco VPN concentrator is sending some RADIUS attributes in the request packet and if certain values appear, then I'd like to only allow a subset of users to login. I've looked at: http://wiki.freeradius.org/SQL-Huntgroup-HOWTO/dbeef165862fe9ba7ef6f7d011889... the SQL Huntgroup howto and it seemed close, but the scenario that I am looking at is slightly different and I am getting mixed up. I am hoping for some help. Here is my scenario: We have a generic VPN profile that we'd like to allow *all* users to login to - this works well. When users login to the "secret" profile, then the following VPN attribute is included in the request: Vendor-3076-Attr-146 = 0x554d44 The attribute and value are known and constant, thus I can make decisions on them. Users who are in the "secret" group should be able to login to *both* the generic profile (which does not have the Vendor-3076-Attr-146 = 0x554d44 pair) and the "secret" profile, which does have the pair. If a user is not in the secret group, then their login should fail if the Vendor-3076-Attr-146 = 0x554d44 pair is in the request. Thanks for any advice or design input! Cheers, -mz
On 07/02/2013 02:30 AM, Matt Zagrabelny wrote:
If a user is not in the secret group, then their login should fail if the Vendor-3076-Attr-146 = 0x554d44 pair is in the request.
This is pretty easy: authorize { ... if (Vendor-3076-Attr-146 == 0x554d44) { if (SQL-Group == secret) { noop } else { reject } } ... } See "man unlang" for more info.
On 2 Jul 2013, at 07:18, Phil Mayers <p.mayers@IMPERIAL.AC.UK> wrote:
On 07/02/2013 02:30 AM, Matt Zagrabelny wrote:
If a user is not in the secret group, then their login should fail if the Vendor-3076-Attr-146 = 0x554d44 pair is in the request.
This is pretty easy:
authorize { ... if (Vendor-3076-Attr-146 == 0x554d44) { if (SQL-Group == secret) { noop } else { reject } } ... }
Actually no. Undefined attributes should not be modified or evaluated. You'll need to find the proper definition for the attribute and add a new dictionary entry. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
On 2 Jul 2013, at 07:41, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 2 Jul 2013, at 07:18, Phil Mayers <p.mayers@IMPERIAL.AC.UK> wrote:
On 07/02/2013 02:30 AM, Matt Zagrabelny wrote:
If a user is not in the secret group, then their login should fail if the Vendor-3076-Attr-146 = 0x554d44 pair is in the request.
This is pretty easy:
authorize { ... if (Vendor-3076-Attr-146 == 0x554d44) { if (SQL-Group == secret) { noop } else { reject } } ... }
Actually no. Undefined attributes should not be modified or evaluated. You'll need to find the proper definition for the attribute and add a new dictionary entry.
This may work for 2.x.x but definitely wont't work for 3.0 which uses direct DICT_ATTR pointer comparisons in some places (instead of comparing vendor/attribute number). Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
On 2 Jul 2013, at 08:53, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 07/02/2013 07:52 AM, Arran Cudbard-Bell wrote:
This may work for 2.x.x but definitely wont't work for 3.0 which uses direct DICT_ATTR pointer comparisons in some places (instead of comparing vendor/attribute number).
So... what *can* you do with Vendor-X-Attr-Y?
Use it to figure out which dictionary entries you're missing. We can't modify the dictionaries dynamically after startup without locking the tree (on every read/write), else we could of added unknown attributes as octet type attributes. The compromise is to dynamically allocate fake DICT_ATTR entries for attributes which couldn't be resolved in the dictionaries, or that have values which don't match their data type (64bit value in integer type for example). As these DICT_ATTRs are dynamically allocated and unique to each request, comparing the pointers doesn't result in a match. A better solution, seeing as we now pre-parse all conditions and xlat expansions, might be to add unknown attributes at parse time. The server didn't do this when we first started using DICT_ATTR pointers in VALUE_PAIRs. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
On 02/07/13 11:37, Arran Cudbard-Bell wrote:
On 2 Jul 2013, at 08:53, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 07/02/2013 07:52 AM, Arran Cudbard-Bell wrote:
This may work for 2.x.x but definitely wont't work for 3.0 which uses direct DICT_ATTR pointer comparisons in some places (instead of comparing vendor/attribute number).
So... what *can* you do with Vendor-X-Attr-Y?
Use it to figure out which dictionary entries you're missing.
I was hoping for something more specific than that ;o) So you can't compare them; can you set them: update reply { Vendor-X-Attr-Y = 0xff } ? Can you xlat them? update request { Tmp-String-0 = "%{Vendor-X-Attr-Y}" } ? Or are they basically display-only i.e. debug output and detail file?
We can't modify the dictionaries dynamically after startup without locking the tree (on every read/write), else we could of added unknown attributes as octet type attributes.
The compromise is to dynamically allocate fake DICT_ATTR entries for attributes which couldn't be resolved in the dictionaries, or that have values which don't match their data type (64bit value in integer type for example).
As these DICT_ATTRs are dynamically allocated and unique to each request, comparing the pointers doesn't result in a match.
Ah.
On 2 Jul 2013, at 11:57, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 02/07/13 11:37, Arran Cudbard-Bell wrote:
On 2 Jul 2013, at 08:53, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 07/02/2013 07:52 AM, Arran Cudbard-Bell wrote:
This may work for 2.x.x but definitely wont't work for 3.0 which uses direct DICT_ATTR pointer comparisons in some places (instead of comparing vendor/attribute number).
So... what *can* you do with Vendor-X-Attr-Y?
Use it to figure out which dictionary entries you're missing.
I was hoping for something more specific than that ;o)
It appears Alan has already done what I just suggested below. update reply { Vendor-1-Attr-2 := 0x01 } if (&reply:Vendor-1-Attr-2) { ok } (0) update reply { (0) Vendor-1-Attr-2 := 0x01 (0) } # update reply = notfound (0) ? if (&reply:Vendor-1-Attr-2) (0) ? if (&reply:Vendor-1-Attr-2) -> TRUE (0) if (&reply:Vendor-1-Attr-2) { (0) - entering if (&reply:Vendor-1-Attr-2) {...} (0) [ok] = ok (0) - if (&reply:Vendor-1-Attr-2) returns ok Sending Access-Reject of id 208 from 0.0.0.0 port 1812 to 127.0.0.1 port 54941 Attr-26.1.2 = 0x01 Waking up in 4.9 seconds. Radclient gets confused though... rad_recv: Access-Reject packet from host 127.0.0.1 port 1812, id=208, length=29 Attr-26 = 0x00000001020301 So you may in fact now be able to use them in conditions, and be able to ignore everything I previously said. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
On 2 Jul 2013, at 12:15, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 2 Jul 2013, at 11:57, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 02/07/13 11:37, Arran Cudbard-Bell wrote:
On 2 Jul 2013, at 08:53, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 07/02/2013 07:52 AM, Arran Cudbard-Bell wrote:
This may work for 2.x.x but definitely wont't work for 3.0 which uses direct DICT_ATTR pointer comparisons in some places (instead of comparing vendor/attribute number).
So... what *can* you do with Vendor-X-Attr-Y?
Use it to figure out which dictionary entries you're missing.
I was hoping for something more specific than that ;o)
It appears Alan has already done what I just suggested below.
update reply { Vendor-1-Attr-2 := 0x01 }
if (&reply:Vendor-1-Attr-2) { ok }
(0) update reply { (0) Vendor-1-Attr-2 := 0x01 (0) } # update reply = notfound (0) ? if (&reply:Vendor-1-Attr-2) (0) ? if (&reply:Vendor-1-Attr-2) -> TRUE (0) if (&reply:Vendor-1-Attr-2) { (0) - entering if (&reply:Vendor-1-Attr-2) {...} (0) [ok] = ok (0) - if (&reply:Vendor-1-Attr-2) returns ok
Or the condition stuff is still message up... Taking out the update statement I still get: (0) ? if (reply:Vendor-1-Attr-2) (0) ? if (reply:Vendor-1-Attr-2) -> TRUE (0) if (reply:Vendor-1-Attr-2) { (0) - entering if (reply:Vendor-1-Attr-2) {...} (0) [ok] = ok Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
On 2 Jul 2013, at 12:19, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 2 Jul 2013, at 12:15, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 2 Jul 2013, at 11:57, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 02/07/13 11:37, Arran Cudbard-Bell wrote:
On 2 Jul 2013, at 08:53, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 07/02/2013 07:52 AM, Arran Cudbard-Bell wrote:
This may work for 2.x.x but definitely wont't work for 3.0 which uses direct DICT_ATTR pointer comparisons in some places (instead of comparing vendor/attribute number).
So... what *can* you do with Vendor-X-Attr-Y?
Use it to figure out which dictionary entries you're missing.
I was hoping for something more specific than that ;o)
It appears Alan has already done what I just suggested below.
update reply { Vendor-1-Attr-2 := 0x01 }
if (&reply:Vendor-1-Attr-2) { ok }
(0) update reply { (0) Vendor-1-Attr-2 := 0x01 (0) } # update reply = notfound (0) ? if (&reply:Vendor-1-Attr-2) (0) ? if (&reply:Vendor-1-Attr-2) -> TRUE (0) if (&reply:Vendor-1-Attr-2) { (0) - entering if (&reply:Vendor-1-Attr-2) {...} (0) [ok] = ok (0) - if (&reply:Vendor-1-Attr-2) returns ok
Or the condition stuff is still message up...
*messed
Taking out the update statement I still get:
(0) ? if (reply:Vendor-1-Attr-2) (0) ? if (reply:Vendor-1-Attr-2) -> TRUE (0) if (reply:Vendor-1-Attr-2) { (0) - entering if (reply:Vendor-1-Attr-2) {...} (0) [ok] = ok
Ok, just broken for unknown attributes: (0) update reply { (0) ? if (reply:User-Name) (0) ? if (reply:User-Name) -> FALSE (0) policy filter_username { Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
Hi,
We have a generic VPN profile that we'd like to allow *all* users to login to - this works well.
When users login to the "secret" profile, then the following VPN attribute is included in the request:
Vendor-3076-Attr-146 = 0x554d44
use/load the dictionary.cisoc.vpn3000 dictionary file (its what ASA have inherited) the 146 attribute isnt present currently so just add it to the file after the Member-Of entry eg eg ATTRIBUTE CPVN3000-Member-Of 145 string ATTRIBUTE CPVN3000-Tunnel-Group-Name 146 string theres a tonne of other attributes missing from that dictionary....havent got time to send through the change right now. alan
participants (4)
-
A.L.M.Buxey＠lboro.ac.uk -
Arran Cudbard-Bell -
Matt Zagrabelny -
Phil Mayers