On 11/2/07, Manoj Mohan <[EMAIL PROTECTED]> 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/[EMAIL PROTECTED]: > 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 ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos