[28647] in Kerberos
Re: gss_accept_sec_context
daemon@ATHENA.MIT.EDU (Ken Raeburn)
Fri Nov 2 16:02:08 2007
In-Reply-To: <4d569c330711021054n18d3c5een387102b38a822e7d@mail.gmail.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Message-Id: <A02AEC1B-BBCD-4D05-8414-18F704500A67@mit.edu>
From: Ken Raeburn <raeburn@mit.edu>
Date: Fri, 2 Nov 2007 16:01:32 -0400
To: Kevin Coffman <kwc@citi.umich.edu>
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
On Nov 2, 2007, at 13:54, Kevin Coffman wrote:
> On 11/2/07, Manoj Mohan <manojm@us.ibm.com> wrote:
>> when I did ktutil of my keytab file.. I had 2 entries (with KVNO
>> 2)...
>> I deleted the file and recreated it with ktadd but with -e option
>> to add only one
>> encryption type and then the accept_context worked.
>>
>> What is the usual practice? Should we always do ktadd with -e
>> option? Why is it
>> generating 2 entries when I do only ktadd (without -e) .. when in my
>> krb5.conf there is only one encryption listed like this:
>>
>> [libdefaults]
>> default_realm = EXAMPLE.IBM.COM
>> default_keytab_name = FILE:/etc/krb5.keytab
>> default_tkt_enctypes = des-cbc-crc
>> default_tgs_enctypes = des-cbc-crc
>
> ktadd does not look at those enctype definitions on the local machine
> where you run ktadd. What is used is the "supported_enctypes" defined
> for the realm in the kdc configuration. If your service doesn't
> support all the enctypes listed there, then you must limit the list
> with the -e option when doing the ktadd.
We wouldn't want to look at the *default* ticket encryption types on
the server anyways, but the set of supported enctypes on the server.
If that list isn't being used (as specified, or the compiled-in
default), in addition to the KDC-side restrictions, it's probably a
bug, I think.
Ken
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
