(RADIATOR) Client identifier

Hugh Irvine hugh at open.com.au
Tue May 20 17:48:47 CDT 2008 

Hello Henning -

Unfortunately no - the first match is the only match.

As mentioned in my previous mail however, if you send me a couple of  
example access requests from the trace 4 debug I'll take another look.

regards

Hugh


On 20 May 2008, at 21:05, Henning Markussen wrote:

> Hi
>
> Hmm ... ok
>
> what if I used the default clause twice?
>
> Would it then first try the first client section, it fails
> and then try the second client section?
>
> <Client DEFAULT>
>     Secret verysecret1
>     Identifier other
> </Client>
>
> <Client DEFAULT>
>     Secret verysecret2
>     Identifier Default
> </Client>
>
> and then afterwards use the handler section to make user validation  
> etc.
>
> - Henning
>
> Hugh Irvine wrote:
>> Hello Henning -
>> Unfortunately there is no way to check multiple shared secrets -  
>> Radiator has no way of knowing if the shared secret is correct or  
>> not (indeed the RADIUS protocol has no way of knowing). And  
>> further, the correct shared secret is required for the reply to  
>> the particular client device.
>> I'm afraid I can't really think of any way to do what you  
>> describe, but if you could send me a sample trace 4 debug from  
>> Radiator showing a couple of typical access requests from a couple  
>> of different devices, I'll have another look.
>> regards
>> Hugh
>> On 20 May 2008, at 14:08, Henning Markussen wrote:
>>> Hello
>>>
>>> My plan was to check with a external script in the handler  
>>> section if a person was member of a specific group.
>>>
>>> <Handler Client-Identifier = other>
>>> check that user is member of group20
>>> </Handler>
>>>
>>> <Handler Client-Identifier = Default>
>>> check that user is member of group10
>>> </Handler>
>>>
>>> so if the device uses "Secret verysecret1", the user must be a  
>>> member of the group1 to logon, and if the device uses "Secret  
>>> verysecret2" you have to be a member of group10.
>>>
>>> This is just simple part, but this give give the option to check  
>>> for a lot of other things after I check if a user is a member of  
>>> that specific group.
>>>
>>> This was the only plan I had to determine if a device was in  
>>> group a or b. Might not be the best way - so that is why the mail  
>>> to the maillist.
>>>
>>> My problem is again that I don't have a complete list of all the  
>>> devices , and I was hoping to make it as flexible so that people  
>>> can just change the secret and I didn't have to have a list of  
>>> all the ipadresses to maintain afterwards. And that is way I  
>>> looked at secret to find the difference.
>>>
>>> If you have any other questions just let me know.
>>>
>>> - Henning
>>>
>>> Hugh Irvine wrote:
>>>> Hello Henning -
>>>> How are you going to know which people are allowed to log in to  
>>>> which device?
>>>> I think you may need to do the check as part of the  
>>>> authentication rather than by using the Client-Identifier.
>>>> If you can give me a bit more information I will try to make a  
>>>> better suggestion.
>>>> regards
>>>> Hugh
>>>> On 19 May 2008, at 20:02, Henning Markussen wrote:
>>>>> Hello
>>>>>
>>>>> I have a task where i need to separate a lot of network  
>>>>> devices, who is
>>>>> allowed to logon, and who is not.
>>>>>
>>>>> The problem is that I don't have a list of all the ip addresses
>>>>> Currently I'm using this setup to handle all devices the same.
>>>>>
>>>>> <Client DEFAULT>
>>>>>       Secret xxxx
>>>>>       Identifier Default
>>>>> </Client>
>>>>>
>>>>> and then later the
>>>>> <Handler Client-Identifier = Default>
>>>>> </Handler>
>>>>>
>>>>> Since I don't have a complete list of ip adresses, my plan was  
>>>>> maybe to
>>>>> use diffrent secrets.
>>>>>
>>>>> <Client other>
>>>>>       Secret verysecret1
>>>>>       Identifier other
>>>>> </Client>
>>>>>
>>>>> <Client DEFAULT>
>>>>>       Secret verysecret1
>>>>>       Identifier Default
>>>>> </Client>
>>>>>
>>>>>
>>>>> and then
>>>>>
>>>>> <Handler Client-Identifier = other>
>>>>> do something
>>>>> </Handler>
>>>>>
>>>>> <Handler Client-Identifier = Default>
>>>>> do something
>>>>> </Handler>
>>>>>
>>>>> But it seems that the Client part, has to be ip specific or the  
>>>>> default
>>>>> class.
>>>>>
>>>>> I looked at IdenticalClients, but that again comes back to the  
>>>>> problem
>>>>> that I don't have a complete ip list.
>>>>>
>>>>> Is there a other way/option/approach that I have missed?
>>>>> Or any other ideas ....
>>>>>
>>>>> - Henning
>>>>>
>>>>> -- 
>>>>> Archive at http://www.open.com.au/archives/radiator/
>>>>> Announcements on radiator-announce at open.com.au
>>>>> To unsubscribe, email 'majordomo at open.com.au' with
>>>>> 'unsubscribe radiator' in the body of the message.
>>>> NB:
>>>> Have you read the reference manual ("doc/ref.html")?
>>>> Have you searched the mailing list archive (www.open.com.au/ 
>>>> archives/radiator)?
>>>> Have you had a quick look on Google (www.google.com)?
>>>> Have you included a copy of your configuration file (no secrets),
>>>> together with a trace 4 debug showing what is happening?
>>>> Have you checked the RadiusExpert wiki:
>>>> http://www.open.com.au/wiki/index.php/Main_Page
>> NB:
>> Have you read the reference manual ("doc/ref.html")?
>> Have you searched the mailing list archive (www.open.com.au/ 
>> archives/radiator)?
>> Have you had a quick look on Google (www.google.com)?
>> Have you included a copy of your configuration file (no secrets),
>> together with a trace 4 debug showing what is happening?
>> Have you checked the RadiusExpert wiki:
>> http://www.open.com.au/wiki/index.php/Main_Page



NB:

Have you read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive (www.open.com.au/archives/ 
radiator)?
Have you had a quick look on Google (www.google.com)?
Have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?
Have you checked the RadiusExpert wiki:
http://www.open.com.au/wiki/index.php/Main_Page

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
Includes support for reliable RADIUS transport (RadSec),
and DIAMETER translation agent.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.


--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.

More information about the radiator mailing list