]
Darran Lofthouse commented on WFLY-1592:
----------------------------------------
This issue is due to changes introduced in REM3-29 where the default protocol was switched
from 'remote' to 'remoting'.
Reverting that change would not be appropriate as it is needed to be able to enable GSSAPI
support.
The change for REM3-29 does allow the protocol name to be specified in configuration
however doing that would require the same config on the server and in all clients - it
would also only be a short term fix until we enable support for GSSAP.
SASL-42 will instead allow the server side to specify a list of accepted alternative
protocols, when GSSAPI is in use it will be essential for clients using it to use the
correct protocol but older clients may still want to connect with username / password
auth.
Attempting to use eap6.1 jboss-cli.sh to connect to remote wildfly
(alpha1 or 2) fails; credentials not accepted
----------------------------------------------------------------------------------------------------------------
Key: WFLY-1592
URL:
https://issues.jboss.org/browse/WFLY-1592
Project: WildFly
Issue Type: Bug
Components: Remoting, Security
Affects Versions: 8.0.0.Alpha2
Reporter: Rob Stryker
Assignee: Darran Lofthouse
Fix For: 8.0.0.CR1
Using eap6.1 client jars, or the jboss-cli.sh script in a local eap6.1 installation, to
connect to a remote wildfly alpha1 or alpha2, seems to work but fails when provided with
credentials. This is most easily replicated as follows:
1) On remote machine start wildfly alpha1 or alpha2
2) on local machine, cd eap-6.1/bin
3) on local machine:
[rob@rawbdor bin]$ ./jboss-cli.sh
You are disconnected at the moment. Type 'connect' to connect to the server or
'help' for the list of supported commands.
[disconnected /] connect
myhost.net
Authenticating against security realm: ManagementRealm
Username: admin
Password:
Unable to authenticate against controller at myhost.net:9999: Authentication failed: all
available authentication mechanisms failed
This is an issue for tools as we need a set of jars that communicates correctly with all
as7 servers. We currently have a set of jars that communicates with all 7.x / eap 6.x,
which is good. If this is merely a bug on the server, then we can hopefully delay having
to bundle an additional set of client jars until larger breakages occur.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: