Hello Frank -
What is shown below looks like what is being logged to syslog? I would like to
see a trace 4 output to a logfile so I can see the packet dumps.
thanks
Hugh
On Fri, 01 Sep 2000, FlintHillsTechnical Support wrote:
> Hugh--
>
> we are set to trace 4 and this is all that is entered when this happens
>
> Aug 31 21:48:24 x.x.x.x /usr/bin/radiusd[11856]: Access rejected for pja: No such
>user
>
> if this will help, here is authentication debugging from the router
>
> 11w0d: AAA: name=Virtual-Access1 flags=0x11 type=5 shelf=0 slot=0 adapter=0 port=1
>channel=0
> 11w0d: AAA/MEMORY: create_user (0x6279B794) user='pja' ruser=''
>port='Virtual-Access1' rem_addr='' authen_type=PAP service=PPP priv=1
> 11w0d: AAA/AUTHEN/START (1231792523): port='Virtual-Access1' list='' action=LOGIN
>service=PPP
> 11w0d: AAA/AUTHEN/START (1231792523): using "default" list
> 11w0d: AAA/AUTHEN (1231792523): status = UNKNOWN
> 11w0d: AAA/AUTHEN/START (1231792523): Method=LOCAL
> 11w0d: AAA/AUTHEN (1231792523): status = ERROR
> 11w0d: AAA/AUTHEN/START (1231792523): Method=radius (radius)
> 11w0d: AAA/AUTHEN (1231792523): status = FAIL
> Sep 1 02:48:24 UTC: %VPDN-6-AUTHENFAIL: L2F HGW FlintVPOP, AAA authentication
>failure for Vi1 user pja; Request Denied
> 11w0d: AAA/MEMORY: free_user (0x6279B794) user='pja' ruser='' port='Virtual-Access1'
>rem_addr='' authen_type=PAP service=PPP priv=1
>
> Frank
>
>
> >
> >I will need to see a more complete trace 4 showing what is happening.
> >
> >thanks
> >
> >Hugh
> >
> >On Fri, 01 Sep 2000, FlintHillsTechnical Support wrote:
> >> Hello--
> >>
> >> We have tried to implement Handlers which work, sorta! We now can allow any user
>to connect to our Ascends despite their Service-Type and we can restrict who can
>telnet to the Cisco. However, when we try to dial into the external NAS that is
>connected to the Cisco as a normal user it is rejected and in the debug file is
> >>
> >> Aug 31 15:44:45 x.x.x.x /usr/bin/radiusd[11856]: Access rejected for pja: No such
>user
> >>
> >> Here are our 2 examples of our Clients and our Handler statements. I am pretty
>sure this is a syntax issue....
> >>
> >> <Client x.x.x.x>
> >> Secret xxxxxx
> >> DefaultRealm cisco.flinthills.com
> >> </Client>
> >>
> >> <Client x.x.x.x>
> >> Secret xxxxxx
> >> DefaultRealm ascend.flinthills.com
> >> </Client>
> >>
> >> <Handler Realm=ascend.flinthills.com>
> >> RewriteUsername tr/A-Z/a-z/
> >> RewriteUsername s/\@ascend\.flinthills\.com//
> >> <AuthBy DBFILE>
> >> Filename %D/users
> >> </AuthBy>
> >> AcctLogFileName %L/acct-radius
> >> WtmpFileName %L/wtmp-radius
> >> </Handler>
> >>
> >> <Handler Service-Type=Framed-User, Realm=cisco.flinthills.com>
> >> RewriteUsername tr/A-Z/a-z/
> >> RewriteUsername s/\@cisco\.flinthills\.com//
> >> <AuthBy DBFILE>
> >> Filename %D/users
> >> </AuthBy>
> >> AcctLogFileName %L/acct-radius
> >> WtmpFileName %L/wtmp-radius
> >> </Handler>
> >>
> >> <Handler Realm=cisco.flinthills.com>
> >> RewriteUsername tr/A-Z/a-z/
> >> RewriteUsername s/\@cisco\.flinthills\.com//
> >> <AuthBy DBFILE>
> >> Filename %D/netadm
> >> </AuthBy>
> >> AcctLogFileName %L/acct-radius
> >> WtmpFileName %L/wtmp-radius
> >> </Handler>
> >>
> >>
> >> Any help on this would be greatly appreciated!!!
> >>
> >> TIA
> >> Frank
> >>
> >>
> >> >>
> >> >> We have Ascend NASes and a Cisco router that has other NASes
> >> >connected to it via L2F tunnels. We are trying to restrict who can telnet to
> >> >the Cisco router. Previously, we did not have the NASes connected to the Cisco
> >> >so access was restricted by placing the Cisco in a separate realm pointing to a
> >> >users file that only the users allowed on the router were in. The Ascend NASes
> >> >were in another realm pointing to a separate users file that all of the dialup
> >> >users authenticated from.
> >> >
> >> >> However, now we have dialup users coming through
> >> >the Cisco from external NASes and this will not work and essentially anyone
> >> >could telnet to the router.
> >> >
> >> >> First, we created a common users file and used a
> >> >check item of Service-Type = Framed User and set administrators(those who
> >> >needed access to the Cisco) with no Service-Type check item so they could
> >> >telnet to the router OR dial in via ppp.
> >> >
> >> >> But now we realize (much to our
> >> >dismay)that we have users who dial into the Ascend's TermSrv with Linux and
> >> >older Macs that utilize scripts. When accessing this way the Service-Type is
> >> >passed as Login-User and not Framed User.
> >> >
> >> >> Does anyone have ideas on this?
> >> >Essentially we want only a few users telnet access to the Cisco yet still allow
> >> >the script users their method of access. I have looked through the archive some
> >> >but really I don't know the best way to search for this issue. Are we
> >> >approaching this correctly by utilizing check items?
> >> >
> >> >You will have to look at the trace 4 packet dumps of the relevant radius
> >> >request packets to see what (if anything) is different between the various
> >> >requests. You may find that seperate Handlers for the different classes of user
> >> >is a better approach rather than a single users file. You might also consider
> >> >having your administrative users log in with a special realm, such as
> >> >"[EMAIL PROTECTED]" (perhaps in conjunction with our RadKey product or
> >> >something similar).
>
>
> ===
> 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.
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc.
Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X.
===
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.
