Re: [RADIATOR] Authorizing users via TACACS for Juniper Netscreens
Hello Craig -
There are several steps:
1. define the AuthorizeGroup’s you require
2. specify the return attributes you need for each AuthorizeGroup (syntax will
depend on the specific device)
3. perform the authentication and set which AuthorizeGroup the user belongs to
…..
See the examples in section 5.96.10 in the Radiator 4.13 reference manual
(“doc/ref.pdf”).
See also the examples in “goodies/tacacsplusserver.cfg” and
“goodies/tacplus.txt”.
regards
Hugh
On 25 Jun 2014, at 10:51, Craig Ayliffe wrote:
> Hi Hugh,
>
> Actually I was looking for a way to set the vsys/privilege to restrict what a
> user can do.
>
> i.e. wanted to do something like this:
> AuthorizeGroup READ permit service=netscreen {vsys=root
> privilege=read-only}
> AuthorizeGroup WRITE permit service=netscreen {vsys=root privilege=root}
>
> Or do I need to use something like AuthorizeAdd/AuthorizeReplace to pass back
> attribute-value pairs?
>
> Regards,
>
> Craig
>
> -Original Message-
> From: Hugh Irvine [mailto:h...@open.com.au]
> Sent: Wednesday, 25 June 2014 8:39 AM
> To: Craig Ayliffe
> Cc: radiator@open.com.au
> Subject: Re: [RADIATOR] Authorizing users via TACACS for Juniper Netscreens
>
>
> Hello Craig -
>
> The usual way to do this is with Identifiers in the Client clauses and
> Handlers to match.
>
> Something like this:
>
>
> .
>
>
> Identifier JuniperNetscreen
> Secret .
> .
>
>
>
> Identifier JuniperNetscreen
> Secret .
> .
>
>
>
> Identifier JuniperNetscreen
> Secret .
> .
>
>
> .
>
>
>
>
> .
>
>
>
>
> .
>
> hope that helps
>
> regards
>
> Hugh
>
>
> On 24 Jun 2014, at 23:24, Craig Ayliffe
> wrote:
>
>> Hi,
>>
>> I am looking for examples of Radiator configuration to restrict users
>> logging into Juniper Netscreens running ScreenOS 6.3 and higher.
>>
>> Need to be able to specify the vsys to be Root and the privilege to be
>> either 'root' or 'read-only' depending of their AuthorizeGroup configuration.
>>
>> Haven't been able to find any examples anywhere.
>> Would appreciate any assistance.
>>
>> Regards,
>>
>> Craig
>>
>> Craig Ayliffe | Brennan IT | Infrastructure Engineer
>>
>> T: 02 8235 3515 | M: 0410 400 546 | craig.ayli...@brennanit.com.au |
>> www.brennanit.com.au
>>
>>
>> ___
>> radiator mailing list
>> radiator@open.com.au
>> http://www.open.com.au/mailman/listinfo/radiator
>
>
> --
>
> Hugh Irvine
> h...@open.com.au
>
> Radiator: the most portable, flexible and configurable RADIUS server
> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
> Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
> TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
> DIAMETER, SIM, etc.
> Full source on Unix, Linux, Windows, MacOSX, Solaris, VMS, NetWare etc.
>
--
Hugh Irvine
h...@open.com.au
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER, SIM, etc.
Full source on Unix, Linux, Windows, MacOSX, Solaris, VMS, NetWare etc.
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Authorizing users via TACACS for Juniper Netscreens
Hi Hugh,
Actually I was looking for a way to set the vsys/privilege to restrict what a
user can do.
i.e. wanted to do something like this:
AuthorizeGroup READ permit service=netscreen {vsys=root
privilege=read-only}
AuthorizeGroup WRITE permit service=netscreen {vsys=root privilege=root}
Or do I need to use something like AuthorizeAdd/AuthorizeReplace to pass back
attribute-value pairs?
Regards,
Craig
-Original Message-
From: Hugh Irvine [mailto:h...@open.com.au]
Sent: Wednesday, 25 June 2014 8:39 AM
To: Craig Ayliffe
Cc: radiator@open.com.au
Subject: Re: [RADIATOR] Authorizing users via TACACS for Juniper Netscreens
Hello Craig -
The usual way to do this is with Identifiers in the Client clauses and Handlers
to match.
Something like this:
.
Identifier JuniperNetscreen
Secret .
.
Identifier JuniperNetscreen
Secret .
.
Identifier JuniperNetscreen
Secret .
.
.
.
.
hope that helps
regards
Hugh
On 24 Jun 2014, at 23:24, Craig Ayliffe wrote:
> Hi,
>
> I am looking for examples of Radiator configuration to restrict users logging
> into Juniper Netscreens running ScreenOS 6.3 and higher.
>
> Need to be able to specify the vsys to be Root and the privilege to be either
> 'root' or 'read-only' depending of their AuthorizeGroup configuration.
>
> Haven't been able to find any examples anywhere.
> Would appreciate any assistance.
>
> Regards,
>
> Craig
>
> Craig Ayliffe | Brennan IT | Infrastructure Engineer
>
> T: 02 8235 3515 | M: 0410 400 546 | craig.ayli...@brennanit.com.au |
> www.brennanit.com.au
>
>
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
--
Hugh Irvine
h...@open.com.au
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER, SIM, etc.
Full source on Unix, Linux, Windows, MacOSX, Solaris, VMS, NetWare etc.
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Authorizing users via TACACS for Juniper Netscreens
Hello Craig - The usual way to do this is with Identifiers in the Client clauses and Handlers to match. Something like this: ….. Identifier JuniperNetscreen Secret ….. ….. Identifier JuniperNetscreen Secret ….. ….. Identifier JuniperNetscreen Secret ….. ….. ….. ….. ….. hope that helps regards Hugh On 24 Jun 2014, at 23:24, Craig Ayliffe wrote: > Hi, > > I am looking for examples of Radiator configuration to restrict users logging > into Juniper Netscreens running ScreenOS 6.3 and higher. > > Need to be able to specify the vsys to be Root and the privilege to be either > ‘root’ or ‘read-only’ depending of their AuthorizeGroup configuration. > > Haven’t been able to find any examples anywhere. > Would appreciate any assistance. > > Regards, > > Craig > > Craig Ayliffe | Brennan IT | Infrastructure Engineer > > T: 02 8235 3515 | M: 0410 400 546 | craig.ayli...@brennanit.com.au | > www.brennanit.com.au > > > ___ > radiator mailing list > radiator@open.com.au > http://www.open.com.au/mailman/listinfo/radiator -- Hugh Irvine h...@open.com.au Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER, SIM, etc. Full source on Unix, Linux, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
[RADIATOR] overlapping Client clauses
It would be nice if the manual documented what happens when an incoming request is potentially capable of matching more than one Client clause. Here's what I've figured out on my own (as of 4.13), in case it helps others in the meanwhile: * If multiple Client clauses have an exact match (same IP, or hostnames resolving to same IP), the *last* one listed in the configuration wins. * Any exact match beats any CIDR match. and it also looks like, but I haven't tested: * A longer-prefix CIDR match beats a shorter-prefix CIDR match. * If multiple Client clauses have the same CIDR, the *last* one listed in the configuration wins. * A CIDR match beats a MAC match. Thanks, David P.S. Yes, it's probably a better idea to avoid having overlaps in the first place, but sometimes that's a lot of extra work. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
