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
*** This bug has been marked as a duplicate of bug 1168918 ***
+1 my preference is one BZ per failure scenario, and no yo-yo BZs for additional failure scenarios.
+1 the same opinion as Darran; whenever possible, we prefer having case-by-case BZs than a single BZ covering multiple scenarios
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.
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.
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.
Closed as known issue, see new documentation BZ1174156.
John Doyle <jdoyle> updated the status of jira EAP6-174 to Closed