I have Keycloak 17.0.0 (Quarkus) running in Kubernetes. When I start the Keycloak server with HTTP (http-enabled:true; hostname-strict-https:false), I can successfully log in to the administration console from both the Windows 10 and Fedora 35 systems (tried from two computers with Windows and three with Linux). I tried both Chrome and Firefox, and the behaviour is the same.
But when I start the Keycloak server with HTTPS (certificate generated using keytool, no root certificate), then I can log in from the Fedora systems, but can't from the Windows systems.
I'm not sure if this matters, but from both the Windows and Fedora systems, I'm connecting to the Keycloak server through a corporate VPN.
When trying to log in from the Windows machines, the server returns status code 400 - this is the request URL:
https://<ip>:<port>/realms/master/login-actions/authenticate?session_code=fUdxAl_f-vYHQFGUCX07SQnWEnncBCPf8hi3t3pmmHs&execution=05d68330-cbf2-4b28-9d04-2365989934d1&client_id=security-admin-console&tab_id=eK7ABwblVp8
In Keycloak logs, I see this exception (truncated where the three dots are for brevity):
2022-03-23 14:45:41,653 WARN [org.keycloak.services] (executor-thread-6) KC-SERVICES0013: Failed authentication: java.lang.RuntimeException: java.io.IOException: Underlying input stream returned zero bytes
at org.jboss.resteasy.plugins.server.BaseHttpRequest.getFormParameters(BaseHttpRequest.java:61)
at org.jboss.resteasy.plugins.server.BaseHttpRequest.getDecodedFormParameters(BaseHttpRequest.java:74)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.jboss.resteasy.core.ContextParameterInjector$GenericDelegatingProxy.invoke(ContextParameterInjector.java:166)
at com.sun.proxy.$Proxy46.getDecodedFormParameters(Unknown Source)
at org.keycloak.authentication.DefaultAuthenticationFlow.processAction(DefaultAuthenticationFlow.java:104)
at org.keycloak.authentication.AuthenticationProcessor.authenticationAction(AuthenticationProcessor.java:1002)
at org.keycloak.services.resources.LoginActionsService.processFlow(LoginActionsService.java:321)
at org.keycloak.services.resources.LoginActionsService.processAuthentication(LoginActionsService.java:292)
at org.keycloak.services.resources.LoginActionsService.authenticate(LoginActionsService.java:276)
at org.keycloak.services.resources.LoginActionsService.authenticateForm(LoginActionsService.java:349)
...
Caused by: java.io.IOException: Underlying input stream returned zero bytes
at java.base/sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:288)
at java.base/sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
at java.base/sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
at java.base/java.io.InputStreamReader.read(InputStreamReader.java:181)
at java.base/java.io.BufferedReader.fill(BufferedReader.java:161)
at java.base/java.io.BufferedReader.read1(BufferedReader.java:212)
at java.base/java.io.BufferedReader.read(BufferedReader.java:287)
at org.jboss.resteasy.plugins.providers.FormUrlEncodedProvider.parseForm(FormUrlEncodedProvider.java:88)
at org.jboss.resteasy.plugins.server.BaseHttpRequest.getFormParameters(BaseHttpRequest.java:57)
I compared the two outgoing authentication requests (from Windows and from Fedora) in Chrome's Network tab, and they looked almost identical: small difference in accepted-language header - but only the lowest priority one, (expected) differences in session cookies.
Related
I am trying to connect two machines both running JBoss EAP 7.1.0 using a JMS bridge. Machine 1 is to act as a web server and has a WAR file deployed which is accessible, and Machine 2 is to act as the app server and has all the necessary components deployed just fine.
This is the error I am receiving:
WARN [org.apache.activemq.artemis.jms.bridge] (ServerService Thread Pool -- 72) AMQ342010: Failed to connect JMS Bridge N/A: javax.naming.CommunicationException: WFNAM00018: Failed to connect to remote host [Root exception is javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed:
JBOSS-LOCAL-USER: javax.security.sasl.SaslException: ELY05128: [JBOSS-LOCAL-USER] Failed to read challenge file [Caused by java.io.FileNotFoundException: /.../.../jboss/standalone/tmp/auth/local3093626581916142639.challenge (No such file or directory)]]
at org.wildfly.naming.client.remote.RemoteNamingProvider.getPeerIdentityForNaming(RemoteNamingProvider.java:110)
at org.wildfly.naming.client.remote.RemoteNamingProvider.getPeerIdentityForNaming(RemoteNamingProvider.java:53)
at org.wildfly.naming.client.NamingProvider.getPeerIdentityForNamingUsingRetry(NamingProvider.java:105)
at org.wildfly.naming.client.remote.RemoteNamingProvider.getPeerIdentityForNamingUsingRetry(RemoteNamingProvider.java:91)
at org.wildfly.naming.client.remote.RemoteContext.lambda$lookupNative$0(RemoteContext.java:189)
at org.wildfly.naming.client.NamingProvider.performExceptionAction(NamingProvider.java:222)
at org.wildfly.naming.client.remote.RemoteContext.performWithRetry(RemoteContext.java:100)
at org.wildfly.naming.client.remote.RemoteContext.lookupNative(RemoteContext.java:188)
at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:74)
at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:60)
at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:144)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at org.apache.activemq.artemis.jms.bridge.impl.JNDIFactorySupport.createObject(JNDIFactorySupport.java:46)
at org.apache.activemq.artemis.jms.bridge.impl.JNDIDestinationFactory.createDestination(JNDIDestinationFactory.java:32)
at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.setupJMSObjects(JMSBridgeImpl.java:1072)
at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.start(JMSBridgeImpl.java:398)
at org.wildfly.extension.messaging.activemq.jms.bridge.JMSBridgeService.startBridge(JMSBridgeService.java:114)
at org.wildfly.extension.messaging.activemq.jms.bridge.JMSBridgeService$1.run(JMSBridgeService.java:84)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
The connection to the target machine (application server) is being made as the path to JBoss is that of the path on the machine, which I verified by testing with a Windows application server environment and the path was the correct Windows path to the directory where the challenge file should be, so clearly the connection is being made as the directories are being accessed. However, the .challenge file isn't present each time which understandably causes the error message.
I have scoured SO and JBoss forums for days now and nothing is resolving my issue.
I saw this post: JBOSS-LOCAL-USER: javax.security.sasl.SaslException: Failed to read server challenge
This is the same issue that I am facing, but the answer which was marked as correct doesn't help me very much. The solution, in this case, was to replace the default ApplicationRealm with a JAAS realm, but I do not know if this is what I need, and I certainly do not currently have one. I did research it, but it seemed to not be applicable to my setup, but I could be wrong.
I also tried this solution: https://access.redhat.com/solutions/3209281 (Subscription only access)
This solution was to remove default-user="$local" from here:
<security-realm name="ApplicationRealm">
<authentication>
<local default-user="$local" allowed-users="*" skip-group-loading="true"/>
I did this to both standalone-full.xml files on both machines, and it appeared to make no difference at all.
I have created application users on both machines and given them superuser privileges through the JBoss console as I figured it was probably an issue with permissions when trying to write the file but this too was to no avail. I have also verified that both user credentials are correct.
The workaround was to switch to using a core bridge instead of a JMS bridge, as per the recommendation from Justin in the comments.
I am unable to get MyEclipse to connect to the marketplace. I am aware of the proxy setup. These are the steps I followed within a proxy environment and within a direct environment.
A. Within the Company Network. (browers use automatic configuration script)
Chose Native option. Does not work.
Chose Manual option. Set the domain, username. Opened the proxy script to figure out available proxy servers. Verified independently that these proxy servers work. Does not work.
Modified the vmargs to provide the http host, user, password and port properties. Does not work.
Did steps 1-3 with restarts of Eclipse.
B. Within home environment. (Direct connection to internet)
Tried Direct Option. Does not work.
Tried Native Option. Does not work.
The error message that I constantly see (through error logs) is this.
java.lang.reflect.InvocationTargetException
at org.eclipse.epp.internal.mpc.ui.commands.MarketplaceWizardCommand$3.run(MarketplaceWizardCommand.java:203)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
Caused by: org.eclipse.core.runtime.CoreException: HTTP Server Unknown HTTP Response Code (-1):http://marketplace.eclipse.org/catalogs/api/p
at org.eclipse.equinox.internal.p2.transport.ecf.RepositoryTransport.stream(RepositoryTransport.java:161)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.epp.internal.mpc.core.util.AbstractP2TransportFactory.invokeStream(AbstractP2TransportFactory.java:35)
at org.eclipse.epp.internal.mpc.core.util.TransportFactory$1.stream(TransportFactory.java:69)
at org.eclipse.epp.internal.mpc.core.service.RemoteMarketplaceService.processRequest(RemoteMarketplaceService.java:141)
at org.eclipse.epp.internal.mpc.core.service.RemoteMarketplaceService.processRequest(RemoteMarketplaceService.java:80)
at org.eclipse.epp.internal.mpc.core.service.DefaultCatalogService.listCatalogs(DefaultCatalogService.java:36)
at org.eclipse.epp.internal.mpc.ui.commands.MarketplaceWizardCommand$3.run(MarketplaceWizardCommand.java:200)
... 1 more
Caused by: org.eclipse.ecf.filetransfer.BrowseFileTransferException: Could not connect to http://marketplace.eclipse.org/catalogs/api/p
at com.genuitec.pulse2.common.http.ecf.PulseRetrieveFileTransfer.openStreams(Unknown Source)
at org.eclipse.ecf.provider.filetransfer.retrieve.AbstractRetrieveFileTransfer.sendRetrieveRequest(AbstractRetrieveFileTransfer.java:889)
at org.eclipse.ecf.provider.filetransfer.retrieve.AbstractRetrieveFileTransfer.sendRetrieveRequest(AbstractRetrieveFileTransfer.java:576)
at org.eclipse.ecf.provider.filetransfer.retrieve.MultiProtocolRetrieveAdapter.sendRetrieveRequest(MultiProtocolRetrieveAdapter.java:106)
at org.eclipse.equinox.internal.p2.transport.ecf.FileReader.sendRetrieveRequest(FileReader.java:349)
at org.eclipse.equinox.internal.p2.transport.ecf.FileReader.read(FileReader.java:213)
at org.eclipse.equinox.internal.p2.transport.ecf.RepositoryTransport.stream(RepositoryTransport.java:153)
... 11 more
Is there any alternative or any other step that I can take to resolve this problem. I know I can go through the manual update by downloading the plugin and all. But I really want to solve this issue.
MyEclipse Version Information:
MyEclipse Blue Edition
Version: 10.7.1 Blue
Build id: 10.7.1-Blue-20130201
Apparently it could be a bug.
I just read this whole bug report here.
I tried adding the VM arguments to ensure the the HTTPClient workaround can be achieved via a configuration change. Did not work.
However, I was able to remove the http client libraries from the plugins folder, courtesy Comment #27 and #29 on the bug report.
Now I'm able to connect over proxy and direct as well.
We use kerberos authentication to perform SSO. Earlier our product was on JRE 6 Update 22 and everything used to work fine. We recently migrated to JRE 6 update 45, and the kerberos authentication fails.
So, basically the code performs 2 steps - the connect and login
1. The "connect" step tests if the SPN name and credentials (either password or keytab) can login to the domain controller identified by the realm and KDC info.
2. The "login" step does the same, and then also tries to bind to the AD LDAP service using the GSSAPI authentication mechanism. So, it is attempting to perform a GSSAPI bind and at this step it is failing now.
So, here's what is happening -
Server(our product) sends AS-REQ to KDC
KDC responds back with error_code: KRB5KDC_ERR_PREAUTH_REQUIRED (25)
Server again sends AS-REQ to KDC with the timestamp
KDC responds back ( AS-REP) with TGT
MCIM sends the TGS-REQ – From our analysis, this is the problem area, this request is populated with incorrect details as explained below.
KDC responds back with error_code: KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN (7)
Now, the problem here is when the server is sending the TGS-REQ, it sends with Server Name (Unknown): ldap/10.213.177.3 whereas in the older JRE version it used to send the TGS-REQ as ldap/win2008.mcssoiwa.hari(hostname of kdc) even when the KDC IP is given.
Now, KDC does not have an SPN registered with ldap and IP whereas it has a SPN registered with Ldap/Hostname of the KDC
If we explicitly perform a setspn command for ldap/, everything starts working. So, what has changed in later versions of JRE 6 which is causing this issue. This is really a blocker for us and we are not aware how this can be resolved. Any help/guidance would be appreciated.
The code which is doing this -
LDAPConnection connection = new LDAPConnection(request.getServer(), request.getPort());
GSSAPIBindRequest bindRequest = new GSSAPIBindRequest(request.getAuthnId(), null, "N/A", null, null, "");
connection.bind(bindRequest); //throws exception
This throws the following exception
*
Caused by: com.unboundid.ldap.sdk.LDAPException: Unable to create the initial GSSAPI SASL request: javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Server not found in Kerberos database (7))] caused by GSSException: No valid credentials provided (Mechanism level: Server not found in Kerberos database (7)) caused by KrbException: Server not found in Kerberos database (7) caused by KrbException: Identifier doesn't match expected value (906)
at com.unboundid.ldap.sdk.SASLHelper.processSASLBind(SASLHelper.java:120)
at com.unboundid.ldap.sdk.GSSAPIBindRequest.run(GSSAPIBindRequest.java:1022)
... 56 common frames omitted
Caused by: javax.security.sasl.SaslException: GSS initiate failed
at com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(Unknown Source)
at com.unboundid.ldap.sdk.SASLHelper.processSASLBind(SASLHelper.java:114)
... 57 common frames omitted
Caused by: org.ietf.jgss.GSSException: No valid credentials provided (Mechanism level: Server not found in Kerberos database (7))
at sun.security.jgss.krb5.Krb5Context.initSecContext(Unknown Source)
at sun.security.jgss.GSSContextImpl.initSecContext(Unknown Source)
at sun.security.jgss.GSSContextImpl.initSecContext(Unknown Source)
... 59 common frames omitted
Caused by: sun.security.krb5.KrbException: Server not found in Kerberos database (7)
at sun.security.krb5.KrbTgsRep.<init>(Unknown Source)
at sun.security.krb5.KrbTgsReq.getReply(Unknown Source)
at sun.security.krb5.internal.CredentialsUtil.serviceCreds(Unknown Source)
at sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(Unknown Source)
at sun.security.krb5.Credentials.acquireServiceCreds(Unknown Source)
... 62 common frames omitted
Caused by: sun.security.krb5.Asn1Exception: Identifier doesn't match expected value (906)
at sun.security.krb5.internal.KDCRep.init(Unknown Source)
at sun.security.krb5.internal.TGSRep.init(Unknown Source)
at sun.security.krb5.internal.TGSRep.<init>(Unknown Source)*
Two things: briefly skimming over changes in JDK6 shows there are some mentions of LDAP between 22 and 45. I can't detect anything related immediately - maybe you have to scrutinize all changes in detail.
Release notes of UnboundID Solutions's LDAP SDK for Java could also give some indication. Maybe you need to upgrade the SDK to make up for a change in the JDK.
I'm having trouble making a remote JMX call to JBoss 6 on a Centos 5.6 server. I've previously been able to do this when running the same app on a Debian server.
./twiddle.sh --server=service:jmx:rmi:///jndi/rmi://SERVER:1090/jmxconnector invoke foo:service=bar baz
Caused by: java.net.NoRouteToHostException: No route to host
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)
at java.net.Socket.connect(Socket.java:478)
at java.net.Socket.<init>(Socket.java:375)
at java.net.Socket.<init>(Socket.java:189)
at sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:22)
at sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:128)
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:595)
The same call succeeds if I run it locally on SERVER. I've opened port 1090 with iptables, and I can connect via telnet to SERVER:1090. hostname -i returns the correct IP address.
I've also tried starting JBoss with -Djava.rmi.server.hostname=localhost. If I do this, then I get a different exception:
Caused by: java.rmi.NoSuchObjectException: no such object in table
at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:255)
at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:233)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:142)
at javax.management.remote.rmi.RMIServerImpl_Stub.newClient(Unknown Source)
at javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java:2327)
at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:279)
at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:248)
at org.jboss.console.twiddle.Twiddle.createMBeanServerConnection(Twiddle.java:322)
at org.jboss.console.twiddle.Twiddle.connect(Twiddle.java:331)
at org.jboss.console.twiddle.Twiddle.access$400(Twiddle.java:60)
at org.jboss.console.twiddle.Twiddle$1.getServer(Twiddle.java:217)
It turns out that in addition to port 1090, JMX/RMI also uses a dynamically allocated port, which gets blocked by the firewall. So, if it's appropriate, disable the firewall altogether, or else this seems to be an alternative (which I've not tried yet):
http://olegz.wordpress.com/2009/03/23/jmx-connectivity-through-the-firewall/
What I did was this:
Update the file activemq.xml and specify rmiServerPort.
<managementContext createConnector="true" connectorPort="SOME_PORT" rmiServerPort="SOME_OTHER" jmxDomainName="org.apache.activemq"/>
Allow both ports by updating your iptables entry, restart activemq and it should work.
I have a remote GlassFish server that has a node agent configured. The instance I want to start in profiling mode is controlled by the node agent.
I've installed and calibrated the remote pack and I've modified my domain.xml for the specific instance as follows:
<profiler enabled="true" name="NetBeansProfiler">
<jvm-options>-agentpath:/home/glassfish/glassfish/profiler-server-6.0rc1-linux/lib/deployed/jdk16/linux/libprofilerinterface.so=/home/glassfish/glassfish/profiler-server-6.0rc1-linux/lib,5140</jvm-options>
</profiler>
Now at this point NetBeans tells you to start the domain with the --verbose command but in my case I'm trying to start an instance and "asadmin start-instance" doesn't support --verbose. I've checked the server.log but I'm not seeing any error nor any language that says it's waiting when I try to start the instances.
However, I think GlassFish is properly configured and my NetBeans setup is the issue. Where I think the issue might be is trying to specify the port. If I leave the port off, it just tries to connect forever. If I put the port on it just closes the dialog and the status shows "Inactive".
UPDATE:
It seems there might be a bug with GF2. After verifying everything and getting the server so that it was listening, the following exception is thrown
Could not load Logmanager "com.sun.enterprise.server.logging.ServerLogManager"
java.lang.ClassNotFoundException: com.sun.enterprise.server.logging.ServerLogManager
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.util.logging.LogManager$1.run(LogManager.java:166)
at java.security.AccessController.doPrivileged(Native Method)
at java.util.logging.LogManager.(LogManager.java:156)
According to this URL, http://java.net/jira/browse/GLASSFISH-3256 it's a known issue and won't be fixed until GF3.
Anyway, my question was about how to connect to a specific instance and I think that was answered.
Do not include the port number in the hostname field. The port number is taken from the global profiler settings.