(RADIATOR) Assigning vlan attributes

[Hugh Irvine]

Hello Colin -

Yes you can use two AuthBy clauses to do what you describe.

Here is how I generally do it:


.........

# define AuthBy LDAP2 clause to check AD

<AuthBy LDAP2>
	Identifier CheckAD
	......
</AuthBy>

# define AuthBy FILE for AD and VLAN

<AuthBy FILE>
	Identifier CheckUser
	Filename %D/users.vlan
	.....
</AuthBy>

# define Realm(s) or Handler(s)

<Handler ......>
	AuthBy CheckUser
	.....
</Handler>

.......

The file "users.vlan" would contain something like this:

# users.vlan

userA  Auth-Type = CheckAD
	vlan = .....

userB  Auth-Type = CheckAD
	vlan = .....

........

where "vlan = ...." is the appropriate reply item for your equipment.

It is a good idea to keep the user entries in the file in  
alphabetical order for ease of maintenance.

hope that helps

regards

Hugh


On 23 Feb 2007, at 00:04, Colin Byelong wrote:

> Hi Jan,
>
> Thanks for the reply, We are actually authenticating against a AD  
> server using the ldap front end.
> Do you know if i can just authenticate against the AD server then  
> have a file on radiator that contains userid's and which vlan they  
> should be in ?
>
> Thanks
>
> Colin
>> Hello Colin,
>>
>> Colin Byelong wrote:
>>
>>> We know how to do the authentication against LDAP part but im not  
>>> sure
>>> where information about which vlan they should be in is held,  
>>> would this
>>> be in a users file on the radius server ?
>>> So the user logs in this is checked against the ldap entry,  
>>> passes then
>>> the user is checked against a file on the radius server and  
>>> placed into
>>> a vlan.
>>> Do you have a example of this ?
>>>
>>
>> I put into my AuthBy LDAP line like this:
>>
>>         AuthAttrDef     radiusTunnelPrivateGroupID, \
>>                         Tunnel-Private-Group-ID, reply
>>
>> Radiator fetch values of attribute radiusTunnelPrivateGroupID from my
>> LDAP and passes it in reply as Tunnel-Private-Group-ID to NAS.
>>
>> Hope this helps
>>
>
>
> -- 
> ---------------------------------------------------------------------- 
> -
>
>
> Colin Byelong                             Email: C.Byelong at ucl.ac.uk
> Senior Network Development Officer
> Network Group
> Information Systems Division
> University College London
> Gower Street                              Phone: 020 7679-2572
> London WC1E 6BT
> ---------------------------------------------------------------------- 
> --
> --
> 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?

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