[RADIATOR] Apcon Radius dictionary entry

2014-08-14 Thread Jason Griffith
Hello all,

We were hunting around for this today but could not find it within the
included dictionary entry with Radiator. Hopefully it will be useful to
someone else and maybe be added in the future?

This is for the Apcon range of IntellaPatch devices. We had a few that
could only authenticate with Radius and the following dictionary entries
seem to work for this:

VENDOR  Apcon   10830
VENDORATTR 10830   Apcon-User-Level  1  integer
VALUE   Apcon-User-Level  Default   0
VALUE   Apcon-User-Level  Guest 1
VALUE   Apcon-User-Level  Operator  2
VALUE   Apcon-User-Level  Advanced  3
VALUE   Apcon-User-Level  Admin 4

Regards,

Jason Griffith
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

[RADIATOR] Correction to CheckPoint Gaia dictionary entry

2014-04-14 Thread Jason Griffith
Hi, I'd just thought I'd share this with anyone who is interested. I was
troubleshooting Radius with the Gaia CheckPoint OS today and found that we
had problems assigning roles to users via the Radius attributes. We fixed
this by modifying the following in the Radiator dictionary file:

We replaced the commented lines with the VENDORATTR lines.

#
# CheckPoint
#
VENDORCheckPoint  2620
#ATTRIBUTE CP-Gaia-User-Role   229 string
#ATTRIBUTE CP-Gaia-SuperUser-Access  230 integer

VENDORATTR  2620  CP-Gaia-User-Role   229 string
VENDORATTR  2620  CP-Gaia-SuperUser-Access  230 integer

After we made this change the User Role seemed to function correctly. I
hope this helps.

Jason
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] TACACS Authorisation sessions across reloads in 4.9

2012-06-08 Thread Jason Griffith
Hi Patrik,

I had feedback (By the way, thanks to Mike for that!) stating that the only
problems were the loss of specific AV pairs specified in the local users
file if this is used, and the fact that I removed the DEFAULT group from
the code.

In the limited time that I have been working on it I have solved the
DEFAULT group issue by putting it back and adding another check, but I am
still working on the local user attributes which is a bit more tricky for
me.

I'll share my changes once complete. No word on whether this will ever be
officially fixed, but I didn't specifically ask.

Jason

On Fri, Jun 8, 2012 at 8:32 AM, Patrik Forsberg
wrote:

> Hello,
>
> ** **
>
> Sorry for being slow to answer this!
>
> This is exactly the functionality I wished for.
>
> One thing thou. Is it possible to modify the 24 hour limit to follow
> “AuthorizationTimeout” clause instead of a static value ?
>
> ** **
>
> What’s the word from OSC ? is it possible that this could find its way
> into a patchset or next release ?
>
> Or does it break something unforeseen ?
>
> ** **
>
> Mvh,
>
> Patrik Forsberg
>
> ** **
>
> *From:* radiator-boun...@open.com.au [mailto:radiator-boun...@open.com.au]
> *On Behalf Of *Jason Griffith
> *Sent:* Wednesday, May 30, 2012 8:45 PM
> *To:* radiator@open.com.au
> *Subject:* [RADIATOR] TACACS Authorisation sessions across reloads in 4.9*
> ***
>
> ** **
>
> Hello,
>
> ** **
>
> I've recently been toying with Radiator 4.9 as we are planning on
> upgrading from 4.5 and have come across this TACACS+ session issue where
> command authorisations fail after Radiator is reloaded even when the
> session is saved to the temporary TACACS sessions file. I could not get
> this to function correctly with standard configuration listed in the manual.
> 
>
> ** **
>
> As I can't compromise on the frequency of Radiator reloads due to our
> integration with other upstream systems, I instead modified the
> Radius/ServerTACACSPLUS.pm file (see attached). I've done a couple of
> things here - move the check for a valid context to after the point where
> the temporary file is read; and also added a timestamp to the session file
> so that any sessions older than 24 hours will not authorise.
> My initial testing of this is positive and I have not come across anything
> unexpected.
>
> ** **
>
> My question to the group is - are there any side effects to this of which
> I may not be aware of or any other features that I'm not using right now
> that may be broken? Being only familiar with the features we use and our
> other customisations I thought it best to throw this out there.
>
> ** **
>
> Thanks for any feed back.
>
> ** **
>
> Jason Griffith
>
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
>
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator