(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