9:24 a.m.
[
https://issues.jboss.org/browse/TEIID-3803?page=com.atlassian.jira.plugin...
]
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#ac...
[5] https://github.com/postgres/postgres/blob/master/src/interfaces/libpq/fe-...
[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)
3338
days inactive
3338
days old
0 comments
1 participants
participants (1)
-
Ramesh Reddy (JIRA)