(RADIATOR) Re: could not find handler for user at domain.com

[Forbes Mike]

Scratch that, I did a global rewrite of the user@ to user.  Is that the
best way to deal with this?

Mike

On Tue, 7 Sep 2004, Forbes Mike wrote:

>
> I get the following error:
>
> Tue Sep  7 17:03:56 2004: WARNING: Could not find a handler for
> user at qwest.net: request is ignored
>
> We also receive user at colorado.edu that fails.
>
> I see in the reference manual radiator will first look for a realm
> matching the @qwest.net or @colorado.edu.  Since we do not use this for
> authenication, they do not exist.  I tried adding a default realm, with
> Realm = DEFAULT but that did not work.
>
> The access request provides the NAS-IP-Address and the Framed-Protocol
> which should forward it to the correct handler, but it seems to get caught
> up on the @ symbol.
>
> All requests without the @domain.com work fine, is there a way to have it
> process these with the handler for IP and PPP?
>
> <Handler Realm=Backbone_Devices,Framed-Protocol=PPP>
> RewriteUsername s/^([^@]+).*/$1/
> RewriteUsername tr/A-Z/a-z/
>         <AuthBy GROUP>
>                 <AuthBy Krb5Password>
>                         Fork
>                         Identifier Krb5Password
>                         Keytab FILE:/etc/krb5.keytab
>                 </AuthBy>
>
>         </AuthBy>
>         AuthLog DSL_PPP_Login_Failures
>        # Log accounting to a detail file
>         AcctLogFileName %L/dsl_ppp_users.log
> </Handler>
>
> Yes we use realms and handlers and we understand that is bad. We use them
> to differentiate inside the handlers.  We do not use <Realm = > anywhere
> except to test the realm default.  I do not want to authenticate
> @domain.com users, I am willind to do so as to kick out in the appropriate
> authlog file.  We then automate their removal from the DSL device until
> they change the username to the correct user.
>
> Mike
>
>
> Here is the output for working and not working.
>
> Tue Sep  7 18:20:29 2004: DEBUG: Packet dump:
> *** Received from 192.168.X.X port 21689 ....
> Code:       Access-Request
> Identifier: 131
> Attributes:
>         Framed-Protocol = PPP
>         User-Name = "user at qwest.net"
>         User-Password =
>         NAS-Port-Type = Virtual
>         Cisco-NAS-Port = "1/0/0/1.XX"
>         NAS-Port = 0
>         Connect-Info = "ppp-640-256"
>         Service-Type = Framed-User
>         NAS-IP-Address = 192.168.X.X
>
> Tue Sep  7 18:20:29 2004: WARNING: Could not find a handler for
> user at qwest.net: request is ignored
>
> A regular user looks like this:
>
> Tue Sep  7 17:04:12 2004: DEBUG: Packet dump:
> *** Received from 192.168.X.X port 21688 ....
> Code:       Access-Request
> Identifier: 61
> Attributes:
>         Framed-Protocol = PPP
>         User-Name = "user"
>         User-Password =
>         NAS-Port-Type = Virtual
>         Cisco-NAS-Port = "1/0/0/1.XXX"
>         NAS-Port = 0
>         Connect-Info = "ppp-640-256-4"
>         Service-Type = Framed-User
>         NAS-IP-Address = 192.168.X.X
>
> Tue Sep  7 17:04:12 2004: DEBUG: Handling request with Handler
> 'Realm=Backbone_D
> evices,Framed-Protocol=PPP'
> Tue Sep  7 17:04:12 2004: DEBUG: Rewrote user name to user
> Tue Sep  7 17:04:12 2004: DEBUG: Rewrote user name to user
> Tue Sep  7 17:04:12 2004: DEBUG:  Deleting session for user,
> 192.168.X.X, 0
> Tue Sep  7 17:04:12 2004: DEBUG: Handling with Radius::AuthGROUP
> Tue Sep  7 17:04:12 2004: DEBUG: Handling with Radius::AuthKrb5Password:
> Krb5Password
> Tue Sep  7 17:04:13 2004: DEBUG: Radius::AuthKrb5Password looks for match
> with user
> Tue Sep  7 17:04:13 2004: DEBUG: Radius::AuthKrb5Password ACCEPT:
> Tue Sep  7 17:04:13 2004: DEBUG: Access accepted for user
> Tue Sep  7 17:04:13 2004: DEBUG: Packet dump:
>
>

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