(RADIATOR) radius setup for network management

[Hugh Irvine]

Hello Stafford -

What you show below is exactly how I would approach the problem.

The problem you have is due to the fact that the Identifier in a Client 
clause does not propogate through the IdenticalClients.

You will need to specify your Client clauses individually, each one 
with the appropriate Identifier.

BTW - the most recent version is Radiator 3.5 (available from the web 
site) - and you may be interested in our new Radar product.

regards

Hugh


On Friday, Dec 20, 2002, at 07:07 Australia/Melbourne, Stafford A. Rau 
wrote:

> I'm trying to puzzle out what should probably be a not too complicated
> setup, but I'm getting a bit dazed and confused.
>
> I want to use radius authentication for management access to a number 
> of
> routers, dslams, and other equipment.
>
> I'm running an older version of Radiator, 2.16, on a unix platform and
> can successfully authenticate with AuthBy NT against our Windows 
> domain.
> I can also successfully specify read-write access to our DSLAMs with 
> the
> "Service-Type = Administrative-User" attribute.
>
> Here's where I'm having trouble: I want to be able to specify 
> read-only,
> read-write, or no access depending on the user and the device.
>
> To be specific, all the devices are grouped by geographic location, 
> which
> in our case is by US state (Oregon, Washington, Utah, etc).
>
> We have a corporate engineering group that should have read-write 
> access
> to all devices, regardless of state.
>
> Each state has an engineering group that should have read-write access
> to all the devices in that state, and read-only access to all other
> devices.
>
> We have a provisioning group for each state that should have read-write
> access to the devices in that state, but no access to any devices
> outside that state.
>
> It's not a huge number of users nor devices - about 50-75 devices in
> each of the five states, and about 50 total user accounts.
>
> I'm hoping someone can suggest an overall structure for the radius.cfg
> and users files that would allow me to accomplish what I've described 
> in
> a reasonably manageable fashion.
>
> What I have so far is:
>
> <Client ut_dslams>
> include /usr/local/etc/raddb/ut_dslams
> </Client>
>
> <Client or_dslams>
> include /usr/local/etc/raddb/nw_dslams
> </Client>
>
> <Realm DEFAULT>
> 	AcctLogFileName %Ldetail
> 	PasswordLogFileName %L/password.log
> 	RewriteUsername s/^([^@]+).*/$1/
> 	<AuthBy FILE>
> 		Filename /usr/local/etc/raddb/users
> 	</AuthBy>
> </Realm>
>
> <AuthBy NT>
> 	Identifier domaincheck
> 	Domain dorky.domain.com
> 	DomainController dorkycontroller
> </AuthBy>
>
> In the included client files, I have the secret, an "Identifier = "
> line, and a bunch of IdenticalClients.
>
> In the users files, I have:
>
> #Corp Engineering
> joe1 Auth-Type = domaincheck
> 	Service-Type = Administrative-User
> joe2 Auth-Type = domaincheck
> 	Service-Type = Administrative-User
> #Oregon Provisioning
> slug1 Auth-Type = domaincheck, Client-Identifier = or_dslams
> 	Service-Type = Administrative-User
> slug2 Auth-Type = domaincheck, Client-Identifier = or_dslams
> 	Service-Type = Administrative-User
>
> The "Client-Identifier" doesn't seem to be checked.
>
> Thanks,
> --Stafford
> ===
> 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.
>
>

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.

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