Bug 1254532 (TEIID-3643) - VDB based kerberos authentication does not work with ODBC
Summary: VDB based kerberos authentication does not work with ODBC
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: TEIID-3643
Product: JBoss Data Virtualization 6
Classification: JBoss
Component: Teiid
Version: 6.2.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: jolee
QA Contact: Juraj Duráni
URL:
Whiteboard:
Depends On:
Blocks: 1242071
TreeView+ depends on / blocked
 
Reported: 2015-08-18 10:32 UTC by Juraj Duráni
Modified: 2019-08-15 05:08 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-02-10 08:56:08 UTC
Type: Support Patch
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker TEIID-3643 0 Major Closed VDB based kerberos authentication does not work with ODBC 2019-09-19 01:14:38 UTC

Description Juraj Duráni 2015-08-18 10:32:45 UTC
I have a VDB configured to use GSS authentication. Both, JDBC and ODBC ports are configured to use default "teiid-security" security domain. Accessing the VDB through JDBC works fine, but ODBC throws exception [1], [2]. If the ODBC port is configured to use GSS authentication, connection is successful.

[1]
isql -v krb
[08001][unixODBC]could not connect to server: Spojenie odmietnut
Is the server running on host "localhost" (::1) and accepting
TCP/IP connections on port 35432?
ERROR: TEIID40055 Wrong logon method is being used. Server is not set up for Kerberos based authentication.
DETAIL: org.teiid.jdbc.TeiidSQLException: TEIID40055 Wrong logon method is being used. Server is not set up for Kerberos based authentication.

[ISQL]ERROR: Could not SQLConnect
[2]
11:49:56,470 ERROR [org.teiid.ODBC] (New I/O worker #3) TEIID40015 Unexpected error occurred: org.teiid.client.security.LogonException: TEIID40055 Wrong logon method is being used. Server is not set up for Kerberos based authentication.
at org.teiid.transport.LogonImpl.neogitiateGssLogin(LogonImpl.java:168) [teiid-runtime-8.7.1.6_2-redhat-4.jar:8.7.1.6_2-redhat-4]
at org.teiid.odbc.ODBCServerRemoteImpl.logon(ODBCServerRemoteImpl.java:237) [teiid-runtime-8.7.1.6_2-redhat-4.jar:8.7.1.6_2-redhat-4]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_40]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_40]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_40]
at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_40]
at org.teiid.transport.ODBCClientInstance.processMessage(ODBCClientInstance.java:127) [teiid-runtime-8.7.1.6_2-redhat-4.jar:8.7.1.6_2-redhat-4]
at org.teiid.transport.ODBCClientInstance.receivedMessage(ODBCClientInstance.java:116) [teiid-runtime-8.7.1.6_2-redhat-4.jar:8.7.1.6_2-redhat-4]
at org.teiid.transport.SSLAwareChannelHandler.messageReceived(SSLAwareChannelHandler.java:211) [teiid-runtime-8.7.1.6_2-redhat-4.jar:8.7.1.6_2-redhat-4]
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:303) [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:1142) [rt.jar:1.8.0_40]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_40]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_40]


Steps to reproduce:


Teiid configuration: [1]
VDB: [2]
Client.conf: [3]
Java application: [4]
ODBC datasource: [5]
ODBC connection: isql -v krb

[1]
<system-properties>
    <property name="java.security.krb5.kdc" value="my.host"/>
    <property name="java.security.krb5.realm" value="EXAMPLE.COM"/>
    <property name="java.security.krb5.debug" value="true"/>
</system-properties>
...
<security-domain name="host">
    <authentication>
        <login-module code="Kerberos" flag="required" module="org.jboss.security.negotiation">
            <module-option name="storeKey" value="true"/>
            <module-option name="useKeyTab" value="true"/>
            <module-option name="keyTab" value="${jboss.home.dir}/psql.keytab"/>
            <module-option name="principal" value="postgres/localhost"/>
            <module-option name="doNotPrompt" value="true"/>
            <module-option name="useTicketCache" value="true"/>
            <module-option name="debug" value="true"/>
            <module-option name="refreshKrb5Config" value="false"/>
        </login-module>
    </authentication>
</security-domain>
<security-domain name="EXAMPLE.COM">
    <authentication>
        <login-module code="SPNEGO" flag="requisite" module="org.jboss.security.negotiation">
            <module-option name="password-stacking" value="useFirstPass"/>
            <module-option name="serverSecurityDomain" value="host"/>
        </login-module>
    </authentication>
    <mapping>
        <mapping-module code="SimpleRoles" type="roles">
            <module-option name="user" value="admin"/>
        </mapping-module>
    </mapping>
</security-domain>
...
<transport name="jdbc" socket-binding="teiid-jdbc" protocol="teiid">
    <authentication security-domain="teiid-security"/>
</transport>
<transport name="odbc" socket-binding="teiid-odbc" protocol="pg">
    <authentication security-domain="teiid-security"/>
</transport>

[2]
<vdb name="vdb_odbc" version="1">
    <property name="security-domain" value="EXAMPLE.COM"/>
    <property name="authentication-type" value="GSS"/>
...
</vdb>

[3]
client{ com.sun.security.auth.module.Krb5LoginModule required
 storeKey="true"
 useKeyTab="true"
 keyTab="/path/to/user.keytab"
 principal="user"
 doNotPrompt="true"
 refreshKrb5Config="false"
 useTicketCache="true"
 debug="true";
};

[4]
TeiidDataSource tds = new TeiidDataSource();
tds.setServerName("jdv.host");
tds.setPortNumber(31000);
tds.setDatabaseName("vdb_odbc");
tds.setJaasName("client");
tds.setKerberosServicePrincipleName("postgres/localhost");
Connection con = tds.getConnection();

[5]
[krb]
Driver = /opt/redhat/jboss-dv/v6/psqlodbc/lib64/psqlodbc.so
Description = PostgreSQL Data Source
DSN = krb
Servername = localhost
Port = 35432
Protocol = 7.4-1
UserName = user
Database = vdb_odbc
ReadOnly = no
ServerType = Postgres
ConnSettings =
UseServerSidePrepare=1
ByteaAsLongVarBinary=1
Optimizer=0
Ksqo=0
Debug=0
Fetch = 10000

Comment 1 Van Halbert 2015-08-18 12:40:02 UTC
That is expected behavior.  The client is not in charge of how they authenticate over the pg protocol.  It must be determined from the session service authentication type, the vdb authentication type property, or the vdb gss pattern property.

Comment 2 Van Halbert 2015-08-18 13:50:10 UTC
Reopened by the project.

Comment 3 jolee 2015-09-30 13:45:04 UTC
git:jboss-integration/teiid.git : 8.7.x-prod-ipv6.2 : cc7270c

git:teiid/teiid.git : 62-8.7.x : cc7270c

Comment 5 Juraj Duráni 2015-10-21 11:24:07 UTC
Verified.

Comment 7 JBoss JIRA Server 2016-06-17 12:40:27 UTC
Steven Hawkins <shawkins> updated the status of jira TEIID-3643 to Closed


Note You need to log in before you can comment on or make changes to this bug.