gss_accept_sec_context

[Kevin Coffman]

On 11/2/07, Manoj Mohan <manojm at us.ibm.com> wrote:
>
>
> Thanks Kevin.. that suggestion helped a lot!!
>
>  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.

>  Another strange observation is that...when I add service key to keytab file via ktadd..
>  and then performed kinit for the service.. kinit fails like this:
>
>  kinit sso_11x/lxvm-l141.ibm.com
>  Password for sso_11x/lxvm-l141.ibm.com at EXAMPLE.IBM.COM:
>  kinit(v5): Password incorrect while getting initial credentials
>
>  The password I provided is correct.
>
>  It works only when i do kinit first followed by ktadd. The reverse is not working.
>  What is the reason for this ?

ktadd generates a new random key and puts it in both the keytab file
and in the KDC's database.  That key is not based on a password.  In
order to use the new random key with kinit, you need to specify:

kinit -k -t <keytab_file> sso_11x/lxvm-l141.ibm.com