More or less- the only difference is that it says:
GSS-API error initializing context: SPNEGO failed to negotiate a mechanism
rather than
GSS-API error initializing context: Generic RADIUS failure
The only other difference in behaviour between SPNEGO and specifying the
mechanism explicitly is with SPNEGO I don't get "GSS-API error accepting
context: Unknown code rse 17" in my gss-server output. In both cases I
see no activity on the RADIUS side nor any attempts being made to access
RADIUS.
On 09/07/13 20:00, Rhys Smith wrote:
> Do you get the same failure when specifying the mech as well as using SPNEGO?
>
> i.e.
>
> gss-client -mech "{1.3.6.1.5.5.15.1.1.18 }" 127.0.0.1 host@localhost bar
> vs
> gss-client -spnego 127.0.0.1 host@localhost bar
>
>
> Also, you've definitely got selinux disabled?
>
> Rhys.
>
>
> On 9 Jul 2013, at 15:15, Mark Cairney <[log in to unmask]> wrote:
>
>> OK I've set the hostname to be 127.0.0.1 and disabled IPv6 by:
>> echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6
>> echo 1 > /proc/sys/net/ipv6/conf/default/disable_ipv6
>>
>> I can confirm that /etc/gss/mech contains:
>>
>> #
>> # Sample mechanism glue configuration for EAP GSS mechanism.
>> #
>> # Any encryption type supported by Kerberos can be defined as the
>> # last element of the OID arc.
>> #
>> eap-aes128 1.3.6.1.5.5.15.1.1.17 mech_eap.so
>> eap-aes256 1.3.6.1.5.5.15.1.1.18 mech_eap.so
>> /etc/gss/mech (END)
>>
>> I'm assuming the freeradius - shib hooks are OK from my radtest output.
>>
>> I don't get any errors in gss-server if I output the log file however not outputting the logfile and running gss-server in the fg yields:
>>
>> gss-server -verbose host@moonshot-test.is.ed.ac.ukstarting...
>> Received token (size=53):
>> 60 33 06 09 2b 06 01 05 05 0f 01 01 12 06 01 00
>> 00 00 02 00 00 00 1e 68 6f 73 74 2f 6d 6f 6f 6e
>> 73 68 6f 74 2d 74 65 73 74 2e 69 73 2e 65 64 2e
>> 61 63 2e 75 6b
>> Sending accept_sec_context token (size=66):
>> 60 40 06 09 2b 06 01 05 05 0f 01 01 12 06 02 00
>> 00 00 03 00 00 00 1e 68 6f 73 74 2f 6d 6f 6f 6e
>> 73 68 6f 74 2d 74 65 73 74 2e 69 73 2e 65 64 2e
>> 61 63 2e 75 6b 80 00 00 05 00 00 00 05 01 00 00
>> 05 01
>> continue needed...
>> Received token (size=29):
>> 60 1b 06 09 2b 06 01 05 05 0f 01 01 12 06 01 80
>> 00 00 04 00 00 00 06 02 00 00 06 01 40
>> Sending accept_sec_context token (size=31):
>> 60 1d 06 09 2b 06 01 05 05 0f 01 01 12 06 02 80
>> 00 00 01 00 00 00 08 00 0d 00 00 00 00 00 10
>> GSS-API error accepting context: Unspecified GSS failure. Minor code may provide more information
>> GSS-API error accepting context: Unknown code rse 17
>>
>> I'm hoping that error code means more to one of you than it does to me! :-)
>>
>>
>>
>>
>> On 09/07/13 14:53, Sam Hartman wrote:
>>> Looking at your radsec.conf I'd recommend using 127.0.0.1 rather than
>>> localhost, but you say you've tried that already.
>>> Our RADIUS library supports IPv6, but the version of Freeradius you're
>>> using does not, and so sometimes localhost means ::1.
>>>
>>> However, since you've already tried that, I don't know what is going on.
>>> The gss-server error will be more useful than the gss-client error but
>>> it's probably connection refused.
>>>
>>
>> --
>> /****************************
>>
>> Mark Cairney
>> ITI UNIX Section
>> Information Services
>> University of Edinburgh
>>
>> Tel: 0131 650 6565
>> Email: [log in to unmask]
>>
>> *******************************/
>>
>> The University of Edinburgh is a charitable body, registered in
>> Scotland, with registration number SC005336.
>
>
--
/****************************
Mark Cairney
ITI UNIX Section
Information Services
University of Edinburgh
Tel: 0131 650 6565
Email: [log in to unmask]
*******************************/
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
|