REST Web Service - Authentication Change (3.7 vs 4.1)

We have an internal API that we call using the REST POST Request node. The API is running on IIS and is secured using Windows authentication.

In version 3.7, we were able to retrieve data from this API successfully, using ‘None’ as the authentication option - the login context for the currently-logged-in Windows user was exchanged in the background.

In version 4.1, the same workflow fails with a 401 Unauthorized error. We have tried changing the authentication option to use NTLM and also tried setting up the Kerberos configuration in KNIME, on the off-chance that would help.

We have v3.7 and v4.1 on the same PC (and for sanity, have tried a couple of others) and still see the results above.

Any ideas?

1 Like

Hi @gtownsend,
Maybe you need to create a Kerberos configuration as described here: https://www.knime.com/blog/speaking-kerberos-with-knime-big-data-extensions? Step 3 is of course not required, and maybe not even step 2, if Kerberos should use your Windows credentials. If this setup is required for the big data extension, it might very well be that KNIME has to be made aware of Kerberos realm via config file for the POST Request node, too.
Kind regards
Alexander

2 Likes

Thanks @AlexanderFillbrunn -

I gave that a try (looks like it has changed a little in v4); setting it up for our local domain and logging in for good measure…

Trying the POST node afterwards still gives a 401 response, unfortunately. Tried it with both the None and NTLM authentication types, just to be sure. As far as I can tell so far, the REST components don’t seem to be aware of/use this configuration.

Appreciate the help!
Graham

1 Like

HI Alexander

I read this and wondered what you meant by the ‘config file for the POST request node’.
Is there a dedicated configuration file for each node? I’m very new to Knime so please accept my apologies if this is a silly question. I’m presuming you don’t mean through the ‘Configure’ option for the node in the Knime environment?

Regards and thanks in advance

David

Hi,
I meant the krb5.conf file mentioned in the link I posted. But as @gtownsend pointed out, this is not necessary anymore as KNIME now has a preference page for it.
Kind regards
Alexander

1 Like

Hi @gtownsend,
do you by any chance have a way of having a look into the request KNIME makes, either on the client using a tool like wireshark or on the server side in the server logs? It would be interesting to see what KNIME sends.
Kind regards,
Alexander

1 Like

Hi @AlexanderFillbrunn -

I’ve setup Wireshark to look on the client side. I don’t have access to the server or the server private key to decrypt it, but this is a summary of what I’ve been able to capture.

With KNIME 4, it records (all via TLS v1.2, with ‘S’ and ‘C’ indicating if the server/client sent the packet):

  • C: Client Hello
  • S: Server Hello, Certificate, Server Key Exchange, Server Hello Done
  • C: Client Key Exchange
  • S: Change Cipher Spec, Encrypted Handshake Message
  • C: Application Data (443 bytes, 139 bytes)
  • S: Application Data (747 bytes)

With KNIME 3.7, also all on TLS v1.2:

  • C: Client Hello
  • S: Server Hello, Certificate, Server Key Exchange, Server Hello Done
  • C: Client Key Exchange
  • S: Change Cipher Spec, Encrypted Handshake Message
  • C: Application Data (443 bytes, 139 bytes)
  • S: Application Data (747 bytes)
  • C: Encrypted Alert
  • —New Conversation Starts—
  • C: Client Hello
  • S: Server Hello, Change Cipher Spec, Encrypted Handshake Message
  • C: Change Cipher Spec
  • C: Encrypted Handshake Message
  • C: Application Data (539 bytes, 139 bytes)
  • S: Application Data (939 bytes)
  • C: Application Data (1051 bytes, 139 bytes)
  • S: Application Data (875 bytes)

So all seems identical until the point where the client sends the encrypted alert back to the server.

Graham

4 Likes

Hi Graham,
Attached you find an update site from which you can install a REST client backported from 4.1.2 to 3.7.2. Could you install that into a copy of your 3.7.2 KNIME where the REST worked and see if it still works after installing the extension from the update site? You can also install a KNIME 3.7.2 from here: https://www.knime.com/download-previous-versions. To install the extension from the zip, go to Help -> Install new Software… and then click on the “Add…” button. Here enter a name, e.g. “REST” and then click on the button “Archive…” and select the zip file. Now click OK and you should see the entry “Build artifacts from knime-rest” in the list of features. Expand that entry and select “KNIME REST Client Extension”. Then click next and confirm any dialogs until the installation starts. In the end you are asked to restart KNIME and then you can try your workflow. This would help us narrow down the cause of the error significantly. Thank you for your help!
Kind regards,
Alexander

rest_client_4.2.0_backported_to_3.8.0_20200429.zip (845.9 KB)

3 Likes

Thanks Alexander -

I’ve installed that extension into a copy of 3.7.2. Just as a sanity check -

After restarting the application and resetting the node, the REST POST request completes successfully. Wireshark is also showing an identical pattern for v3.7 as before the extension was installed.

Graham

2 Likes

Hi Graham,
Thank you very much with bearing with me here. I hope you are willing to do me another few favors. Can you:

  • Confirm that you find the “NTLM (Labs)” option also in 3.7.2 after installing the patched version (just to be sure it’s used)
  • On the Kerberos preference page click “Restore Defaults” (this should revert all custom settings to JVM defaults)
  • Add this property to the end of the knime.ini file: -Djava.security.krb5.debug=true (there is also a setting on the Kerberos preference pages to enable it; using a system property via knime.ini is more robust, though)
  • Restart KNIME with capturing system out and system error
  • Reproduce the problem and then send us the generated output

Almost completely unrelated: There is another “NTLM” option available when the Erlwood community extension is installed. Does that have any influence on the observe behavior? It should not, but given that all the authentication is so much baked into Java this might be different.

With the information gathered with the above steps our developers hope to be able to reproduce the behaviour and fix it for KNIME 4.2.

Kind regards,
Alexander

2 Likes

Hi Alexander -

No problem - I appreciate you looking at this. To check I’ve executed under the right conditions, I’ll try and be pedantic in my response:

In KNIME 3.7.2:

  • The NTLM (Labs) option is shown on the authentication tab of the POST request node.
  • It still executes successfully, using None as the authentication option.

In KNIME 4.1.2:

  • I clicked the Restore Defaults option on the Kerberos preferences page.
  • Added -Djava.security.krb5.debug=true to the knime.ini file.
  • Restarted KNIME, using the -consoleLog option on the command line (this was the only option I could find through searching - let me know if I need to do something else to get system out/error).
  • The output is below:

During startup:

CompilerOracle: exclude javax/swing/text/GlyphView.getBreakSpot
May 07, 2020 9:54:30 AM org.apache.cxf.bus.osgi.CXFExtensionBundleListener addExtensions
INFO: Adding the extensions from bundle org.apache.cxf.cxf-rt-transports-http (135) [org.apache.cxf.transport.http.HTTPTransportFactory, org.apache.cxf.transport.http.HTTPWSDLExtensionLoader, org.apache.cxf.transport.http.policy.HTTPClientAssertionBuilder, org.apache.cxf.transport.http.policy.HTTPServerAssertionBuilder, org.apache.cxf.transport.http.policy.NoOpPolicyInterceptorProvider]
May 07, 2020 9:54:30 AM org.apache.cxf.bus.osgi.CXFExtensionBundleListener addExtensions
INFO: Adding the extensions from bundle org.apache.cxf.cxf-rt-transports-http-hc (136) [org.apache.cxf.transport.http.HTTPConduitFactory, org.apache.cxf.transport.ConduitInitiator]
!SESSION 2020-05-07 09:54:23.128 -----------------------------------------------

eclipse.buildId=unknown
java.version=1.8.0_202
java.vendor=AdoptOpenJdk
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US
Command-line arguments:  -os win32 -ws win32 -arch x86_64 -consoleLog

!ENTRY org.eclipse.ui 2 0 2020-05-07 09:54:43.503
!MESSAGE Warnings while parsing the key bindings from the 'org.eclipse.ui.commands' and 'org.eclipse.ui.bindings' extension point
!SUBENTRY 1 org.eclipse.ui 2 0 2020-05-07 09:54:43.503
!MESSAGE Cannot bind to an undefined command: plug-in='org.knime.workbench.editor', id='knime.commands.editor.gridSettings'

!ENTRY org.eclipse.jface 2 0 2020-05-07 09:54:46.553
!MESSAGE Keybinding conflicts occurred.  They may interfere with normal accelerator operation.
!SUBENTRY 1 org.eclipse.jface 2 0 2020-05-07 09:54:46.553
!MESSAGE A conflict occurred for CTRL+F:
Binding(CTRL+F,
        ParameterizedCommand(Command(org.eclipse.ui.edit.findReplace,Find and Replace,
                Find and replace text,
                Category(org.eclipse.ui.category.edit,Edit,null,true),
                org.eclipse.ui.internal.WorkbenchHandlerServiceHandler@71ee2fff,

                ,,true),null),
        org.eclipse.ui.defaultAcceleratorConfiguration,
        org.eclipse.ui.contexts.window,,,system)
Binding(CTRL+F,
        ParameterizedCommand(Command(knime.commands.findnode,Find Node...,
                Finds a Node in the workflow.,
                Category(knime.command.category,KNIME Workflow Editor commands,Commands available for the workflow editor,true),
                org.eclipse.ui.internal.WorkbenchHandlerServiceHandler@68f2363,
                ,,true),null),
        org.eclipse.ui.defaultAcceleratorConfiguration,
        org.eclipse.ui.contexts.window,,,system)

!ENTRY org.eclipse.equinox.p2.core 4 0 2020-05-07 09:54:48.599
!MESSAGE Exception during event notification
!STACK 0
java.lang.IllegalArgumentException: Location must be absolute: ..
        at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.checkValidLocation(AbstractRepositoryManager.java:749)
        at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.contains(AbstractRepositoryManager.java:253)
        at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.addRepository(AbstractRepositoryManager.java:166)
        at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.notify(AbstractRepositoryManager.java:820)
        at org.eclipse.equinox.internal.p2.core.ProvisioningEventBus.dispatchEvent(ProvisioningEventBus.java:108)
        at org.eclipse.equinox.internal.p2.core.ProvisioningEventBus.dispatchEvent(ProvisioningEventBus.java:1)
        at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
        at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)

!ENTRY org.eclipse.equinox.p2.core 4 0 2020-05-07 09:54:48.631
!MESSAGE Exception during event notification
!STACK 0
java.lang.IllegalArgumentException: Location must be absolute: ..
        at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.checkValidLocation(AbstractRepositoryManager.java:749)
        at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.contains(AbstractRepositoryManager.java:253)
        at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.addRepository(AbstractRepositoryManager.java:166)
        at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.notify(AbstractRepositoryManager.java:820)
        at org.eclipse.equinox.internal.p2.core.ProvisioningEventBus.dispatchEvent(ProvisioningEventBus.java:108)
        at org.eclipse.equinox.internal.p2.core.ProvisioningEventBus.dispatchEvent(ProvisioningEventBus.java:1)
        at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
        at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)

When executing the node:

ERROR    KNIME-Worker-4-POST Request 0:1 Node    Execute failed: Wrong status: 401 Unauthorized
java.lang.IllegalStateException: Wrong status: 401 Unauthorized
        at org.knime.rest.nodes.common.RestNodeModel.checkResponse(RestNodeModel.java:793)
        at org.knime.rest.nodes.common.RestNodeModel.makeFirstCall(RestNodeModel.java:406)
        at org.knime.rest.nodes.common.RestNodeModel.execute(RestNodeModel.java:340)
        at org.knime.core.node.NodeModel.execute(NodeModel.java:737)
        at org.knime.core.node.NodeModel.executeModel(NodeModel.java:571)
        at org.knime.core.node.Node.invokeFullyNodeModelExecute(Node.java:1236)
        at org.knime.core.node.Node.execute(Node.java:1016)
        at org.knime.core.node.workflow.NativeNodeContainer.performExecuteNode(NativeNodeContainer.java:557)
        at org.knime.core.node.exec.LocalNodeExecutionJob.mainExecute(LocalNodeExecutionJob.java:95)
        at org.knime.core.node.workflow.NodeExecutionJob.internalRun(NodeExecutionJob.java:218)
        at org.knime.core.node.workflow.NodeExecutionJob.run(NodeExecutionJob.java:124)
        at org.knime.core.util.ThreadUtils$RunnableWithContextImpl.runWithContext(ThreadUtils.java:334)
        at org.knime.core.util.ThreadUtils$RunnableWithContext.run(ThreadUtils.java:210)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at org.knime.core.util.ThreadPool$MyFuture.run(ThreadPool.java:123)
        at org.knime.core.util.ThreadPool$Worker.run(ThreadPool.java:246)

Trying the Erlwood extension:

  • Installed the latest version of the two community Erlwood extensions.
  • Restarted KNIME.
  • Changed the POST request node to use the new NTLM authentication option.
  • Executed the node.
  • Received a 401 error.
  • In the console log, the error shown was the same - identical stack trace, with the only difference being a slightly different first line: ERROR KNIME-Worker-4-POST Request 2:1 Node Execute failed: Wrong status: 401 Unauthorized

If there’s anything I’ve missed on here, or more details that would help - please let me know.

Thanks,
Graham

1 Like

Hi @gtownsend

looping myself in here, as the developer of the KNIME Kerberos Integration. The steps that @AlexanderFillbrunn provided were coming from me and – unfortunately – not quite complete. Sorry for that!

It was correct to reset the Kerberos Preference Page back to defaults. But after that you still need to:

  1. On the Kerberos preference page:
  • (Re)activate the “Kerberos debug logging to KNIME log and Console”
  • Set the log level to ERROR
  1. Stop KNIME.
  2. Start KNIME using the -consoleLog option on the command line
  3. Rerun the failing node.

This should give you some output that (very roughly) looks like this:

WARN 	 Worker-2 KerberosLogger	 Java config name: null
WARN 	 Worker-2 KerberosLogger	 Native config name: /etc/krb5.conf
WARN 	 Worker-2 KerberosLogger	 Loaded from native config
[...]

If nothing of the sort shows up, this means that likely no Kerberos is being used (which then also means the KNIME Kerberos Integration is not the cause).

Best, Björn

3 Likes

Hi @bjoern.lohrmann -

Thanks for that additional detail - I’ve run this again in KNIME 4.1. Same configuration as the previous test, just with the Kerberos debug logging now set to ERROR. It looks like there are those messages you mentioned. Below is full output I see when executing (with just the tiniest of redaction):

ERROR    KNIME-Worker-3-POST Request 0:1 KerberosLogger  Java config name: null
LSA: Found Ticket
LSA: Made NewWeakGlobalRef
LSA: Found PrincipalName
LSA: Made NewWeakGlobalRef
LSA: Found DerValue
LSA: Made NewWeakGlobalRef
LSA: Found EncryptionKey
LSA: Made NewWeakGlobalRef
LSA: Found TicketFlags
LSA: Made NewWeakGlobalRef
LSA: Found KerberosTime
LSA: Made NewWeakGlobalRef
LSA: Found String
LSA: Made NewWeakGlobalRef
LSA: Found DerValue constructor
LSA: Found Ticket constructor
LSA: Found PrincipalName constructor
LSA: Found EncryptionKey constructor
LSA: Found TicketFlags constructor
LSA: Found KerberosTime constructor
LSA: Finished OnLoad processing
ERROR    KNIME-Worker-3-POST Request 0:1 KerberosLogger  Native config name: C:\Windows\krb5.ini
ERROR    KNIME-Worker-3-POST Request 0:1 KerberosLogger  Search Subject for SPNEGO INIT cred (<<DEF>>, sun.security.jgss.spnego.SpNegoCredElement)
ERROR    KNIME-Worker-3-POST Request 0:1 KerberosLogger  No Subject
ERROR    KNIME-Worker-3-POST Request 0:1 KerberosLogger  Search Subject for Kerberos V5 INIT cred (<<DEF>>, sun.security.jgss.krb5.Krb5InitCredential)
ERROR    KNIME-Worker-3-POST Request 0:1 KerberosLogger  No Subject
ERROR    KNIME-Worker-3-POST Request 0:1 KerberosLogger  >>>KinitOptions cache name is C:\Users\########\krb5cc_########
ERROR    KNIME-Worker-3-POST Request 0:1 KerberosLogger  >> Acquire default native Credentials
ERROR    KNIME-Worker-3-POST Request 0:1 KerberosLogger  Using builtin default etypes for default_tkt_enctypes
ERROR    KNIME-Worker-3-POST Request 0:1 KerberosLogger  default etypes for default_tkt_enctypes: 18 17 16 23.
LSA: Found KrbCreds constructor
LSA: Got handle to Kerberos package
LSA: Response size is 4689
LSA: TICKET SessionKey KeyType is 18
LSA: Valid etype found: 18
LSA: Principal domain is ########.COM
LSA: Name type is 1
LSA: Name count is 1
LSA: Principal domain is ########.COM
LSA: Name type is 2
LSA: Name count is 2
LSA: Session key all zero. Stop.
ERROR    KNIME-Worker-3-POST Request 0:1 KerberosLogger  >>> Found no TGT's in LSA
ERROR    KNIME-Worker-3-POST Request 0:1 KerberosLogger  Negotiate support not initiated, will fallback to other scheme if allowed. Reason:
GSSException: No valid credentials provided (Mechanism level: No valid credentials provided (Mechanism level: Attempt to obtain new INITIATE credentials failed! (null)))
        at sun.security.jgss.spnego.SpNegoContext.initSecContext(SpNegoContext.java:454)
        at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
        at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
        at sun.net.www.protocol.http.spnego.NegotiatorImpl.init(NegotiatorImpl.java:108)
        at sun.net.www.protocol.http.spnego.NegotiatorImpl.<init>(NegotiatorImpl.java:117)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
        at sun.net.www.protocol.http.Negotiator.getNegotiator(Negotiator.java:63)
        at sun.net.www.protocol.http.NegotiateAuthentication.isSupportedImpl(NegotiateAuthentication.java:138)
        at sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:111)
        at sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHeader.java:200)
        at sun.net.www.protocol.http.AuthenticationHeader.<init>(AuthenticationHeader.java:143)
        at sun.net.www.protocol.http.AuthenticationHeader.<init>(AuthenticationHeader.java:123)
        at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1714)
        at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492)
        at sun.net.www.protocol.http.HttpURLConnection.getHeaderFields(HttpURLConnection.java:3074)
        at sun.net.www.protocol.https.HttpsURLConnectionImpl.getHeaderFields(HttpsURLConnectionImpl.java:292)
        at org.apache.cxf.transport.http.Headers.readFromConnection(Headers.java:258)
        at org.apache.cxf.transport.http.URLConnectionHTTPConduit$URLConnectionWrappedOutputStream.updateCookiesBeforeRetransmit(URLConnectionHTTPConduit.java:297)
        at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleRetransmits(HTTPConduit.java:1409)
        at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1545)
        at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1347)
        at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
        at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:651)
        at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
        at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
        at org.apache.cxf.jaxrs.client.AbstractClient.doRunInterceptorChain(AbstractClient.java:649)
        at org.apache.cxf.jaxrs.client.WebClient.doInvokeAsync(WebClient.java:984)
        at org.apache.cxf.jaxrs.client.WebClient$AsyncInvokerImpl.method(WebClient.java:1486)
        at org.apache.cxf.jaxrs.client.spec.InvocationBuilderImpl$InvocationImpl.submit(InvocationBuilderImpl.java:360)
        at org.knime.rest.nodes.common.RestNodeModel.invoke(RestNodeModel.java:481)
        at org.knime.rest.nodes.common.RestNodeModel.makeFirstCall(RestNodeModel.java:371)
        at org.knime.rest.nodes.common.RestNodeModel.execute(RestNodeModel.java:340)
        at org.knime.core.node.NodeModel.execute(NodeModel.java:737)
        at org.knime.core.node.NodeModel.executeModel(NodeModel.java:571)
        at org.knime.core.node.Node.invokeFullyNodeModelExecute(Node.java:1236)
        at org.knime.core.node.Node.execute(Node.java:1016)
        at org.knime.core.node.workflow.NativeNodeContainer.performExecuteNode(NativeNodeContainer.java:557)
        at org.knime.core.node.exec.LocalNodeExecutionJob.mainExecute(LocalNodeExecutionJob.java:95)
        at org.knime.core.node.workflow.NodeExecutionJob.internalRun(NodeExecutionJob.java:218)
        at org.knime.core.node.workflow.NodeExecutionJob.run(NodeExecutionJob.java:124)
        at org.knime.core.util.ThreadUtils$RunnableWithContextImpl.runWithContext(ThreadUtils.java:334)
        at org.knime.core.util.ThreadUtils$RunnableWithContext.run(ThreadUtils.java:210)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at org.knime.core.util.ThreadPool$MyFuture.run(ThreadPool.java:123)
        at org.knime.core.util.ThreadPool$Worker.run(ThreadPool.java:246)
Caused by: GSSException: No valid credentials provided (Mechanism level: Attempt to obtain new INITIATE credentials failed! (null))
        at sun.security.jgss.krb5.Krb5InitCredential.getTgt(Krb5InitCredential.java:345)
        at sun.security.jgss.krb5.Krb5InitCredential.getInstance(Krb5InitCredential.java:145)
        at sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:122)
        at sun.security.jgss.krb5.Krb5MechFactory.getMechanismContext(Krb5MechFactory.java:187)
        at sun.security.jgss.GSSManagerImpl.getMechanismContext(GSSManagerImpl.java:224)
        at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:212)
        at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
        at sun.security.jgss.spnego.SpNegoContext.GSS_initSecContext(SpNegoContext.java:882)
        at sun.security.jgss.spnego.SpNegoContext.initSecContext(SpNegoContext.java:317)
        ... 48 more
Caused by: javax.security.auth.login.LoginException: No password provided
        at com.sun.security.auth.module.Krb5LoginModule.promptForPass(Krb5LoginModule.java:919)
        at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:760)
        at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at javax.security.auth.login.LoginContext.invoke(LoginContext.java:755)
        at javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
        at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
        at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
        at java.security.AccessController.doPrivileged(Native Method)
        at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
        at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
        at sun.security.jgss.GSSUtil.login(GSSUtil.java:258)
        at sun.security.jgss.krb5.Krb5Util.getTicket(Krb5Util.java:158)
        at sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:337)
        at sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:333)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.security.jgss.krb5.Krb5InitCredential.getTgt(Krb5InitCredential.java:332)
        ... 56 more
ERROR    KNIME-Worker-3-POST Request 0:1 Node    Execute failed: Wrong status: 401 Unauthorized
java.lang.IllegalStateException: Wrong status: 401 Unauthorized
        at org.knime.rest.nodes.common.RestNodeModel.checkResponse(RestNodeModel.java:793)
        at org.knime.rest.nodes.common.RestNodeModel.makeFirstCall(RestNodeModel.java:406)
        at org.knime.rest.nodes.common.RestNodeModel.execute(RestNodeModel.java:340)
        at org.knime.core.node.NodeModel.execute(NodeModel.java:737)
        at org.knime.core.node.NodeModel.executeModel(NodeModel.java:571)
        at org.knime.core.node.Node.invokeFullyNodeModelExecute(Node.java:1236)
        at org.knime.core.node.Node.execute(Node.java:1016)
        at org.knime.core.node.workflow.NativeNodeContainer.performExecuteNode(NativeNodeContainer.java:557)
        at org.knime.core.node.exec.LocalNodeExecutionJob.mainExecute(LocalNodeExecutionJob.java:95)
        at org.knime.core.node.workflow.NodeExecutionJob.internalRun(NodeExecutionJob.java:218)
        at org.knime.core.node.workflow.NodeExecutionJob.run(NodeExecutionJob.java:124)
        at org.knime.core.util.ThreadUtils$RunnableWithContextImpl.runWithContext(ThreadUtils.java:334)
        at org.knime.core.util.ThreadUtils$RunnableWithContext.run(ThreadUtils.java:210)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at org.knime.core.util.ThreadPool$MyFuture.run(ThreadPool.java:123)
        at org.knime.core.util.ThreadPool$Worker.run(ThreadPool.java:246)

Some notes:

  • The principal domain that was found was the correct one.
  • I tried creating a krb5.ini file in the location it was searching for, based on the instructions @AlexanderFillbrunn mentioned before and running the process again.
    • No difference, except an additional Loaded from native context message.

Hopefully this helps, but please let me know if there’s anything else I can run here.

Thanks,
Graham

3 Likes

Hi @gtownsend

apologies for the late reply, we are currently working hard towards our release in July. Thank you for the logs, they are quite helpful any I think I have an idea what is going on. The important log line is this one:

LSA: Session key all zero. Stop.

In your setup, KNIME is trying to read the Kerberos ticket from via the native Windows ticket cache API (LSA). The behavior of that API has changed since its inception to not disclose the Kerberos session key anymore. If you want to keep your setup as it is, your best option is to set a Windows registry key that allows said API to disclose the Kerberos session key. Please read the javax.security.auth.login.LoginException: KrbException: KDC has no support for encryption type (14) - KDC has no support for encryption type section in this document for specifics :

https://docs.oracle.com/javase/8/docs/technotes/guides/security/jgss/tutorials/Troubleshooting.html

You should edit the windows registry w.r.t. the allowtgtsessionkey key (see “solution 2”).

If you want a little more context, you can read through this Java bug report (see the comment that mentions “Session key all zero”):

https://bugs.openjdk.java.net/browse/JDK-8164217

Best,
Björn

6 Likes

Thanks @bjoern.lohrmann -

Appreciate the update. Will look forward to the update, but will use the workaround until then!

Graham

2 Likes

Hi Bjorn

Did the fix find its way into the 4.2 release? I have installed it but am finding the same issues.
If the Registry workaround detailed above is applicable to 4.2 I will try and get someone to implement.it.

Thanks for your ongoing support and responsiveness

regards

David