(RADIATOR) Client identifier

[Henning Markussen]

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
> 

--
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.