On 6/12/20 10:05 AM, Aparajita Singh wrote: > [Caused by GSSException: Failure unspecified at GSS-API level (Mechanism > level: Invalid argument (400) - Cannot find key of appropriate type to > decrypt AP REP - AES256 CTS mode with HMAC SHA1-96)]
Most likely the long-term key of the service as seen by the KDC does not match the entry in the keytab of the service. Each time you run the kadmin "ktadd" command, new keys are generated for the service, with a new key version number (kvno), and are added to the keytab on whatever machine you run it as. Any existing keytab file elsewhere is invalidated by the generation of new keys. Since you are using the same client and service principal name (why?), you may have provisioned keytab files for the same principal name on the client and server hosts. If you really need to use the same client and server principal name, you will need to provision one keytab file and copy it around (with scp or similar) rather than provision it separately on each machine. You can use "kvno zookeeper/stage-kdc-zk-2f...@stage.fdp.kafka" on the client to see what kvno of tickets the KDC issued to the client. You can use "klist -k" or "klist -k -t /path/to/keytab" to see the kvno present in a keytab file. As an aside, the instructions you reference are from 17 years ago. Please refer to https://web.mit.edu/kerberos/krb5-latest/doc/ ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
