Integrating Kerberos with a Java application using JAAS
Greg Hudson
ghudson at mit.edu
Fri Jun 12 11:48:16 EDT 2020
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-2face at 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/
More information about the Kerberos
mailing list