(RADIATOR) Radiator doesn't reject on reject. ;-)
Terry Simons
galimore at mac.com
Mon Jun 14 13:58:50 CDT 2004
Hi,
I took your suggestion to try the AuthBy GROUP clause... but I have the
same issue.
Here is a log snippet to demonstrate:
Mon Jun 14 12:58:43 2004: DEBUG: Handling request with Handler
'TunnelledByTTLS=1'
Mon Jun 14 12:58:43 2004: DEBUG: Rewrote user name to u0153357
Mon Jun 14 12:58:43 2004: DEBUG: Deleting session for
u0153357 at utah.edu, 155.97.5.66,
Mon Jun 14 12:58:43 2004: DEBUG: Handling with Radius::AuthGROUP
Mon Jun 14 12:58:43 2004: DEBUG: Handling with Radius::AuthFILE:
Mon Jun 14 12:58:43 2004: DEBUG: Radius::AuthFILE looks for match with
u0153357
Mon Jun 14 12:58:43 2004: DEBUG: Radius::AuthFILE REJECT: Bad Password
Mon Jun 14 12:58:43 2004: DEBUG: Handling with Radius::AuthKRB5:
Mon Jun 14 12:58:43 2004: DEBUG: Radius::AuthKRB5 looks for match with
u0153357
Mon Jun 14 12:58:43 2004: DEBUG: Building Kerberos principal:
u0153357 at UTAH.EDU
Mon Jun 14 12:58:43 2004: DEBUG: Radius::AuthKRB5 ACCEPT:
Mon Jun 14 12:58:43 2004: DEBUG: Access accepted for u0153357
Mon Jun 14 12:58:43 2004: DEBUG: EAP result: 0, EAP TTLS inner
authentication redespatched to a Handler
Mon Jun 14 12:58:43 2004: DEBUG: Access accepted for u0153357
As you can see above, the AuthBy group clause is hit, but the same
problem occurs where the reject doesn't return out of the handler.
Here is the interesting configuration portion:
<Handler TunnelledByTTLS=1>
RewriteUsername s/^([^@]+).*/$1/
<AuthBy GROUP>
AuthByPolicy ContinueWhileAccept
<AuthBy FILE>
AcceptIfMissing
Filename %D/users
</AuthBy>
<AuthBy KRB5>
KrbRealm UTAH.EDU
</AuthBy>
</AuthBy>
</Handler>
- 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.
--
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.
More information about the radiator
mailing list