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

[Terry Simons]

Hmmm yes, that would probably work.  :-)

Thanks I'll try it out.

I'm still interested in knowing why my ContinueUntilReject isn't  
working with the current configuration...

Thanks!

- Terry

On Jun 12, 2004, at 12:20 AM, Arjan Waardenburg wrote:

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