Re: [RADIATOR] Ideas on group and reply attribs parsing
On 04/06/2013 03:58 PM, Garry Shtern wrote: > That's an excellent idea! Good to hear it's solved. > In my case the SQLite DB doesn't even need > to be writable by the radiator user. I put my users and clients into > that database, and created custom SQL queries and everything works > perfectly. Sounds a bit like the case I was referring to where SQLite DB is used for AuthBy SQLRADIUS. In this case an external process updates SQLite DB and maintains list of realms and next hop servers for proxying. Like in your case, the DB file itself is read-only for radiusd process. Thanks, Heikki -- Heikki Vatiainen 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 etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list [email protected] http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Ideas on group and reply attribs parsing
Hi Heikki, That's an excellent idea! In my case the SQLite DB doesn't even need to be writable by the radiator user. I put my users and clients into that database, and created custom SQL queries and everything works perfectly. Thanks a lot! -Original Message- From: [email protected] [mailto:[email protected]] On Behalf Of Heikki Vatiainen Sent: Friday, April 05, 2013 4:53 PM To: [email protected] Subject: Re: [RADIATOR] Ideas on group and reply attribs parsing On 04/05/2013 11:17 PM, Garry Shtern wrote: > I am not quite clear on how this would help me. Fall-Through controls > whether we will continue looking even after a REJECT. That's not what > I want. I am looking to augment AuthBy FILE to match against the > groups that we retrieved in AuthBy LDAP2. I want to return as soon as > the first Group= is matched and reject if none are matched... How about this approach: Create a SQLite DB from the information and use AuthBy SQL instead. I have a couple of cases where information is kept in an frequently read but less infrequently (e.g., twice per hour) SQLite DB. Works very well. Thanks, Heikki -- Heikki Vatiainen 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 etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list [email protected] http://www.open.com.au/mailman/listinfo/radiator ___ radiator mailing list [email protected] http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Ideas on group and reply attribs parsing
Hi Hugh, I see how this can be useful to having a hirercical user structure in providing aggregate reply attributes back. However, in my case, there is no hierarchy - I simply want to match a single user entry based on all Check parameters with the ability to skip over the attributes that the AuthBy doesn't handle. As it stands now, if the AuthBY doesn't know how to handle Group attribute, it rejects instead of just ignoring that check. Thanks! -Original Message- From: Hugh Irvine [mailto:[email protected]] Sent: Friday, April 05, 2013 5:55 PM To: Garry Shtern Cc: 'Heikki Vatiainen'; [email protected] Subject: Re: [RADIATOR] Ideas on group and reply attribs parsing Hello Garry - Actually, Fall-Through continues after an ACCEPT. For example, this users file: DEFAULT User-Name = hugh, Password = hugh Fall-Through = yes DEFAULT Reply-Message = "hello, world" produces this: Radiator-4.11 hugh$ perl radpwtst -noacct -user hugh -password hugh sending Access-Request... Sat Apr 6 08:48:36 2013: DEBUG: Packet dump: *** Received from 127.0.0.1 port 60920 Code: Access-Request Identifier: 171 Authentic: ;<208><135><228><181><134><4><251><23><238><4>`<167>Q0<174> Attributes: User-Name = "hugh" Service-Type = Framed-User NAS-IP-Address = 203.63.154.1 NAS-Identifier = "203.63.154.1" NAS-Port = 1234 Called-Station-Id = "123456789" Calling-Station-Id = "987654321" NAS-Port-Type = Async User-Password = q<22>a<130>)3<10><135><138>-<196><23><19><195><178><9> Sat Apr 6 08:48:36 2013: DEBUG: Handling request with Handler 'Realm=DEFAULT', Identifier '' Sat Apr 6 08:48:36 2013: DEBUG: Deleting session for hugh, 203.63.154.1, 1234 Sat Apr 6 08:48:36 2013: DEBUG: Handling with Radius::AuthFILE: Sat Apr 6 08:48:36 2013: DEBUG: Reading users file ./users.default Sat Apr 6 08:48:36 2013: DEBUG: Radius::AuthFILE looks for match with hugh [hugh] Sat Apr 6 08:48:36 2013: DEBUG: Radius::AuthFILE REJECT: No such user: hugh [hugh] Sat Apr 6 08:48:36 2013: DEBUG: Radius::AuthFILE looks for match with DEFAULT [hugh] Sat Apr 6 08:48:36 2013: DEBUG: Radius::AuthFILE ACCEPT: : DEFAULT [hugh] Sat Apr 6 08:48:36 2013: DEBUG: Radius::AuthFILE looks for match with DEFAULT1 [hugh] Sat Apr 6 08:48:36 2013: DEBUG: Radius::AuthFILE ACCEPT: : DEFAULT1 [hugh] Sat Apr 6 08:48:36 2013: DEBUG: AuthBy FILE result: ACCEPT, Sat Apr 6 08:48:36 2013: DEBUG: Access accepted for hugh Sat Apr 6 08:48:36 2013: DEBUG: Packet dump: *** Sending to 127.0.0.1 port 60920 Code: Access-Accept Identifier: 171 Authentic: `<155><231>rR<0><239>+<168><130><12><147><22><217><4><148> Attributes: Reply-Message = "hello, world" OK This is how you can cause multiple DEFAULT entries in the users file to be processed. regards Hugh On 6 Apr 2013, at 07:17, Garry Shtern wrote: > Hi Hugh, > > I am not quite clear on how this would help me. Fall-Through controls > whether we will continue looking even after a REJECT. That's not what I want. > I am looking to augment AuthBy FILE to match against the groups that we > retrieved in AuthBy LDAP2. I want to return as soon as the first Group= is > matched and reject if none are matched... > > Thanks, > > -Original Message- > From: Hugh Irvine [mailto:[email protected]] > Sent: Friday, April 05, 2013 3:30 AM > To: Garry Shtern > Cc: 'Heikki Vatiainen'; [email protected] > Subject: Re: [RADIATOR] Ideas on group and reply attribs parsing > > > Hi Garry - > > You probably want "Fall-Through" in your first set of DEFAULT entries. > > See the following section in "doc/ref.pdf": > > > 13.2.7 Fall-Through > > This attribute is not actually returned to the NAS. Its presence causes > Radiator to continue looking for a match with the next DEFAULT user name. > >Fall-Through = yes > > > regards > > Hugh > > > On 5 Apr 2013, at 08:04, Garry Shtern wrote: > >> I actually did. It's similar to what I want to do, with the exception of >> the fact that I want to store the group to reply mappings in local files, >> rather than SQL server. >> >> I am thinking of using a hook to create a "userIsInGroup" function local to >> AuthBy FILE. What do you think? >> >> -Original Message- >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Heikki Vatiainen >
Re: [RADIATOR] Ideas on group and reply attribs parsing
Hello Garry - Actually, Fall-Through continues after an ACCEPT. For example, this users file: DEFAULT User-Name = hugh, Password = hugh Fall-Through = yes DEFAULT Reply-Message = "hello, world" produces this: Radiator-4.11 hugh$ perl radpwtst -noacct -user hugh -password hugh sending Access-Request... Sat Apr 6 08:48:36 2013: DEBUG: Packet dump: *** Received from 127.0.0.1 port 60920 Code: Access-Request Identifier: 171 Authentic: ;<208><135><228><181><134><4><251><23><238><4>`<167>Q0<174> Attributes: User-Name = "hugh" Service-Type = Framed-User NAS-IP-Address = 203.63.154.1 NAS-Identifier = "203.63.154.1" NAS-Port = 1234 Called-Station-Id = "123456789" Calling-Station-Id = "987654321" NAS-Port-Type = Async User-Password = q<22>a<130>)3<10><135><138>-<196><23><19><195><178><9> Sat Apr 6 08:48:36 2013: DEBUG: Handling request with Handler 'Realm=DEFAULT', Identifier '' Sat Apr 6 08:48:36 2013: DEBUG: Deleting session for hugh, 203.63.154.1, 1234 Sat Apr 6 08:48:36 2013: DEBUG: Handling with Radius::AuthFILE: Sat Apr 6 08:48:36 2013: DEBUG: Reading users file ./users.default Sat Apr 6 08:48:36 2013: DEBUG: Radius::AuthFILE looks for match with hugh [hugh] Sat Apr 6 08:48:36 2013: DEBUG: Radius::AuthFILE REJECT: No such user: hugh [hugh] Sat Apr 6 08:48:36 2013: DEBUG: Radius::AuthFILE looks for match with DEFAULT [hugh] Sat Apr 6 08:48:36 2013: DEBUG: Radius::AuthFILE ACCEPT: : DEFAULT [hugh] Sat Apr 6 08:48:36 2013: DEBUG: Radius::AuthFILE looks for match with DEFAULT1 [hugh] Sat Apr 6 08:48:36 2013: DEBUG: Radius::AuthFILE ACCEPT: : DEFAULT1 [hugh] Sat Apr 6 08:48:36 2013: DEBUG: AuthBy FILE result: ACCEPT, Sat Apr 6 08:48:36 2013: DEBUG: Access accepted for hugh Sat Apr 6 08:48:36 2013: DEBUG: Packet dump: *** Sending to 127.0.0.1 port 60920 Code: Access-Accept Identifier: 171 Authentic: `<155><231>rR<0><239>+<168><130><12><147><22><217><4><148> Attributes: Reply-Message = "hello, world" OK This is how you can cause multiple DEFAULT entries in the users file to be processed. regards Hugh On 6 Apr 2013, at 07:17, Garry Shtern wrote: > Hi Hugh, > > I am not quite clear on how this would help me. Fall-Through controls > whether we will continue looking even after a REJECT. That's not what I want. > I am looking to augment AuthBy FILE to match against the groups that we > retrieved in AuthBy LDAP2. I want to return as soon as the first Group= is > matched and reject if none are matched... > > Thanks, > > -Original Message- > From: Hugh Irvine [mailto:[email protected]] > Sent: Friday, April 05, 2013 3:30 AM > To: Garry Shtern > Cc: 'Heikki Vatiainen'; [email protected] > Subject: Re: [RADIATOR] Ideas on group and reply attribs parsing > > > Hi Garry - > > You probably want "Fall-Through" in your first set of DEFAULT entries. > > See the following section in "doc/ref.pdf": > > > 13.2.7 Fall-Through > > This attribute is not actually returned to the NAS. Its presence causes > Radiator to continue looking for a match with the next DEFAULT user name. > >Fall-Through = yes > > > regards > > Hugh > > > On 5 Apr 2013, at 08:04, Garry Shtern wrote: > >> I actually did. It's similar to what I want to do, with the exception of >> the fact that I want to store the group to reply mappings in local files, >> rather than SQL server. >> >> I am thinking of using a hook to create a "userIsInGroup" function local to >> AuthBy FILE. What do you think? >> >> -Original Message- >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Heikki Vatiainen >> Sent: Thursday, April 04, 2013 4:47 PM >> To: [email protected] >> Subject: Re: [RADIATOR] Ideas on group and reply attribs parsing >> >> On 04/04/2013 11:24 PM, Garry Shtern wrote: >> >>> Thanks for the pointer. What I want to accomplish (forgetting about >>> the actual code), it define all of my users in a single file. And in >>> the same file to be able to distinguish which reply attributes are >>> returned based on the RADIUS client. >> >> It's getting a bit late here, so I'll now just ask if you have noticed >> goodies/lookupauthgroup.pl? It uses SQL, but could st
Re: [RADIATOR] Ideas on group and reply attribs parsing
On 04/05/2013 11:17 PM, Garry Shtern wrote: > I am not quite clear on how this would help me. Fall-Through > controls whether we will continue looking even after a REJECT. That's > not what I want. I am looking to augment AuthBy FILE to match > against the groups that we retrieved in AuthBy LDAP2. I want to > return as soon as the first Group= is matched and reject if none are > matched... How about this approach: Create a SQLite DB from the information and use AuthBy SQL instead. I have a couple of cases where information is kept in an frequently read but less infrequently (e.g., twice per hour) SQLite DB. Works very well. Thanks, Heikki -- Heikki Vatiainen 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 etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list [email protected] http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Ideas on group and reply attribs parsing
Hi Hugh, I am not quite clear on how this would help me. Fall-Through controls whether we will continue looking even after a REJECT. That's not what I want. I am looking to augment AuthBy FILE to match against the groups that we retrieved in AuthBy LDAP2. I want to return as soon as the first Group= is matched and reject if none are matched... Thanks, -Original Message- From: Hugh Irvine [mailto:[email protected]] Sent: Friday, April 05, 2013 3:30 AM To: Garry Shtern Cc: 'Heikki Vatiainen'; [email protected] Subject: Re: [RADIATOR] Ideas on group and reply attribs parsing Hi Garry - You probably want "Fall-Through" in your first set of DEFAULT entries. See the following section in "doc/ref.pdf": 13.2.7 Fall-Through This attribute is not actually returned to the NAS. Its presence causes Radiator to continue looking for a match with the next DEFAULT user name. Fall-Through = yes regards Hugh On 5 Apr 2013, at 08:04, Garry Shtern wrote: > I actually did. It's similar to what I want to do, with the exception of the > fact that I want to store the group to reply mappings in local files, rather > than SQL server. > > I am thinking of using a hook to create a "userIsInGroup" function local to > AuthBy FILE. What do you think? > > -Original Message- > From: [email protected] > [mailto:[email protected]] On Behalf Of Heikki Vatiainen > Sent: Thursday, April 04, 2013 4:47 PM > To: [email protected] > Subject: Re: [RADIATOR] Ideas on group and reply attribs parsing > > On 04/04/2013 11:24 PM, Garry Shtern wrote: > >> Thanks for the pointer. What I want to accomplish (forgetting about >> the actual code), it define all of my users in a single file. And in >> the same file to be able to distinguish which reply attributes are >> returned based on the RADIUS client. > > It's getting a bit late here, so I'll now just ask if you have noticed > goodies/lookupauthgroup.pl? It uses SQL, but could still be useful as another > pointer. > > Thanks, > Heikki > > -- > Heikki Vatiainen > > 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 etc. Full > source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. > ___ > radiator mailing list > [email protected] > http://www.open.com.au/mailman/listinfo/radiator > ___ > radiator mailing list > [email protected] > http://www.open.com.au/mailman/listinfo/radiator -- Hugh Irvine [email protected] 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 etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list [email protected] http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Ideas on group and reply attribs parsing
Hi Garry - You probably want "Fall-Through" in your first set of DEFAULT entries. See the following section in "doc/ref.pdf": 13.2.7 Fall-Through This attribute is not actually returned to the NAS. Its presence causes Radiator to continue looking for a match with the next DEFAULT user name. Fall-Through = yes regards Hugh On 5 Apr 2013, at 08:04, Garry Shtern wrote: > I actually did. It's similar to what I want to do, with the exception of the > fact that I want to store the group to reply mappings in local files, rather > than SQL server. > > I am thinking of using a hook to create a "userIsInGroup" function local to > AuthBy FILE. What do you think? > > -Original Message- > From: [email protected] [mailto:[email protected]] On > Behalf Of Heikki Vatiainen > Sent: Thursday, April 04, 2013 4:47 PM > To: [email protected] > Subject: Re: [RADIATOR] Ideas on group and reply attribs parsing > > On 04/04/2013 11:24 PM, Garry Shtern wrote: > >> Thanks for the pointer. What I want to accomplish (forgetting about >> the actual code), it define all of my users in a single file. And in >> the same file to be able to distinguish which reply attributes are >> returned based on the RADIUS client. > > It's getting a bit late here, so I'll now just ask if you have noticed > goodies/lookupauthgroup.pl? It uses SQL, but could still be useful as another > pointer. > > Thanks, > Heikki > > -- > Heikki Vatiainen > > 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 etc. Full > source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. > ___ > radiator mailing list > [email protected] > http://www.open.com.au/mailman/listinfo/radiator > ___ > radiator mailing list > [email protected] > http://www.open.com.au/mailman/listinfo/radiator -- Hugh Irvine [email protected] 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 etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list [email protected] http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Ideas on group and reply attribs parsing
I actually did. It's similar to what I want to do, with the exception of the fact that I want to store the group to reply mappings in local files, rather than SQL server. I am thinking of using a hook to create a "userIsInGroup" function local to AuthBy FILE. What do you think? -Original Message- From: [email protected] [mailto:[email protected]] On Behalf Of Heikki Vatiainen Sent: Thursday, April 04, 2013 4:47 PM To: [email protected] Subject: Re: [RADIATOR] Ideas on group and reply attribs parsing On 04/04/2013 11:24 PM, Garry Shtern wrote: > Thanks for the pointer. What I want to accomplish (forgetting about > the actual code), it define all of my users in a single file. And in > the same file to be able to distinguish which reply attributes are > returned based on the RADIUS client. It's getting a bit late here, so I'll now just ask if you have noticed goodies/lookupauthgroup.pl? It uses SQL, but could still be useful as another pointer. Thanks, Heikki -- Heikki Vatiainen 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 etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list [email protected] http://www.open.com.au/mailman/listinfo/radiator ___ radiator mailing list [email protected] http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Ideas on group and reply attribs parsing
On 04/04/2013 11:24 PM, Garry Shtern wrote: > Thanks for the pointer. What I want to accomplish (forgetting about > the actual code), it define all of my users in a single file. And in > the same file to be able to distinguish which reply attributes are > returned based on the RADIUS client. It's getting a bit late here, so I'll now just ask if you have noticed goodies/lookupauthgroup.pl? It uses SQL, but could still be useful as another pointer. Thanks, Heikki -- Heikki Vatiainen 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 etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list [email protected] http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Ideas on group and reply attribs parsing
Hi Heikki,
Thanks for the pointer. What I want to accomplish (forgetting about the actual
code), it define all of my users in a single file. And in the same file to be
able to distinguish which reply attributes are returned based on the RADIUS
client. That is, for example, if a user from a group "foo" tries to access the
system using Aruba controller, then Reply Attribute might be
Aruba-Priv-Admin-User=1. Whereas, a different user who is part of a group
"bar" comes via the same Aruba controller, then Reply Attribute might be
Aruba-Priv-Admin-User=2. Additionally, if the is part of group "foo" but tries
to access the system via a Cisco switch, he might get a Reply Attribute
"Cisco-Account-Info=blah", and so on and so forth.
I can't seem to figure out how to do it in a single user fie. The closest I
came to was similar to what you are describing:
AuthByPolicy ContinueWhileAccept
AuthBy krb-ldap-auth (AuthBY GROUP)
AuthBy file-auth
Then in ldap-auth, I force retrieval of all groups that the user belongs to
into a User-Groups comma-separated attribute.
PostSearchHook sub { $_[2]->add_attr('User-Groups',
join(',',$_[0]->getUserGroups($_[1], $_[2]))); }
However, now comes the dilemma of forcing to match on individual
group from the above list. I am thinking of something like this in the user
file
DEFAULT Client-Identifier=aruba-controller Group=foo
Aruba-Priv-Admin-User=1
DEFAULT Client-Identifier=aruba-controller Group=bar
Aruba-Priv-Admin-User=2
DEFAULT Client-identifier=cisco-switch Group=foo
Cisco-Account-Info=blah
But, doesn't deal with groups by default, and I am not sure how
to force to loop through all of the groups in User-Groups
Thanks!
-Original Message-
From: [email protected] [mailto:[email protected]] On
Behalf Of Heikki Vatiainen
Sent: Thursday, April 04, 2013 3:53 PM
To: [email protected]
Subject: Re: [RADIATOR] Ideas on group and reply attribs parsing
On 04/04/2013 03:40 PM, Garry Shtern wrote:
> I am trying to accomplish the following goal and would love ideas on
> the best way to accomplish it...
Have you considered something like:
AuthByPolicy ContinueWhileAccept
AuthBy krb-auth
AuthBy ldap-auth
# If still here, have authenticated and have group
Filename users
AuthenticateAttribute Group
Where 'users' may look like this:
group1
Custom-Attribute=1
group2
Custom-Attribute=2
You are describing the problem in terms of configuration you are thinking about
and this makes it quite hard for me to follow. Bouncing off from AuthBy FILE
with Auth-Type check item seems quite complex and I'm thinking there's probably
an easier way to do this.
Thanks,
Heikki
> - Setup clients with identifiers.
>
> - In the user file specify multiple defaults, with
> Client-Identifier, Auth-Type and optional Group attributes in check
> replies, and different reply attributes.
>
> - Defined custom AuthBy with identifiers in the policy file.
>
>
>
> Example:
>
> (users)
>
> DEFAULT Client-Identifier=abc, Auth-Type=Krb-Ldap, Group=grp1
>
> Custom-Attribute=1
>
>
>
> DEFAULT Client-Identifier=abc, Auth-Type Krb-Ldap, Group=grp2
>
> Custom-Attribute=2
>
>
>
> (policy)
>
>
>
> Identifier Ldap
>
> ...
>
>
>
>
>
>
>
> Identifier Krb
>
> ...
>
>
>
>
>
>
>
> Identifier Krb-Ldap
>
> AuthByPolicy ContinueWhileAccept
>
> AuthBy krb-auth
>
> AuthBy ldap-auth
>
>
>
>
>
> I want the following:
>
> - Auth-TypeKrb-Ldap called only _once_, which will verify the
> user's password and retrieve all the groups he is part of.
>
> - Parse users file, matching the first DEFAULT where Group
> matches one of the groups that were retrieved above.
>
> - Have AuthBy's that don't support Groups check just ignore it,
> instead of returning a reject.
>
>
>
> Thanks!
>
>
>
>
>
> ___
> radiator mailing list
> [email protected]
> http://www.open.com.au/mailman/listinfo/radiator
>
--
Heikki Vatiainen
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 etc. Full source on Unix,
Windows, MacOSX, Solaris, VMS, NetWare etc.
___
radiator mailing list
[email protected]
http://www.open.com.au/mailman/listinfo/radiator
___
radiator mailing list
[email protected]
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Ideas on group and reply attribs parsing
On 04/04/2013 03:40 PM, Garry Shtern wrote: > I am trying to accomplish the following goal and would love ideas on the > best way to accomplish it… Have you considered something like: AuthByPolicy ContinueWhileAccept AuthBy krb-auth AuthBy ldap-auth # If still here, have authenticated and have group Filename users AuthenticateAttribute Group Where 'users' may look like this: group1 Custom-Attribute=1 group2 Custom-Attribute=2 You are describing the problem in terms of configuration you are thinking about and this makes it quite hard for me to follow. Bouncing off from AuthBy FILE with Auth-Type check item seems quite complex and I'm thinking there's probably an easier way to do this. Thanks, Heikki > - Setup clients with identifiers. > > - In the user file specify multiple defaults, with > Client-Identifier, Auth-Type and optional Group attributes in check > replies, and different reply attributes. > > - Defined custom AuthBy with identifiers in the policy file. > > > > Example: > > (users) > > DEFAULT Client-Identifier=abc, Auth-Type=Krb-Ldap, Group=grp1 > > Custom-Attribute=1 > > > > DEFAULT Client-Identifier=abc, Auth-Type Krb-Ldap, Group=grp2 > > Custom-Attribute=2 > > > > (policy) > > > > Identifier Ldap > > … > > > > > > > > Identifier Krb > > … > > > > > > > > Identifier Krb-Ldap > > AuthByPolicy ContinueWhileAccept > > AuthBy krb-auth > > AuthBy ldap-auth > > > > > > I want the following: > > - Auth-TypeKrb-Ldap called only _once_, which will verify the > user’s password and retrieve all the groups he is part of. > > - Parse users file, matching the first DEFAULT where Group > matches one of the groups that were retrieved above. > > - Have AuthBy’s that don’t support Groups check just ignore it, > instead of returning a reject. > > > > Thanks! > > > > > > ___ > radiator mailing list > [email protected] > http://www.open.com.au/mailman/listinfo/radiator > -- Heikki Vatiainen 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 etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list [email protected] http://www.open.com.au/mailman/listinfo/radiator
