[teiid-issues] [JBoss JIRA] (TEIID-3803) Kerberos with ODBC with MutualAuth fails
Ramesh Reddy (JIRA)
issues at jboss.org
Thu Nov 5 10:24:00 EST 2015
[ https://issues.jboss.org/browse/TEIID-3803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13126022#comment-13126022 ]
Ramesh Reddy commented on TEIID-3803:
-------------------------------------
There couple different issues here, let me see if I can explain ..
In my test case has
- Windows 2008 Server that hosts Active Directory, another Windows 2008 machine used as ODBC client that was authenticated AD. The Teiid server is deployed in a RHEL 6 box, with kerberos enabled for ODBC transport. When the client issues a connection request to the Teiid server, the above error occurred, at this point there is no SSL configured.
- This leads to believe that, Kerberos is not working from Windows machine at all, however our previous tests with OpenLDAP and KDC server were successful, I am not sure if there were any attempts with Active Directory (possibly there were, not sure how the configuration there is different)
- The issue is Kerberos negotiation itself can request a Mutual Authentication at protocol level, by setting the "GSS_C_MUTUAL_FLAG" on request. In Java, the flag can be set on _GSSContext_ class using "GssContext.requestMutualAuth(true)". Even in Postgres ODBC with "libpq", this flag is set to true [5]. But according to [1] this flag is never validated on client side.
- However due to some unknown issue possibly [2], even when client requests with mutual auth flag to true, this is not approved by the KDC server and approves the connection with a response where Mutual Auth is set to false.
- When Mutual Auth is "false" it has side effect of not returning a token, which per Kerberos specification [3] 1.1.2. The corresponding text is
{quote}
context establishment sequence based on the Kerberos V5 mechanism
will perform one-way authentication (without confirmation or any
return token from target to initiator in response to the initiator's
KRB_AP_REQ) if the mutual_req bit is not set in the application's
call to GSS_Init_sec_context(). Applications requiring confirmation
that their authentication was successful should request mutual
authentication, resulting in a "mutual-required" indication within
KRB_AP_REQ APoptions and the setting of the mutual_req bit in the
flags field of the authenticator checksum. In response to such a
request, the context target will reply to the initiator with a token
containing either a KRB_AP_REP or KRB_ERROR, completing the mutual
context establishment exchange.
{quote}
also the same from _GSSContext _ Java Docs [4]
{quote}
Called by the context acceptor upon receiving a token from the peer. This method *may* return an output token which the application will need to send to the peer for further processing by its initSecContext call.
The application can call isEstablished to determine if the context establishment phase is complete for this peer. A return value of false from isEstablished indicates that more tokens are expected to be supplied to this method. Upon completion of the context establishment, the available context options may be queried through the get methods.
Note that it is possible that acceptSecContext return a token for the peer, and isEstablished return true also. This indicates that the token needs to be sent to the peer, but the local end of the context is now fully established.
{quote}
- so per above, it is possible to get a null token when the Mutual Auth is "false". The same situation when using a Java client is not exhibited. This leads to believe that, either there is a configuration setting in AD or something with encryption keys that is not being agreed upon between a Java VM and AD. I believe it uses strong DH algorithm here. However, even we fix this issue, the intention behind this mutual auth is token use the token for all further encryption purposes between server and client if needs to be. This is not *implemented* in Teiid. So, IMO this is no needed.
- But question remains is, one does not want to send Kerberos tokens in clear channel, for that you can configure SSL on ODBC transport in Teiid and configure SSL certificates on Windows client using [6] & [7]. Note that "PGGSS" environment variables did NOT work for me, I had to put certificates in my user directory. Also, on Windows ODBC DSN, set the "ssl-mode" to "verify-ca" or "verify-full". Note this SSL configuration can be independently used/configured without kerberos for validation. In this case, the SSL channel is created even before the kerberos authentication call is ever placed, and gives much better security based on your certificates than the perceived DH based negotiation.
- another note is do not specify the user name or dummy password on DSN configuration, when dealing with kerberos, that leads to unexplained errors, just leave them blank.
- Used QTODBC windows program for testing the ODBC connection and requests.
[1] http://www.postgresql.org/message-id/55B297BF.4010000@iki.fi
[2] https://technet.microsoft.com/en-us/library/cc781827(v=ws.10).aspx
[3] https://tools.ietf.org/html/rfc1964
[4] http://docs.oracle.com/javase/7/docs/api/org/ietf/jgss/GSSContext.html#acceptSecContext(byte[],%20int,%20int)
[5] https://github.com/postgres/postgres/blob/master/src/interfaces/libpq/fe-auth.c#L113
[6] https://wiki.postgresql.org/wiki/ODBC_Using_Windows_Cert_Store
[7] http://www.postgresql.org/docs/9.1/static/libpq-ssl.html
> 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.12.x
>
>
> 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