[
https://issues.apache.org/jira/browse/QPIDJMS-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15848240#comment-15848240
]
Rob Godfrey commented on QPIDJMS-261:
-------------------------------------
The only "difference" (other than the change in version numbers of the client)
I see is that the 0.11 client sent the AMQP Protocol Header and the open in the
same TCP packet, whereas in 0.20 the open is sent in a separate packet. This
should not make any difference to the broker, so if this the cause then the
broker is at fault by making assumptions about how AMQP frames will be mapped
to TCP packets
> Not possible to connect to IBM's IIB AMQP broker
> ------------------------------------------------
>
> Key: QPIDJMS-261
> URL: https://issues.apache.org/jira/browse/QPIDJMS-261
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
> Affects Versions: 0.20.0
> Environment: Java 1.8
> Reporter: Tin Nguyen
> Attachments: qpid.0.11.1.log, qpid.0.11.1.pcapng, qpid.0.20.0.log,
> qpid.0.20.0.pcapng
>
>
> With the latest 0.20 version I'm not able to connect to IBM's Integration Bus
> running AMQP implementation (afaik it's just a rip off from qpid).
> Seems like something changed with the way qpid-jms handles SASL
> authentication? It's working in 0.11.1 so I tried to look into the changes
> but there were quite a few.
> I don't have access to the IBM server but the admin told me that my client
> didn't get authenticated.
> log output from the qpid client:
> 2348 [AmqpProvider:(1):[amqp://SERVER:5672/TOPIC]] INFO
> o.a.q.j.s.SaslMechanismFinder - Best match for SASL auth was: SASL-PLAIN
> 8120 [AmqpProvider:(1):[amqp://SERVER:5672/TOPIC]] WARN
> o.a.q.j.p.a.b.AmqpResourceBuilder - Open of resource:(JmsConnectionInfo {
> ID:9088d3b3-0cba-4fb4-bb87-207872077309:1, configuredURI =
> amqp://SERVER:5672/TOPIC, connectedURI = null }) failed: AMQXR0041E: A
> connection was not authorized for channel SYSTEM.DEF.AMQP received from
> 10.2.190.60. MQRC 2035 MQRC_NOT_AUTHORIZED [condition =
> amqp:unauthorized-access]
> 8121 [AmqpProvider:(1):[amqp://SERVER:5672/TOPIC]] INFO
> o.a.q.j.p.a.AmqpProvider - Transport failed: An existing connection was
> forcibly closed by the remote host
> Caught exception, exiting.
> javax.jms.JMSSecurityException: AMQXR0041E: A connection was not authorized
> for channel SYSTEM.DEF.AMQP received from 10.2.10.60. MQRC 2035
> MQRC_NOT_AUTHORIZED [condition = amqp:unauthorized-access]
> LOGS on IBM server
> 01/17/2017 01:40:21 PM - Process(51975.7) User(mqm) Program(java)
> Host(SERVER) Installation(Installation1)
> VRMF(9.0.0.0) QMgr(UUFNLB1E)
>
> AMQ5534: User ID 'hadoop' authentication failed
> EXPLANATION:
> The user ID and password supplied by the 'AMQP' program could not be
> authenticated.
> Additional information: 'N/A'.
> ACTION:
> Ensure that the correct user ID and password are provided by the application.
> Ensure that the authentication repository is correctly configured. Look at
> previous error messages for any additional information.
> ----- amqzfuca.c : 4486
> -------------------------------------------------------
> 01/17/2017 01:40:21 PM - Process(51975.7) User(mqm) Program(java)
> Host(SERVER) Installation(Installation1)
> VRMF(9.0.0.0) QMgr(UUFNLB1E)
>
> AMQ5542: The failed authentication check was caused by the queue manager
> CONNAUTH CHCKCLNT(REQDADM) configuration.
> EXPLANATION:
> The user ID 'hadoop' and its password were checked because the queue manager
> connection authority (CONNAUTH) configuration refers to an authentication
> information (AUTHINFO) object named 'SYSTEM.DEFAULT.AUTHINFO.IDPWOS' with
> CHCKCLNT(REQDADM).
> This message accompanies a previous error to clarify the reason for the user
> ID
> and password check.
> ACTION:
> Refer to the previous error for more information.
> Ensure that a password is specified by the client application and that the
> password is correct for the user ID. The authentication configuration of the
> queue manager connection determines the user ID repository. For example, the
> local operating system user database or an LDAP server.
> If the CHCKCLNT setting is OPTIONAL, the authentication check can be avoided
> by
> not passing a user ID across the channel. For example, by omitting the MQCSP
> structure from the client MQCONNX API call.
> To avoid the authentication check, you can amend the authentication
> configuration of the queue manager connection, but you should generally not
> allow unauthenticated remote access.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
