[teiid-issues] [JBoss JIRA] (TEIID-3803) Kerberos with ODBC with MutualAuth fails

Ramesh Reddy (JIRA) issues at jboss.org
Tue Mar 8 12:16:02 EST 2016


    [ https://issues.jboss.org/browse/TEIID-3803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13173750#comment-13173750 ] 

Ramesh Reddy edited comment on TEIID-3803 at 3/8/16 12:15 PM:
--------------------------------------------------------------

There were couple issues, 
1) The changes related to TEIID-3803 were lost during the merge of TEIID-3818 + TEIID-3874 + TEIID-3663
2) The changes related to TEIID-3375, where an additional "AuthenticationGssContinue" added, is failing with windows based client, where the client fails with dummy token used for login continuation for Teiid ODBC <-> JDBC session creation.

The fix is is avoid sending the "AuthenticationGssContinue" in the case when authentication succeeded, but no valid token is available.

The real issue is even though the "mutual auth" is turned on ODBC, with Active Directory there is no peer token provided at the end, KDC does. And sending a dummy token to a Linux ODBC client does not end up in error, where as Windows ODBC one does (which IMO is correct behavior).

The latest commit is address above issues correctly by not sending a "AuthenticationGssContinue" in the case where no peer token is issued. 


was (Author: rareddy):
There were couple issues, 
1) The changes related to TEIID-3803 were lot during the merge of TEIID-3818 + TEIID-3874 + TEIID-3663
2) The changes related to TEIID-3375, where an additional "AuthenticationGssContinue" added, is failing with windows based client, where the client fails with dummy token used for login continuation for Teiid ODBC <-> JDBC session creation.

The fix is is avoid sending the "AuthenticationGssContinue" in the case when authentication succeeded, but no valid token is available.

The real issue is even though the "mutual auth" is turned on ODBC, with Active Directory there is no peer token provided at the end, KDC does. And sending a dummy token to a Linux ODBC client does not end up in error, where as Windows ODBC one does (which IMO is correct behavior).

The latest commit is address above issues correctly by not sending a "AuthenticationGssContinue" in the case where no peer token is issued. 

> Kerberos with ODBC with MutualAuth fails
> ----------------------------------------
>
>                 Key: TEIID-3803
>                 URL: https://issues.jboss.org/browse/TEIID-3803
>             Project: Teiid
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 8.4
>            Reporter: Ramesh Reddy
>            Assignee: Ramesh Reddy
>             Fix For: 8.7.2.6_2, 8.12.2, 8.13, 8.7.6
>
>
> When Active Directory is used for Kerberos authentication, and Windows ODBC client issues connection request it may fail with following exception. 
> {code}
> 00:29:15,561 ERROR [org.teiid.ODBC] (New I/O worker #19) TEIID40015 Unexpected error occurred: org.teiid.client.security.LogonException: TEIID40014 Kerberos context login failed
> 	at org.teiid.transport.LogonImpl.neogitiateGssLogin(LogonImpl.java:203) [teiid-runtime-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> 	at org.teiid.odbc.ODBCServerRemoteImpl.logon(ODBCServerRemoteImpl.java:236) [teiid-runtime-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_79]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_79]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_79]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_79]
> 	at org.teiid.transport.ODBCClientInstance.processMessage(ODBCClientInstance.java:127) [teiid-runtime-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> 	at org.teiid.transport.ODBCClientInstance.receivedMessage(ODBCClientInstance.java:116) [teiid-runtime-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> 	at org.teiid.transport.SSLAwareChannelHandler.messageReceived(SSLAwareChannelHandler.java:211) [teiid-runtime-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> 	at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:88) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> 	at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:462) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:443) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:310) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> 	at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> 	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> 	at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> 	at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:109) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> 	at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:328) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> 	at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:90) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> 	at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> 	at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> 	at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_79]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_79]
> 	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_79]
> Caused by: javax.security.auth.login.LoginException: TEIID50103 Wrong Response returned from teiid-security security domain; Expecting a Kerberoes response
> 	at org.teiid.jboss.JBossSessionService.buildGSSResult(JBossSessionService.java:138) [teiid-jboss-integration-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> 	at org.teiid.jboss.JBossSessionService.neogitiateGssLogin(JBossSessionService.java:106) [teiid-jboss-integration-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> 	at org.teiid.services.SessionServiceImpl.neogitiateGssLogin(SessionServiceImpl.java:545) [teiid-runtime-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> 	at org.teiid.transport.LogonImpl.neogitiateGssLogin(LogonImpl.java:173) [teiid-runtime-8.7.4.redhat-1.jar:8.7.4.redhat-1]
> 	... 30 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


More information about the teiid-issues mailing list