Bug 1254532 - (TEIID-3643) VDB based kerberos authentication does not work with ODBC
VDB based kerberos authentication does not work with ODBC
Status: CLOSED CURRENTRELEASE
Product: JBoss Data Virtualization 6
Classification: JBoss
Component: Teiid (Show other bugs)
6.2.0
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: jolee
Juraj Duráni
: QA-Closed, Reopened
Depends On:
Blocks: 1242071
  Show dependency treegraph
 
Reported: 2015-08-18 06:32 EDT by Juraj Duráni
Modified: 2016-06-17 08:40 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-02-10 03:56:08 EST
Type: Support Patch
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker TEIID-3643 Major Closed VDB based kerberos authentication does not work with ODBC 2017-03-22 10:53 EDT

  None (edit)
Description Juraj Duráni 2015-08-18 06:32:45 EDT
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@EXAMPLE.COM"/>
            <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@EXAMPLE.COM" 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@EXAMPLE.COM"
 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@EXAMPLE.COM");
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@EXAMPLE.COM
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 08:40:02 EDT
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 09:50:10 EDT
Reopened by the project.
Comment 3 jolee 2015-09-30 09:45:04 EDT
git@github.com:jboss-integration/teiid.git : 8.7.x-prod-ipv6.2 : cc7270c

git@github.com:teiid/teiid.git : 62-8.7.x : cc7270c
Comment 5 Juraj Duráni 2015-10-21 07:24:07 EDT
Verified.
Comment 7 JBoss JIRA Server 2016-06-17 08:40:27 EDT
Steven Hawkins <shawkins@redhat.com> 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.