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

Hugh Irvine hugh at open.com.au
Sat Jun 12 02:45:48 CDT 2004


Hi Terry -

This does look curious, however I would have thought the "AuthByPolicy 
ContinueWhileAccept" more appropriate in this case.

I would be inclined to do a more simple test with a single Handler and 
just use radpwtst before moving on to a more complex configuration.

regards

Hugh


On 12 Jun 2004, at 04:18, Terry Simons wrote:

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

NB: have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.

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