(RADIATOR) Radiator doesn't reject on reject. ;-)

[Arjan Waardenburg]

Shouldn't you be using AUTHBY GROUP in this case ?

----- Original Message ----- 
From: "Terry Simons" <galimore at mac.com>
To: <radiator at open.com.au>
Sent: Saturday, 12 June, 2004 04:18
Subject: (RADIATOR) Radiator doesn't reject on reject. ;-)


> Hi,
>
> I'm seeing some bogus behavior out of Radiator 3.9 with the following
> handlers:
>
> <Handler TunnelledByTTLS=1>
>          RewriteUsername s/^([^@]+).*/$1/
>
>         AuthByPolicy ContinueUntilReject
>
>         <AuthBy FILE>
>                         AcceptIfMissing
>                 Filename                        %D/users
>         </AuthBy>
>
>           <AuthBy KRB5>
>                  KrbRealm UTAH.EDU
>          </AuthBy>
> </Handler>
>
> <Handler>
>           <AuthBy FILE>
>                  AcceptIfMissing
>                  Filename %D/users
>                  EAPType TTLS TLS MD5-Challenge MSCHAP-V2
>
>                  EAPTLS_CAFile /opt/uofu/radiator/etc/root.pem
>
>                  EAPTLS_CertificateFile
> /opt/uofu/radiator/etc/our-srv-cert.pem
>                  EAPTLS_CertificateType PEM
>
>                  EAPTLS_PrivateKeyFile /opt/uofu/radiator/etc/our-key.pem
>
>                  EAPTLS_PrivateKeyPassword blahblahblah
>
>                  EAPTLS_MaxFragmentSize 1024
>
>                  EAPTLS_SessionResumption 0
>
>                  AutoMPPEKeys
>          </AuthBy>
> </Handler>
>
> Basically what we're seeing is that if a user is in the %D/users
> directory, I get a reject message in the log, but I also get a
> successful authentication from Kerberos.  The Authentication falls
> through, even though the user was "rejected".  What I need is for
> Radiator to reject, and return from the handler without calling the
> AuthBy KRB5 declaration.
>
> Here's the log file:
>
> Fri Jun 11 20:19:03 2004: DEBUG: Handling request with Handler
> 'TunnelledByTTLS=1'
> Fri Jun 11 20:19:03 2004: DEBUG: Rewrote user name to u0153357
> Fri Jun 11 20:19:03 2004: DEBUG:  Deleting session for
> u0153357 at utah.edu, 155.97.5.66,
> Fri Jun 11 20:19:03 2004: DEBUG: Handling with Radius::AuthFILE:
> Fri Jun 11 20:19:03 2004: DEBUG: Radius::AuthFILE looks for match with
> u0153357
> Fri Jun 11 20:19:03 2004: DEBUG: Radius::AuthFILE REJECT: Bad Password
> Fri Jun 11 20:19:03 2004: DEBUG: Handling with Radius::AuthKRB5:
> Fri Jun 11 20:19:03 2004: DEBUG: Radius::AuthKRB5 looks for match with
> u0153357
> Fri Jun 11 20:19:03 2004: DEBUG: Building Kerberos principal:
> u0153357 at UTAH.EDU
> Fri Jun 11 20:19:04 2004: DEBUG: Radius::AuthKRB5 ACCEPT:
> Fri Jun 11 20:19:04 2004: DEBUG: Access accepted for u0153357
> Fri Jun 11 20:19:04 2004: DEBUG: EAP result: 0, EAP TTLS inner
> authentication redespatched to a Handler
> Fri Jun 11 20:19:04 2004: DEBUG: Access accepted for u0153357
>
>
> Is this happening because of the initial AcceptIfMissing clause in the
> default handler, or is this some sort of weird bug with the
> TunnelledByTTLS=1 handler?
>
> What I need to do is basically unwrap the outer gunk so I can do my
> authorization and authentication against the inner bits.  I want the
> authentication to succeed if the user doesn't exist in the file, but
> fail if they are in the file, and eventually send back an
> EAP-Notification explaining the issue... it didn't seem like there was
> any other way to do this.  Since we ARE seeing the reject here, it
> seems like a bug that Radiator goes ahead and authenticates me to
> Kerberos.
>
> I can provide more logging and/or more configuration if necessary, but
> the problem seems straightforward enough that I thought just providing
> the handler would probably suffice.  Let me know if that isn't the
> case. ;-)
>
> Thanks!
>
> - Terry
>
> --
> 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.
>
>
____________________________________________________________________________
__________
> This inbound message to KPN has been checked for all known viruses by KPN
MailScan
> (IV-Scan), powered by MessageLabs.
> For further information visit: http://www.veiliginternet.nl
>
____________________________________________________________________________
__________
>

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