Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1168921 - Kerberos authentication for Management CLI does not work with IBM JDK
Kerberos authentication for Management CLI does not work with IBM JDK
Status: CLOSED CANTFIX
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Domain Management (Show other bugs)
6.4.0
Unspecified Unspecified
unspecified Severity urgent
: DR13
: EAP 6.4.0
Assigned To: Darran Lofthouse
Ondrej Lukas
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2014-11-28 07:29 EST by Ondrej Lukas
Modified: 2015-04-28 11:05 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Known Issue
Doc Text:
Cause: ?? Consequence: Workaround (if any): Result:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-12-15 05:45:41 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
krb_debug (4.75 KB, text/plain)
2014-11-28 07:29 EST, Ondrej Lukas
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker EAP6-174 Major Closed Kerberos based authentication for Remoting 2017-11-08 15:30 EST
JBoss Issue Tracker WFCORE-448 Major Resolved CLI unable to load JAAS configuration on IBM JDK due to ClassNotFoundException 2017-11-08 15:30 EST

  None (edit)
Description Ondrej Lukas 2014-11-28 07:29:45 EST
Created attachment 962455 [details]
krb_debug

In case when kerberos authentication is correctly configured in security realm [1] and Management CLI which runs with IBM JDK tries to connected then following exception is thrown:

org.jboss.as.cli.CliInitializationException: Failed to connect to the controller
	at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:299)
	at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:277)
	at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:88)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
	at java.lang.reflect.Method.invoke(Method.java:613)
	at org.jboss.modules.Module.run(Module.java:312)
	at org.jboss.modules.Main.main(Main.java:473)
Caused by: org.jboss.as.cli.CommandLineException: The controller is not available at localhost:9999
	at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:1024)
	at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:854)
	at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:830)
	at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:297)
	... 8 more
Caused by: java.io.IOException: java.net.ConnectException: JBAS012144: Could not connect to remote://localhost:9999. The connection timed out
	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:149)
	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:75)
	at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:1002)
	... 11 more
Caused by: java.net.ConnectException: JBAS012144: Could not connect to remote://localhost:9999. The connection timed out
	at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:135)
	at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:256)
	at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
	at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:208)
	at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:167)
	at org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:127)
	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:123)
	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:98)
	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263)
	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168)
	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147)
	... 13 more

Adding kerberos debug output in krb_debug.txt. In case this is only documentation issue caused by any difference from [1], please add comment to documentation bz [3] with description how to correctly set this feature with IBM JDK.

How to reproduce:
1) configure kerberos authentication for Management Realm with wrong configured principal
2) start Kerberos server and EAP, try to authenticate into Management CLI with JDK 1.7 - works fine
3) disconnect from Management CLI
4) try to authenticate into Management CLI with IBM JDK - mentioned above exception is thrown

I request blocker flag since this issue is blocking certification [2] for IBM JDK. 

[1] http://darranl.blogspot.cz/2014/11/wildfly-9-kerberos-authentication-with.html
[2] https://mojo.redhat.com/docs/DOC-48621
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1140458
Comment 1 baranowb 2014-12-01 00:58:12 EST

*** This bug has been marked as a duplicate of bug 1168918 ***
Comment 3 Darran Lofthouse 2014-12-01 06:45:31 EST
+1 my preference is one BZ per failure scenario, and no yo-yo BZs for additional failure scenarios.
Comment 4 Hynek Mlnarik 2014-12-02 02:14:04 EST
+1 the same opinion as Darran; whenever possible, we prefer having case-by-case BZs than a single BZ covering multiple scenarios
Comment 5 baranowb 2014-12-02 04:08:16 EST
Ok, it is better this way. I was just browsing through leftovers that need to be covered and BZ did not show full title so I saw two BZs with the same summary and close BZ numbers - looked like duplicate at first.
Comment 6 Darran Lofthouse 2014-12-03 08:34:38 EST
I am going to work through this one further but I think realistically this one is going to end up with workarounds required when using IBM, if you look at the final two lines in the log: -

[KRB_DBG_CCHE] FileCredentialsCache:Remoting "cli-client" read-1:   >>>KinitOptions cache name is /home/olukas/krb5cc_olukas
[KRB_DBG_CCHE] FileCredentialsCache:Remoting "cli-client" read-1:   >>> FileCredentialsCache default name is: /home/olukas/krb5cc_olukas

The real issue here is that the login module is not up to date on default cache locations and is still referencing the old locations which is why it can not find it.

What I believe may be required is a custom JAAS configuration containing configuration for 'com.ibm.security.jgss.initiate' - this will need to contain a Krb5LoginModule definition that points to the correct cache.  On starting the CLI a system property will need to be set pointing to this custom config.
Comment 7 Darran Lofthouse 2014-12-04 14:04:33 EST
Clearing the milestone for the moment as this one is now looking unrealistic.

The original problem from the debug log seemed to be that the IBM implementation was not using the updated locations for the credentials cache, I now have a small change so a custom JAAS configuration can be provided by the end user when using the IBM JVM but whatever options I use I can not get the IBM JVM to make use of the credentials cache without one error or another error.

I am almost at the point of saying the IBM JVM is not compatible with the current credentials cache format which will fundamentally make solving this impossible.

If there is a working JAAS configuration for the IBM JVM that uses the Krb5LoginModule to populate a Subject using the local cache it would be much appreciated.
Comment 10 Ondrej Kotek 2014-12-15 05:45:41 EST
Closed as known issue, see new documentation BZ1174156.
Comment 14 JBoss JIRA Server 2015-04-28 11:05:34 EDT
John Doyle <jdoyle@jboss.org> updated the status of jira EAP6-174 to Closed

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