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: javax.security.auth.login.LoginException: Invalid argument (400) - Cannot find key for type/kvno to decrypt AS REP - RC4 with HMAC/13
at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:804)
at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617)
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
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?
Ok,
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
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.
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?
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?)
ANd it worked. BUT: I needed to change this:
hadoop.rpc.protection 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…
Regarding the hadoop.rpc.protection 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.
