KNIME + Keytab that works on Linux - Issue

Hello - so I have created keytab on LInux (and it works), but when using it with Big Data Extension I am getting this issue:
aused by: Invalid argument (400) - Cannot find key for type/kvno to decrypt AS REP - RC4 with HMAC/13

I am getting this error during using keytab with any of this encryption type:
aes256-cts aes128-cts arcfour-hmac-md5 des-cbc-md5 des-cbc-crc

Anyone had this issue?

Hey @zebov
This fault could come from different reasons, did you ensure that the service principal is correctly configured to match the keytab?
How did you test the keytab is working?

best regards Mareike

Hello Mareike. I tested in on Linux after generation and it was indeed working.

so is assume you used kinit -kt keytabfile user@EXAMPLE.COM to get a ticket, and that worked. And you are using the keytab with KNIME on the same machine?

The above fault can either mean the KNIME is not able to access the keytab file (wrong path, wrong permissions), that the principal is not identical in keytab and the KNIME configuration or that indeed the encryptions or KVNO does not match.

Could you run a klist -kte on your keytab file and check the decrypt types and KVNO listed there? You will also see the principal in the listing and could recheck.

Hello Mareike, thank you very much for help. Indeed I have tested this and please find obfuscated output below:
[root@TMCX ~]# kdestroy
[root@TMCX ~]# klist
klist: No credentials cache found (filename: /tmp/krb5cc_0)
[root@TMCX ~]# kinit -kt npd.keytab ku01@DOMAIN.LOCAL
[root@TMCX ~]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: ku01@DOMAIN.LOCAL

Valid starting Expires Service principal
04/12/18 10:36:21 04/12/18 20:36:21 krbtgt/DOMAIN.LOCAL@DOMAIN.LOCAL
renew until 05/12/18 10:36:21
[root@TMCX ~]# klist -kte npd.keytab
Keytab name: FILE:npd.keytab
KVNO Timestamp Principal

-1 27/11/18 15:10:42 ku01.DOMAIN.LOCAL@DOMAIN.LOCAL (aes256-cts-hmac-sha1-96)
-1 27/11/18 15:12:10 ku01@DOMAIN.LOCAL (aes256-cts-hmac-sha1-96)
-1 27/11/18 15:16:31 ku01@DOMAIN.LOCAL (aes256-cts-hmac-sha1-96)
[root@TMCX ~]#

Two things I see there, the enctype differs from the one in the keytab. aes256-cts-hmac-sha1-96 differs from the rc4-hmac (which is actually deprecated).
Where do you got your krb5.conf from? Is it from one of the instances you want to connect to?
Could you check in krb5.conf default_tkt_enctypes,default_tgs_enctypes and permitted_enctypes and check if it contains rc4-hmac. If not, try to add it and recreate a keytab.

The other thing is the KVNO. Did you generate a new tickets at the KDC after you created the keytab file?
The keytab states a KVNO of -1 which seems strange to me anyway. But it is definitely out of synch as the error massage states to search for KVNO 13
Did you pass a initial KVNO on keytab creation?

Are you using the keytab on the same machine you created it on? If not, do the krb5.conf differ?

Q1: Where do you got your krb5.conf from? Is it from one of the instances you want to connect to?
A1: Yes, krb5.conf is located here, it was copied from appropriate machine as well: Downloads\knime_3.5.2\plugins\org.knime.binary.jre.win32.x86_64_1.8.0.152-01\jre\lib\security
Permitted encryption types:
permitted_enctypes = aes256-cts aes128-cts arcfour-hmac-md5 des-cbc-md5 des-cbc-crc
This is how i created keytab:
add_entry -password -p USERNAME@DOMAIN.LOCAL -k -1 -e arcfour-hmac-md5

No net tickets were generated on KDC. NO initial KVNO was passed on keytab creation.
I am using it from other machine (test machine) trying to reach the service from KNIME installed on it. Also the path to krb5.conf is in ini.

I have followed this:
I have an active ticket right now on this machine… What else should i check?

could you try use the rc4-hmac enctype in add_entry instead of arcfour-hmac-md5? And add rc4-hmac to the permitted types and try again.

Hello I tried it already and its the same error. I may think there is something with AD Kerberos configuration - would it be the case? I am not admin and dont have access to server only client configuration here possible… It works on Linux - on windows getting this error, but Network Identity Manager is able to connect and get ticket. I think there may be something not only with keytab but in general kerberos config here. What is your opinnion?

Ok, but than that is not the keytab you have shown the klist from.
Even if you have the correct enctype you migth run into an issue with the KVNO because AD increases it with every ktpass.
So you might need to add the KVNO in add-entry to.
and here

For more information about this.

Thanks for replies, I will ask my admin if we can do it - I do not have access to Kerberos server configuration (neither kerberos config in our AD - and I assume this is where changes need to be?)

Well no,
you just need to throw away the current keytab and create a new keytab with the rc4-hmac enctype, and you should be fine.

You actually passed a KVNO with the -k flag (-1 in your case) when you used add_entry, that does not match the KVNO at the KDC.

Hi. Yes I am getting somewhere now:

ktutil: add_entry -password -p USER@DOMAIN.LOCAL -k 3 -e rc4-hmac

ANd it worked. BUT: I needed to change this: from AUTHENTICATION TO PRIVACY. Otherwise even when both set to AUTHENTICATION (BY both i mean HDFS settings and my KNIME used XMLs (core + hdfs sites xmls ) it was returning an error:
“No common protection between client and server”

I wonder why it did not work with Authentication? Both settings in xmls on KNIME side and on the server were using Authentication after all…

Thank you Mareike for your help!

Hey @zebov
Nice to here that it is working now.

Regarding the question:
This setting has to be the same value as the setting in the cluster. So it should have worked with AUTHENTICATION, if it was set to this on the server to.
Maybe you missed to restart after setting it to AUTHENTICATION?

Hey, I also thought so but I double checked and both files had authentication (and it was restarted) on it and still did not work (both settings on cluster and xmls used by KNIME). So no idea here - anyhow -you can maybe put it as notes in KNIME configuration manual so it could be useful for others if they will face this issue. Privacy is anyway good settings as its actually encrypts the traffic according to cloudera post.

Thanks for help!!!

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.