(RADIATOR) 802.1x Authentication Unsuccessful - Could not find a handler for...

Hugh Irvine hugh at open.com.au
Sat Oct 4 02:13:58 CDT 2003


Hello Terry -

You are correct, in many situations a single Handler is fine. The 
reason there are two options is because some people want to process the 
outer authentication in one fashion (usually a simple file), and the 
inner authentication with something like an SQL or LDAP database. The 
Radiator configuration file allows you to do both.

To get a better understanding of what happens, study a trace 4 debug 
from Radiator to see the multi-step processing that occurs during EAP 
authentication.

regards

Hugh



On Saturday, Oct 4, 2003, at 16:59 Australia/Melbourne, Terry Simons 
wrote:

> I actually tried it with *just* the <Handler> clause, and it worked... 
> so apparently the "TunneledByTTLS=1" portion isn't required...
>
> Should I be using both handler portions?  If so, why?  It seems really 
> redundant to do things that way, and it is somewhat confusing.
>
> I'm just trying to understand what's going on here... :-)
>
> Thanks for the help!
>
> - Terry
>
> On Oct 4, 2003, at 12:39 AM, Hugh Irvine wrote:
>
>>
>> Hello Terry -
>>
>> You will need to have two Handlers in your configuration file:
>>
>> Foreground
>> LogStdout
>>
>> LogDir          /usr/local/var/log/radius.log
>> LogFile         %L/logfile
>> DbDir           /usr/local/etc
>> Trace           4
>>
>> AuthPort 1812
>> AcctPort 1813
>>
>> <Client DEFAULT>
>>         NoIgnoreDuplicates Access-Challenge
>>         NoIgnoreDuplicates Access-Request
>>         DupInterval 0
>> </Client>
>>
>> <Handler TunneledByTTLS=1>
>>    <AuthBy FILE>
>>        Filename                        /usr/local/etc/users
>>        EAPType                         TTLS, TLS, MD5-Challenge, 
>> MSCHAP-V2
>>        EAPTLS_MaxFragmentSize          1024
>>        EAPTLS_CAFile                   /etc/radiator/testCA.pem
>>        EAPTLS_CertificateType          PEM
>>        EAPTLS_CertificateFile          /etc/radiator/testServer.pem
>>        EAPTLS_PrivateKeyFile           /etc/radiator/testServer.pem
>>        EAPTLS_PrivateKeyPassword      *********
>>
>>        EAPTLS_SessionResumption 0
>>        AutoMPPEKeys
>>    </AuthBy>
>> </Handler>
>>
>> <Handler>
>>    <AuthBy FILE>
>>        Filename                        /usr/local/etc/users
>>        EAPType                         TTLS, TLS, MD5-Challenge, 
>> MSCHAP-V2
>>        EAPTLS_MaxFragmentSize          1024
>>        EAPTLS_CAFile                   /etc/radiator/testCA.pem
>>        EAPTLS_CertificateType          PEM
>>        EAPTLS_CertificateFile          /etc/radiator/testServer.pem
>>        EAPTLS_PrivateKeyFile           /etc/radiator/testServer.pem
>>        EAPTLS_PrivateKeyPassword      *********
>>
>>        EAPTLS_SessionResumption 0
>>        AutoMPPEKeys
>>    </AuthBy>
>> </Handler>
>>
>>
>> Although it is more usual to have different configurations in the two 
>> Handlers.
>>
>> By means of explanation, the <Handler> at the end is the default 
>> Handler that will be used to process the outer authentication. Then 
>> the <Handler TunneledByTTLS = 1> will process the inner 
>> authentication. Note that EAP is a multi-pass system with a number of 
>> radius exchanges between client and server.
>>
>> BTW - you should also use commas in the EAPType list (see above).
>>
>> Have a look at the example configuration files in the goodies 
>> directory (eap_*.cfg).
>>
>>
>> regards
>>
>> Hugh
>>
>>
>> On Saturday, Oct 4, 2003, at 15:33 Australia/Melbourne, Terry Simons 
>> wrote:
>>
>>> Mike,
>>>
>>> I stripped my configuration down to a bare-bones one, and I'm still 
>>> having the issue I mentioned before (listed at the bottom of this 
>>> E-mail)
>>>
>>> I've also done the following:
>>>
>>> Upgraded to Radiator 3.7.1 w/patches as of October 3 2003.
>>>
>>> Using D-Link DWL 900AP+, which worked with Radiator 3.6 & patches, 
>>> but is broken with Radiator 3.7 & 3.7.1.
>>>
>>> Here's my configuration, and there are some trace level 4 log 
>>> tidbits after the configuration:
>>>
>>> Foreground
>>> LogStdout
>>>
>>> LogDir          /usr/local/var/log/radius.log
>>> LogFile         %L/logfile
>>> DbDir           /usr/local/etc
>>> Trace           4
>>>
>>> AuthPort 1812
>>> AcctPort 1813
>>>
>>> <Client DEFAULT>
>>>         NoIgnoreDuplicates Access-Challenge
>>>         NoIgnoreDuplicates Access-Request
>>>         DupInterval 0
>>> </Client>
>>>
>>> <Handler TunneledByTTLS=1>
>>>    <AuthBy FILE>
>>>        Filename                        /usr/local/etc/users
>>>        EAPType                         TTLS TLS MD5-Challenge 
>>> MSCHAP-V2
>>>        EAPTLS_MaxFragmentSize          1024
>>>        EAPTLS_CAFile                   /etc/radiator/testCA.pem
>>>        EAPTLS_CertificateType          PEM
>>>        EAPTLS_CertificateFile          /etc/radiator/testServer.pem
>>>        EAPTLS_PrivateKeyFile           /etc/radiator/testServer.pem
>>>        EAPTLS_PrivateKeyPassword      *********
>>>
>>>        EAPTLS_SessionResumption 0
>>>        AutoMPPEKeys
>>>    </AuthBy>
>>> </Handler>
>>>
>>> There is some weird logging output that wasn't around in 3.6... plus 
>>> some weirdness from my AP, it seems.
>>>
>>> It doesn't look like an Acct-Session-Id is being generated for my 
>>> authentication... (Does this happen on the AP, or does Radiator do 
>>> this?)
>>>
>>> Also, when I stop my client, I get a stop record from the AP, it 
>>> seems.  Radiator makes 3 logs of this, and complains that it 
>>> couldn't find a handler for a non existent user, literally "" and 
>>> that the requests were ignored.
>>>
>>> Anyway... here's the complete output:
>>>
>>> Fri Oct  3 23:27:14 2003: DEBUG: Reading users file 
>>> /usr/local/etc/users
>>> Fri Oct  3 23:27:14 2003: DEBUG: Finished reading configuration file 
>>> '/etc/radiator/radius.cfg'
>>> Fri Oct  3 23:27:14 2003: DEBUG: Reading dictionary file 
>>> '/usr/local/etc/dictionary'
>>> Fri Oct  3 23:27:14 2003: DEBUG: Creating authentication port 
>>> 0.0.0.0:1812
>>> Fri Oct  3 23:27:14 2003: DEBUG: Creating accounting port 
>>> 0.0.0.0:1813
>>> Fri Oct  3 23:27:14 2003: NOTICE: Server started: Radiator 3.7.1 on 
>>> icebox
>>> Fri Oct  3 23:27:21 2003: DEBUG: Packet dump:
>>> *** Received from 10.0.0.20 port 1248 ....
>>> Code:       Access-Request
>>> Identifier: 91
>>> Authentic:  <212><250>?<241><192>0N]<26><146>&\D<191><27><218>
>>> Attributes:
>>>         User-Name = "terry"
>>>         NAS-IP-Address = 10.0.0.20
>>>         NAS-Port = 0
>>>         Called-Station-Id = "00-40-05-D0-53-80"
>>>         Calling-Station-Id = "00-30-65-1D-9E-A6"
>>>         NAS-Identifier = "WardriveMe"
>>>         Framed-MTU = 1380
>>>         NAS-Port-Type = Wireless-IEEE-802-11
>>>         EAP-Message = <2><1><0><10><1>terry
>>>         Message-Authenticator = 
>>> <229><209>`C<143>G*ob<200><224>@z<141>C<171>
>>>
>>> Fri Oct  3 23:27:21 2003: WARNING: Could not find a handler for 
>>> terry: request is ignored
>>> Fri Oct  3 23:27:26 2003: DEBUG: Packet dump:
>>> *** Received from 10.0.0.20 port 1249 ....
>>> Code:       Accounting-Request
>>> Identifier: 92
>>> Authentic:  <156><165>O<146><241>u<170>I<141><240>vYN5<161><206>
>>> Attributes:
>>>         Acct-Status-Type = Stop
>>>         User-Name = ""
>>>         Acct-Session-Id = ""
>>>         NAS-IP-Address = 10.0.0.20
>>>         NAS-Port = 0
>>>         Acct-Authentic = RADIUS
>>>         NAS-Identifier = "WardriveMe"
>>>         Acct-Delay-Time = 0
>>>
>>> Fri Oct  3 23:27:26 2003: WARNING: Could not find a handler for : 
>>> request is ignored
>>> Fri Oct  3 23:27:31 2003: DEBUG: Packet dump:
>>> *** Received from 10.0.0.20 port 1249 ....
>>> Code:       Accounting-Request
>>> Identifier: 93
>>> Authentic:  7E<24><133>Q<135><27><168>g4<241><18><<201><10>&
>>> Attributes:
>>>         Acct-Status-Type = Stop
>>>         User-Name = ""
>>>         Acct-Session-Id = ""
>>>         NAS-IP-Address = 10.0.0.20
>>>         NAS-Port = 0
>>>         Acct-Authentic = RADIUS
>>>         NAS-Identifier = "WardriveMe"
>>>         Acct-Delay-Time = 83886080
>>>
>>> Fri Oct  3 23:27:31 2003: WARNING: Could not find a handler for : 
>>> request is ignored
>>> Fri Oct  3 23:27:36 2003: DEBUG: Packet dump:
>>> *** Received from 10.0.0.20 port 1249 ....
>>> Code:       Accounting-Request
>>> Identifier: 94
>>> Authentic:  
>>> _@<177><173><183><176><184><20><26><219><202>{B<214><175>E
>>> Attributes:
>>>         Acct-Status-Type = Stop
>>>         User-Name = ""
>>>         Acct-Session-Id = ""
>>>         NAS-IP-Address = 10.0.0.20
>>>         NAS-Port = 0
>>>         Acct-Authentic = RADIUS
>>>         NAS-Identifier = "WardriveMe"
>>>         Acct-Delay-Time = 167772160
>>>
>>> Fri Oct  3 23:27:36 2003: WARNING: Could not find a handler for : 
>>> request is ignored
>>>
>>>
>>>
>>>
>>> On Sep 26, 2003, at 12:50 AM, Mike McCauley wrote:
>>>
>>>> Hello Terry,
>>>>
>>>>
>>>> On Fri, 26 Sep 2003 03:44 pm, Terry Simons wrote:
>>>>> Howdy,
>>>>>
>>>>> After upgrading to Radiator 3.7 I'm getting the following error:
>>>>>
>>>>> Reply-Message = "EAP TTLS inner authentication redespatched to a
>>>>> Handler"
>>>>>
>>>>> Things worked just fine in 3.6... :)
>>>>>
>>>>> I took a look in eap_ttls.cfg, but it looks like there is a typo...
>>>>>
>>>>> There is a starting <Realm DEFAULT> declaration, but it ends with a
>>>>> </Handler> tag.
>>>>
>>>> This is incorrect, but innocuous, and would not explain what you 
>>>> are seeing.
>>>>
>>>> I think we will need to see your Radiator log file at trace level 4 
>>>> showing
>>>> what happens during authentication.
>>>> What type of TTLS authentication are you using?
>>>>
>>>> What does AuthBy         ACCT-TEST  in your config file refer to? I 
>>>> think we
>>>> will need to see your entore config file (no secrets)
>>>>
>>>> Cheers.
>>>>
>>>>
>>>>>
>>>>> That doesn't quite look right...
>>>>>
>>>>> I guess I'll give the eap_ttls_proxy.cfg handler method a try...
>>>>>
>>>>> Should this work the way I have it configured, or did I do 
>>>>> something
>>>>> wrong?
>>>>>
>>>>> Here's the offending realm definition:
>>>>>
>>>>> <Realm DEFAULT>
>>>>>     RewriteUsername s/^([^@]+).*/$1/
>>>>>     AcctLogFileName %L/accounting/accounting.acct
>>>>>
>>>>>      RejectHasReason
>>>>>
>>>>>      AuthByPolicy    ContinueAlways
>>>>>
>>>>>      AuthBy         ACCT-TEST
>>>>>
>>>>>      <AuthLog FILE>
>>>>>          Filename                %L/authlog/authlog.log
>>>>>          LogSuccess              1
>>>>>          LogFailure              1
>>>>>          SuccessFormat           %l,%u,%{NAS-Identifier},%N,%h,OK
>>>>>          FailureFormat           %l,%u,%{NAS-Identifier},%N,%h,FAIL
>>>>>      </AuthLog>
>>>>>     RewriteUsername s/^([^@]+).*/$1/
>>>>>
>>>>>     <AuthBy FILE>
>>>>>         Filename                        /usr/local/etc/users
>>>>>         EAPType                         TTLS TLS MD5-Challenge 
>>>>> MSCHAP-V2
>>>>>         EAPTLS_MaxFragmentSize          1024
>>>>>         EAPTLS_CAFile                   /etc/radiator/CA.pem
>>>>>         EAPTLS_CertificateType          PEM
>>>>>         EAPTLS_CertificateFile          /etc/radiator/Server.pem
>>>>>         EAPTLS_PrivateKeyFile           /etc/radiator/Server.pem
>>>>>         EAPTLS_PrivateKeyPassword       PrivateKey
>>>>>
>>>>>         EAPTLS_SessionResumption 0
>>>>>         AutoMPPEKeys
>>>>>
>>>>>     </AuthBy>
>>>>> </Realm>
>>>>>
>>>>> ===
>>>>> 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.
>>>>
>>>> -- 
>>>> Mike McCauley                               mikem at open.com.au
>>>> Open System Consultants Pty. Ltd            Unix, Perl, Motif, C++, 
>>>> WWW
>>>> 24 Bateman St Hampton, VIC 3188 Australia   http://www.open.com.au
>>>> Phone +61 3 9598-0985                       Fax   +61 3 9598-0955
>>>>
>>>> Radiator: the most portable, flexible and configurable RADIUS server
>>>> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
>>>> Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, 
>>>> TLS,
>>>> TTLS, PEAP etc on Unix, Windows, MacOS etc.
>>>>
>>>
>>> ===
>>> 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.
>>
>
>

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.

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