(RADIATOR) initial run using simple.cfg with NAS client added fails

Joon Yun joon at berkeley.edu
Fri Dec 23 12:25:59 CST 2005


Hi Jeff,

Yes I read that somewhere but after many attempts and continued success  
with a kinit on the radiator box using the same username and password,  
I am 99% sure I have the right password.

I was actually getting these results using the radpwtst application and  
a Cisco Clean Access Server acting as a NAS because it has an  
authentication testing tool. I am embarrassed to say I was not aware I  
should be testing with an EAP/TTLS-PAP client. I will try it now with  
my XP box (SecureW2) and my Mac OS X box (builtin supplicant) and let  
you all know if I have success. Thanks for your continued insights.

Regards,
Joon Yun
UC Berkeley


On Dec 22, 2005, at 4:37 PM, Jeff Wolfe wrote:

> Mike McCauley wrote:
>> Hi,
>
>> Im sorry that I am not expert enough in Kerberos to answer your  
>> question. All I can say is that the error message you are seeing  
>> makes me think the Kerberos client code does not trust the answer  
>> from the Kerberos server.
>
> Decrypt Integrity Check failures 99% of the time point to a bad  
> password.
>
>
>>>>> *** Received from 128.32.231.212 port 32870 ....
>>>>> Code:       Access-Request
>>>>> Identifier: 226
>>>>> Authentic:   
>>>>> <250><147><186>Px<163>K<192>'<224><12><154><16><233>O<185>
>>>>> Attributes:
>>>>>         NAS-IP-Address = 128.32.231.212
>>>>>         User-Name = "joon"
>>>>>         User-Password =
>>>>> <148><214><241><253><11>Q<246><22><214>wB<14><0><140><203><127><0>9 
>>>>> <23
>>>>> 0>
>>>>> =cq<201><147><177><11><174><12><3><31>Z<173>
>
> This smells like an MSCHAP encrypted password. Are you sure your  
> EAP-TTLS client is configured to use PAP as the inner authentication  
> protocol?
>
>>>>> Wed Dec 21 13:56:28 2005: DEBUG: Handling request with Handler
>>>>> 'Realm=DEFAULT'
>>>>> Wed Dec 21 13:56:28 2005: DEBUG:  Deleting session for joon,
>>>>> 128.32.231.212,
>>>>> Wed Dec 21 13:56:28 2005: DEBUG: Handling with Radius::AuthKRB5:
>>>>> Wed Dec 21 13:56:28 2005: DEBUG: Radius::AuthKRB5 looks for match  
>>>>> with
>>>>> joon [joon]
>>>>> Wed Dec 21 13:56:28 2005: DEBUG: Building Kerberos principal:
>>>>> joon at BERKELEY.EDU
>>>>> Wed Dec 21 13:56:29 2005: DEBUG: Radius::AuthKRB5 REJECT: Kinit
>>>>> failed:
>>>>> Decrypt integrity check failed: joon [joon]
>>>>> Wed Dec 21 13:56:29 2005: DEBUG: AuthBy KRB5 result: REJECT, Kinit
>>>>> failed: Decrypt integrity check failed
>>>>> Wed Dec 21 13:56:29 2005: INFO: Access rejected for joon: Kinit
>>>>> failed:
>>>>> Decrypt integrity check failed
>
>>>>> [ndrl5] ~> kinit
>>>>> joon at BERKELEY.EDU's Password:
>>>>> kinit: NOTICE: ticket renewable lifetime is 1 week
>>>>> [ndrl5] ~> klist
>>>>> Credentials cache: FILE:/tmp/krb5cc_5696
>>>>>         Principal: joon at BERKELEY.EDU
>
> The AuthKRB5 module tells you the principal it's using  
> "joon at BERKELY.EDU" which is consistent with what you get when you use  
> kinit. I don't think it's a principal problem.
>
> $0.02
>
> -JEff
>
> --
> 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