(RADIATOR) Re: (re)set of Vendor specific attributes

[Hugh Irvine]

Hello Stephane -

As you have discovered, you cannot have two identical Handler clauses  
- when Handlers are evaluated the first match is the only match.

Your second approach is correct, but the CheckCorporateUsers clause  
must be accepting the user.

We will need to see a trace 4 debug from Radiator to be able to see  
what is happening.

BTW - you should be using Radiator 3.13 with the latest patches.

regards

Hugh


On 2 Aug 2005, at 23:06, DELORT Stephane wrote:

> Hello everyone,
>
> I would like to have my Active Directory users authenticated and  
> then moved to their appropriate VLAN (with trapeze vlan vendor  
> specific attributes).
> I tried to have separate handler like this :
>
> <Handler TunnelledByPEAP=1>
>     AuthByPolicy ContinueWhileAccept
>     AuthBy checkMacAddress      # check the macaddress in a file
>     AuthBy checkCorporateUsers
> <Handler>
>
>
> <Handler TunnelledByPEAP=1>
>     AuthByPolicy ContinueWhileAccept
>     AuthBy checkMacAddress      # check the macaddress in a file
>     AuthBy checkClientUsers
> <Handler>
>
> <AuthBy LSA>
>     Identifier checkCorporateUsers
>     ...
>     StripFromReply TRPZ-VLAN-Name
>     AddToReply  TRPZ-VLAN-Name = corpo_vlan
> </LSA>
>
> <AuthBy LSA>
>     Identifier checkClientUsers
>     ...
>     StripFromReply TRPZ-VLAN-Name
>     AddToReply  TRPZ-VLAN-Name = client_vlan
> </LSA>
>
> <Handler>
>   #PEAP
> </Handler>
>
>
> /!\ This does NOT work because the second handler is never used.
> I thought the handler were checked until one matches the criteria  
> but it does not seem to be the case.
>
> So I tried another idear based on the AuthBy GROUP
>  and I had :
>
>
> <Handler TunnelledByPeap=1>
>    <AuthBy GROUP>
>          AuthByPolicy ContinueWhileAccept
>          AuthBy   CheckMacAddress
>          <AuthBy GROUP>
>               AuthByPolicy ContinueWhileReject
>               AuthBy  CheckCorporateUsers
>               AuthBy  CheckClientUsers
>          </AuthBy>
>     </AuthBy>
> </Handler>
>
>
> In this case, the first clause to be looked at  
> (CheckCorporateUsers) sets the TRPZ-VLAN-Name in the Reply message.
> Even the StripFromReply in CheckClientUsers is not able to remove  
> this attribute (this is odd).
>
> Is there a way to do what Iwant, or at least flush the AccessAccept  
> reply attributes ?.
>
>
> Thanks in advance for any help,
> Stéphane
>
>
>


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?

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
-
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.