[jira] [Commented] (ARTEMIS-1386) With enabled kerberos auth, acceptor allows PLAIN auth sasl users in, even when GSSAPI is the only defined sasl mechanism on transport

2017-09-05 Thread Michal Toth (JIRA) 

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16153586#comment-16153586
 ] 

Michal Toth commented on ARTEMIS-1386:
--

Ok, so AMQP client connected to default 61616 accepts plain user, while 
connecting to 5672 uses only kerberos GSSAPI.
5672 (as expected)
{noformat}
java -jar aac-staging-0.24.0.jar sender --broker amqp://hostname:5672  
--address lalaQ --log-msgs interop --conn-username lala --conn-password lala 
--count 1  --log-lib debug
14:48:44,705 DEBUG 
Connection=amqp://hostname:5672?jms.username=lala=lala
14:48:45,430 DEBUG Skipping SASL-GSSAPI mechanism as it must be explicitly 
enabled in the configured sasl mechanisms
14:48:45,430 INFO Best match for SASL auth was: null
14:48:45,431 ERROR Failed to connect to remote at: amqp://hostname:5672
14:48:45,439 DEBUG Shutdown of ExecutorService: 
java.util.concurrent.ScheduledThreadPoolExecutor@6ee52dcd[Terminated, pool size 
= 0, active threads = 0, queued tasks = 0, completed tasks = 3] is shutdown: 
true and terminated: true took: 0.001 seconds.
14:48:45,441 ERROR Could not find a suitable SASL mechanism for the remote peer 
using the available credentials.
javax.jms.JMSSecurityException: Could not find a suitable SASL mechanism for 
the remote peer using the available credentials.
at 
org.apache.qpid.jms.provider.amqp.AmqpSaslAuthenticator.recordFailure(AmqpSaslAuthenticator.java:154)
at 
org.apache.qpid.jms.provider.amqp.AmqpSaslAuthenticator.handleSaslInit(AmqpSaslAuthenticator.java:108)
at 
org.apache.qpid.jms.provider.amqp.AmqpSaslAuthenticator.tryAuthenticate(AmqpSaslAuthenticator.java:61)
at 
org.apache.qpid.jms.provider.amqp.AmqpProvider.processSaslAuthentication(AmqpProvider.java:954)
at 
org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdates(AmqpProvider.java:938)
at 
org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1800(AmqpProvider.java:101)
at 
org.apache.qpid.jms.provider.amqp.AmqpProvider$17.run(AmqpProvider.java:789)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

{noformat}

While connecting to 61616 lets AMQP SASL plain user in (for AMQP connection)
{noformat}
# java -jar aac-staging-0.24.0.jar sender --broker 
amqp://dhcp-145-62.lab.eng.brq.redhat.com:61616  --address lalaQ --log-msgs 
interop --conn-username lala --conn-password lala --count 1  --log-lib debug
14:51:21,094 DEBUG 
Connection=amqp://dhcp-145-62.lab.eng.brq.redhat.com:61616?jms.username=lala=lala
14:51:21,829 INFO Best match for SASL auth was: SASL-PLAIN
[1662383289:0] -> Open{ 
containerId='ID:9e62a8f8-be25-46b3-99c8-7e6182bbec92:1', 
hostname='dhcp-145-62.lab.eng.brq.redhat.com', maxFrameSize=1048576, 
channelMax=32767, idleTimeOut=3, outgoingLocales=null, 
incomingLocales=null, offeredCapabilities=null, 
desiredCapabilities=[sole-connection-for-container], 
properties={product=QpidJMS, version=0.24.0, platform=JVM: 1.8.0_65, 25.65-b01, 
Oracle Corporation, OS: Linux, 3.10.0-229.49.1.el7.x86_64, amd64}}
[1662383289:0] <- Open{ containerId='0.0.0.0', hostname='null', 
maxFrameSize=4294967295, channelMax=65535, idleTimeOut=3, 
outgoingLocales=null, incomingLocales=null, 
offeredCapabilities=[sole-connection-for-container, DELAYED_DELIVERY, 
SHARED-SUBS, ANONYMOUS-RELAY], desiredCapabilities=null, 
properties={product=apache-activemq-artemis, version=2.3.0-SNAPSHOT}}
[1662383289:0] -> Begin{remoteChannel=null, nextOutgoingId=1, 
incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535, 
offeredCapabilities=null, desiredCapabilities=null, properties=null}
[1662383289:0] <- Begin{remoteChannel=0, nextOutgoingId=1, 
incomingWindow=2147483647, outgoingWindow=2147483647, handleMax=65535, 
offeredCapabilities=null, desiredCapabilities=null, properties=null}
14:51:21,878 DEBUG AmqpConnection { ID:3268ee2a-cf27-405a-9760-13e226b7fcbb:1 } 
is now open: 
14:51:21,878 INFO Connection ID:3268ee2a-cf27-405a-9760-13e226b7fcbb:1 
connected to remote Broker: amqp://dhcp-145-62.lab.eng.brq.redhat.com:61616
[1662383289:1] -> Begin{remoteChannel=null, nextOutgoingId=1, 
incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535, 
offeredCapabilities=null, desiredCapabilities=null, properties=null}
[1662383289:1] <- Begin{remoteChannel=1, nextOutgoingId=1, 
incomingWindow=2147483647,

[jira] [Commented] (ARTEMIS-1386) With enabled kerberos auth, acceptor allows PLAIN auth sasl users in, even when GSSAPI is the only defined sasl mechanism on transport

2017-09-05 Thread Gary Tully (JIRA) 

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16153579#comment-16153579
 ] 

Gary Tully commented on ARTEMIS-1386:
-

I think there must be some other amqp acceptor in the mix that supports 
sasl-plain. The one on port 5672 will only advertise Gssapi

> With enabled kerberos auth, acceptor allows PLAIN auth sasl users in, even 
> when GSSAPI is the only defined sasl mechanism on transport
> --
>
> Key: ARTEMIS-1386
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1386
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP, Broker
>Affects Versions: 2.4.0
> Environment: Artemis built from sources
> last git commit 098d69b63c81d9b2aa2c58c30d921d30472e57f8 (Sept 1)
>Reporter: Michal Toth
>
> Enable all AMQP authentication & authorization to be performed by GSSAPI 
> (kerberos), so user can send and receive messages w/o problems using kerberos 
> credentials.
> Define broker amqp acceptor to accept only GSSAPI auth mechanism.
> {noformat}
>  name="amqp">tcp://0.0.0.0:5672?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=AMQP;useEpoll=true;amqpCredits=1000;amqpMinCredits=300;saslMechanisms=GSSAPI;saslLoginConfigScope=mykerberos
> {noformat}
> Users authentication over PLAIN sasl mechanism should not be allowed it. Only 
> Kerberized ones. This is not working actually.
> I am able to send/receive a message using plain over AMQP, with such defined 
> saslMechanisms as above. 
> login.config
> {noformat}
> activemq {
>  org.apache.activemq.artemis.spi.core.security.jaas.Krb5LoginModule optional
>debug=true;
>  org.apache.activemq.artemis.spi.core.security.jaas.PropertiesLoginModule 
> sufficient
>debug=true
>reload=true
>org.apache.activemq.jaas.properties.user="artemis-users.properties"
>org.apache.activemq.jaas.properties.role="artemis-roles.properties";
> };
> mykerberos {
> com.sun.security.auth.module.Krb5LoginModule required
> isInitiator=false
> storeKey=true
> useKeyTab=true
> keyTab="/opt/amqp-service.keytab"
> principal="amqp/hostn...@my.realm.com"
> debug=true;
> };
> {noformat}
> {noformat}
> users properties
> admin = 
> ENC(1024:31461C31F100DA2D4363030BD70AB79BD1693552737AB4951B9B733770B60F40:B97C0DE92D4C0A17C2FE572E206A8F8806EFDFEBA456ED96AC1570E12E3F1BEC8314FA9744AC7EFD95DA939FACA2EA829CF3F46C96268F6B9140C74A2E1EE4D3)
> lala = lala
> ---
> roles.properties
> amq = admin,al...@mqe.redhat.com,lala
> readers = b...@mqe.redhat.com
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)