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

[Terry Simons]

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.