Hello Jeremy -
On Saturday 06 January 2001 16:20, [EMAIL PROTECTED] wrote:
> Hugh Irvine <[EMAIL PROTECTED]> writes:
> <...>
>
> > > What I would like to do now is convert the NAS's to use Radius and
> > > provide similar functionality/behaviour as we currently have with
> > > XTACACS, which is:
> > >
> > > - provide access to different user groups, e.g. group 1 can only call
> > > into NAS 1, group 2 can call both NAS 1 and NAS 2, etc, and admins
> > > can call into any NAS.
> >
> > What type of database are you using for your user records? And are the
> > different groups mentioned above in different databases? The answer to
> > the above will determine which solution is best.
>
> The database is DBM-based, currently called by various programs from
> xtacacsd when the user logs in/out and start/stops PPP.
>
> Everyone is in the same database, the group access is controlled by
> xtacacsd depending on the users primary Unix group on the main server.
>
I would suggest that your AuthBy EXTERNAL do the group checks as well, there
is no easy way to only check UNIX groups in Radiator (you can easily check
both passwords and groups however).
I would also suggest that you consider moving to an SQL based solution
containing everything which will be *much* easier to maintain (and is *much*
better for accounting).
> > > combined with ...
> > >
> > > - provide 3 levels of service/access:
> > > 1) limited exec shell/connect access to our main server for
> > > telnet/terminal access only.
> > > 2) SLIP/PPP access [note 1]
> > > 3) Authenticated "enable" access for router admins [note 2].
> > >
> > > Note 1: for historical reasons, all users must currently login to
> > > the NAS, then type 'ppp default' to start PPP (likewise for anyone
> > > still using SLIP). We need to preserve this behaviour with Radius
> > > in order not to upset the users :-) So automatic startup of PPP
> > > is out of the question initially.
> >
> > In this case the users will log in to the NAS which will send a
> > Service-Type of Login-User in the access request. You will need to return
> > an access accept with the same Service-Type = Login-User.
>
> OK. How does this differ from Service-Type = NAS-Prompt-User? It seems
> that NAS-Prompt-User might be better from my limited reading of the RFC.
>
The first thing to understand here is that you do not control the
Service-Type attribute, it is the NAS that sends the Service-Type attribute
in the Access-Request according to what the user is trying to do. Radiator
*must* return the same Service-Type as was in the request, otherwise the NAS
will refuse the connection.
> > > Note 2: the current XTACACS functionality requires the router admin
> > > logs in to the NAS with their normal username/password, then types
> > > 'enable', when they are prompted for their username/password again;
> > > if possible I would like to preserve this behaviour with Radius.
> > > (I have experimented with returning Service-Type = Administrative-User
> > > but this immediately gives me full enable privileges, which isn't
> > > what I want)
> >
> > This is undoubtedly a NAS configuration issue.
>
> Can anyone else help me out here?
>
There have been many discussions about Cisco configurations on this list, so
have a look at the archive site and do a search on "cisco" or "aaa".
http://www.starport.net/~radiator
Also check the Cisco web site where you will find *lots* of configuration
information and examples.
BTW - there is a new feature in recent versions of IOS called
"pre-authentication" (or similar) which causes to NAS to send an initial
access request with the Calling-Station-Id and Called-Station-Id before even
answering the phone. You may be able to use this to help do some of what you
want.
regards
Hugh
--
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.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
