You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Michiel Lange <ml...@anwb.nl> on 2018/04/06 13:22:59 UTC
Qpid Dispatch authenticate through ldap, is this possible
Hi,
I use Qpid Dispatch to route JMS to an Artemis broker, which I have configured to use LDAP; allowing certain groups to create queues, send messages or receive.
I am strugging getting Qpid dispatch to even use authentication, leave alone if the authentication information would be stored in LDAP (rather than a separate sasl database)
At the moment I am running qpid-dispatch 1.0.0, running like this (all of these are currently using ANONYMOUS as saslMechanism, which is not really what I was hoping for)
Host 1: contains only listeners
Host 2: contains connectors, connecting to Host 1 (inter-router) and the actual brokers (route-container); This one also contains the linkRoutes to the defined brokers based on their prefix.
I cannot really find that much in the documentation on how to setup authorization
________________________________
Disclaimer
E-mail wordt door ANWB niet gebruikt voor het aangaan van externe verplichtingen.
Deze e-mail is uitsluitend bestemd voor geadresseerde(n). Indien deze e-mail onverhoopt niet voor u is bestemd dan verzoeken wij u vriendelijk contact op te nemen met de afzender en daarna het bericht te vernietigen. Deze e-mail mag niet worden doorgestuurd, openbaar gemaakt of verveelvoudigd worden zonder de toestemming van de afzender.
ANWB betracht grote zorgvuldigheid bij het verzenden van e-mails. ANWB kan echter niet garanderen dat deze e-mail juist, volledig, tijdig en virusvrij wordt overgebracht. In een dergelijk geval is ANWB op geen enkele wijze aansprakelijk voor enige schade, direct dan wel indirect, in welke vorm dan ook.
ANWB B.V.
________________________________
Re: Qpid Dispatch authenticate through ldap, is this possible
Posted by Ganesh Murthy <gm...@redhat.com>.
2018-04-06 11:57 GMT-04:00 Michiel Lange <ml...@anwb.nl>:
> I think I would not really mind either way (yet); Since on broker level
> one could/would set some policies, it would be logical to have the
> authorization remain on the broker;
>
Jiust FYI, you could set policies on the router as well -
https://qpid.apache.org/releases/qpid-dispatch-1.0.1/book/book.html#policy
> So, if qpid dispatch is unaware of credentials used (but passes those
> along) might make matters a bit easier.
>
>
>
> -----Oorspronkelijk bericht-----
> Van: Ganesh Murthy
> Verzonden: vrijdag 6 april 2018 17:14
> Aan: users@qpid.apache.org
> Onderwerp: Re: Qpid Dispatch authenticate through ldap, is this possible
>
> 2018-04-06 9:22 GMT-04:00 Michiel Lange:
>
> > Hi,
> >
> > I use Qpid Dispatch to route JMS to an Artemis broker, which I have
> > configured to use LDAP; allowing certain groups to create queues, send
> > messages or receive.
> > I am strugging getting Qpid dispatch to even use authentication, leave
> > alone if the authentication information would be stored in LDAP
> > (rather than a separate sasl database)
> >
> Would you rather have the router (instead of the broker) do the LDAP
> authentication if it worked on the router ?
>
> >
> > At the moment I am running qpid-dispatch 1.0.0, running like this (all
> > of these are currently using ANONYMOUS as saslMechanism, which is not
> > really what I was hoping for)
> >
> > Host 1: contains only listeners
> > Host 2: contains connectors, connecting to Host 1 (inter-router) and
> > the actual brokers (route-container); This one also contains the
> > linkRoutes to the defined brokers based on their prefix.
> >
> > I cannot really find that much in the documentation on how to setup
> > authorization ________________________________
> >
> > Disclaimer
> >
> > E-mail wordt door ANWB niet gebruikt voor het aangaan van externe
> > verplichtingen.
> >
> > Deze e-mail is uitsluitend bestemd voor geadresseerde(n). Indien deze
> > e-mail onverhoopt niet voor u is bestemd dan verzoeken wij u
> > vriendelijk contact op te nemen met de afzender en daarna het bericht te
> vernietigen.
> > Deze e-mail mag niet worden doorgestuurd, openbaar gemaakt of
> > verveelvoudigd worden zonder de toestemming van de afzender.
> >
> > ANWB betracht grote zorgvuldigheid bij het verzenden van e-mails. ANWB
> > kan echter niet garanderen dat deze e-mail juist, volledig, tijdig en
> > virusvrij wordt overgebracht. In een dergelijk geval is ANWB op geen
> > enkele wijze aansprakelijk voor enige schade, direct dan wel indirect,
> > in welke vorm dan ook.
> >
> > ANWB B.V.
> >
> > ________________________________
> >
> ________________________________
>
>
> Disclaimer
>
> E-mail wordt door ANWB niet gebruikt voor het aangaan van externe
> verplichtingen.
>
> Deze e-mail is uitsluitend bestemd voor geadresseerde(n). Indien deze
> e-mail onverhoopt niet voor u is bestemd dan verzoeken wij u vriendelijk
> contact op te nemen met de afzender en daarna het bericht te vernietigen.
> Deze e-mail mag niet worden doorgestuurd, openbaar gemaakt of
> verveelvoudigd worden zonder de toestemming van de afzender.
>
> ANWB betracht grote zorgvuldigheid bij het verzenden van e-mails. ANWB kan
> echter niet garanderen dat deze e-mail juist, volledig, tijdig en virusvrij
> wordt overgebracht. In een dergelijk geval is ANWB op geen enkele wijze
> aansprakelijk voor enige schade, direct dan wel indirect, in welke vorm dan
> ook.
>
> ANWB B.V.
> ________________________________
>
RE: Qpid Dispatch authenticate through ldap, is this possible
Posted by Michiel Lange <ml...@anwb.nl>.
I think I would not really mind either way (yet); Since on broker level one could/would set some policies, it would be logical to have the authorization remain on the broker;
So, if qpid dispatch is unaware of credentials used (but passes those along) might make matters a bit easier.
-----Oorspronkelijk bericht-----
Van: Ganesh Murthy
Verzonden: vrijdag 6 april 2018 17:14
Aan: users@qpid.apache.org
Onderwerp: Re: Qpid Dispatch authenticate through ldap, is this possible
2018-04-06 9:22 GMT-04:00 Michiel Lange:
> Hi,
>
> I use Qpid Dispatch to route JMS to an Artemis broker, which I have
> configured to use LDAP; allowing certain groups to create queues, send
> messages or receive.
> I am strugging getting Qpid dispatch to even use authentication, leave
> alone if the authentication information would be stored in LDAP
> (rather than a separate sasl database)
>
Would you rather have the router (instead of the broker) do the LDAP authentication if it worked on the router ?
>
> At the moment I am running qpid-dispatch 1.0.0, running like this (all
> of these are currently using ANONYMOUS as saslMechanism, which is not
> really what I was hoping for)
>
> Host 1: contains only listeners
> Host 2: contains connectors, connecting to Host 1 (inter-router) and
> the actual brokers (route-container); This one also contains the
> linkRoutes to the defined brokers based on their prefix.
>
> I cannot really find that much in the documentation on how to setup
> authorization ________________________________
>
> Disclaimer
>
> E-mail wordt door ANWB niet gebruikt voor het aangaan van externe
> verplichtingen.
>
> Deze e-mail is uitsluitend bestemd voor geadresseerde(n). Indien deze
> e-mail onverhoopt niet voor u is bestemd dan verzoeken wij u
> vriendelijk contact op te nemen met de afzender en daarna het bericht te vernietigen.
> Deze e-mail mag niet worden doorgestuurd, openbaar gemaakt of
> verveelvoudigd worden zonder de toestemming van de afzender.
>
> ANWB betracht grote zorgvuldigheid bij het verzenden van e-mails. ANWB
> kan echter niet garanderen dat deze e-mail juist, volledig, tijdig en
> virusvrij wordt overgebracht. In een dergelijk geval is ANWB op geen
> enkele wijze aansprakelijk voor enige schade, direct dan wel indirect,
> in welke vorm dan ook.
>
> ANWB B.V.
>
> ________________________________
>
________________________________
Disclaimer
E-mail wordt door ANWB niet gebruikt voor het aangaan van externe verplichtingen.
Deze e-mail is uitsluitend bestemd voor geadresseerde(n). Indien deze e-mail onverhoopt niet voor u is bestemd dan verzoeken wij u vriendelijk contact op te nemen met de afzender en daarna het bericht te vernietigen. Deze e-mail mag niet worden doorgestuurd, openbaar gemaakt of verveelvoudigd worden zonder de toestemming van de afzender.
ANWB betracht grote zorgvuldigheid bij het verzenden van e-mails. ANWB kan echter niet garanderen dat deze e-mail juist, volledig, tijdig en virusvrij wordt overgebracht. In een dergelijk geval is ANWB op geen enkele wijze aansprakelijk voor enige schade, direct dan wel indirect, in welke vorm dan ook.
ANWB B.V.
________________________________
Re: Qpid Dispatch authenticate through ldap, is this possible
Posted by mlange <ml...@anwb.nl>.
Ganesh Murthy wrote
> On Mon, Apr 16, 2018 at 10:08 AM, mlange <
> mlange@
> > wrote:
>
>>
>> > That looks a bit as if artemis is trying to authenticate the connection
>> > via a client certificate. From the config snippet you supplied it
>> > doesn't look like it is using TLS, let alone supplying a client cert.
>> > Are you able to get a protocol trace for the interaction between the
>> > router and the broker? (A simple way to do this would be to start a
>> > router with that connector in with env var PN_TRACE_FRM=1 and capture
>> > the output)
>>
>> It shouldn't do that, trying to authenticate via client certificate
>> (well,
>> not yet at least)
>> With the same config, but then connecting directly to the broker (a
>> javax.jms.Connection(String user, String password); with the same
>> credentials) allows me to connect just fine.
>>
>> The trace gives quite some output; I think the relevant parts are these:
>> [0x7f595400bdb0]: -> SASL
>> [0x7f595400bdb0]: <- SASL
>> [0x7f595400bdb0]:0 <- @sasl-mechanisms(64)
>> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
>> [0x7f595400bdb0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS,
>> initial-response=b"
> anonymous@.host
> "]
>> [0x7f595400bdb0]:0 <- @sasl-outcome(68) [code=0]
>>
>> Here it seems as if qpid chooses to use ANONYMOUS to connect with the
>> broker
>> (which will not work, the broker is configured to require authentication)
>> whereas the broker seems to offer PLAIN as well.
>>
>> a bit later I see the connection:
>> [0x7f5954027d60]:4 <- @begin(17) [next-outgoing-id=0,
>> incoming-window=2147483647, outgoing-window=2147483647]
>> [0x7f5954027d60]:4 <- @attach(18)
>> [name="qpid-jms:sender:ID:8b0bc583-315f-4f54-8f17-ecc40379c7
>> 7f:1:1:1:testqueues.testqueue",
>> handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0,
>> source=@source(40) [address="ID:8b0bc583-315f-4f5
>> 4-8f17-ecc40379c77f:1:1:1",
>> durable=0, timeout=0, dynamic=false,
>> outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list",
>> :"amqp:released:list", :"amqp:modified:list"]], target=@target(41)
>> [address="testqueues.testqueue", durable=0, timeout=0, dynamic=false,
>> capabilities=@PN_SYMBOL[:queue]], initial-delivery-count=0,
>> max-message-size=0]
>> [0x7f5954027d60]:4 -> @begin(17) [remote-channel=4, next-outgoing-id=0,
>> incoming-window=2147483647, outgoing-window=2147483647]
>> [0x7f595400bdb0]:0 -> @begin(17) [next-outgoing-id=0,
>> incoming-window=2147483647, outgoing-window=2147483647]
>> [0x7f595400bdb0]:0 -> @attach(18)
>> [name="qpid-jms:sender:ID:8b0bc583-315f-4f54-8f17-ecc40379c7
>> 7f:1:1:1:testqueues.testqueue",
>> handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0,
>> source=@source(40) [address="ID:8b0bc583-315f-4f5
>> 4-8f17-ecc40379c77f:1:1:1",
>> durable=0, timeout=0, dynamic=false,
>> outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list",
>> :"amqp:released:list", :"amqp:modified:list"]], target=@target(41)
>> [address="testqueues.testqueue", durable=0, timeout=0, dynamic=false,
>> capabilities=@PN_SYMBOL[:queue]], initial-delivery-count=0,
>> max-message-size=0]
>> [0x7f595400bdb0]:0 <- @close(24) [error=@error(29)
>> [condition=:"amqp:internal-error", description="Unrecoverable error:
>> AMQ119031: Unable to validate user from /192.168.0.1:52202. Username:
>> null;
>> SSL certificate subject DN: unavailable"]]
>> [0x7f595400bdb0]: <- EOS
>> [0x7f595400bdb0]:0 -> @close(24) []
>> [0x7f595400bdb0]: -> EOS
>> [0x7f5954027d60]:4 -> @attach(18)
>> [name="qpid-jms:sender:ID:8b0bc583-315f-4f54-8f17-ecc40379c7
>> 7f:1:1:1:testqueues.testqueue",
>> handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0,
>> source=@source(40) [durable=0, timeout=0, dynamic=false],
>> target=@target(41)
>> [durable=0, timeout=0, dynamic=false], initial-delivery-count=0,
>> max-message-size=0]
>> [0x7f5954027d60]:4 -> @detach(22) [handle=0, closed=false,
>> error=@error(29)
>> [condition=:"qd:routed-link-lost", description="Connectivity to the peer
>> container was lost"]]
>> [0x7f5954027d60]:4 <- @detach(22) [handle=0, closed=true]
>>
>> Username is null, as well as client-certificates not provided (which is
>> logical, since there are none yet);
>>
>> When I add saslMechanisms: PLAIN to the connection{} I see a new error in
>> the SERVER log module (server.log):
>> proton:io:sasl_error SASL(-4): no mechanism available: No worthy mechs
>> found (Authentication failed [mech=none])
>>
> Is it possible that you don't have the relevant cyrus-sasl-plain libraries
> installed? Does the tests/system_tests_sasl_plain.py pass for you? If you
> look at that test, you will notice that one router is trying to connect to
> another router using PLAIN mech.
>
>>
>> which is weird, as it seems that PLAIN is offered by the broker. (or I am
>> interpreting things completely wrong)
>>
>>
>>
>> --
>> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936
>> .html
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
> users-unsubscribe@.apache
>> For additional commands, e-mail:
> users-help@.apache
>>
>>
I was about to write, that is not possible at all...
And then I looked... *hides in embarrassment* And here I thought I had them
installed on all my nodes... I hadn't O.O; how simple things can be,
sometimes... thanks!
--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Qpid Dispatch authenticate through ldap, is this possible
Posted by Ganesh Murthy <gm...@redhat.com>.
On Mon, Apr 16, 2018 at 10:08 AM, mlange <ml...@anwb.nl> wrote:
>
> > That looks a bit as if artemis is trying to authenticate the connection
> > via a client certificate. From the config snippet you supplied it
> > doesn't look like it is using TLS, let alone supplying a client cert.
> > Are you able to get a protocol trace for the interaction between the
> > router and the broker? (A simple way to do this would be to start a
> > router with that connector in with env var PN_TRACE_FRM=1 and capture
> > the output)
>
> It shouldn't do that, trying to authenticate via client certificate (well,
> not yet at least)
> With the same config, but then connecting directly to the broker (a
> javax.jms.Connection(String user, String password); with the same
> credentials) allows me to connect just fine.
>
> The trace gives quite some output; I think the relevant parts are these:
> [0x7f595400bdb0]: -> SASL
> [0x7f595400bdb0]: <- SASL
> [0x7f595400bdb0]:0 <- @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0x7f595400bdb0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS,
> initial-response=b"anonymous@masterbroker.host.name"]
> [0x7f595400bdb0]:0 <- @sasl-outcome(68) [code=0]
>
> Here it seems as if qpid chooses to use ANONYMOUS to connect with the
> broker
> (which will not work, the broker is configured to require authentication)
> whereas the broker seems to offer PLAIN as well.
>
> a bit later I see the connection:
> [0x7f5954027d60]:4 <- @begin(17) [next-outgoing-id=0,
> incoming-window=2147483647, outgoing-window=2147483647]
> [0x7f5954027d60]:4 <- @attach(18)
> [name="qpid-jms:sender:ID:8b0bc583-315f-4f54-8f17-ecc40379c7
> 7f:1:1:1:testqueues.testqueue",
> handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0,
> source=@source(40) [address="ID:8b0bc583-315f-4f5
> 4-8f17-ecc40379c77f:1:1:1",
> durable=0, timeout=0, dynamic=false,
> outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list",
> :"amqp:released:list", :"amqp:modified:list"]], target=@target(41)
> [address="testqueues.testqueue", durable=0, timeout=0, dynamic=false,
> capabilities=@PN_SYMBOL[:queue]], initial-delivery-count=0,
> max-message-size=0]
> [0x7f5954027d60]:4 -> @begin(17) [remote-channel=4, next-outgoing-id=0,
> incoming-window=2147483647, outgoing-window=2147483647]
> [0x7f595400bdb0]:0 -> @begin(17) [next-outgoing-id=0,
> incoming-window=2147483647, outgoing-window=2147483647]
> [0x7f595400bdb0]:0 -> @attach(18)
> [name="qpid-jms:sender:ID:8b0bc583-315f-4f54-8f17-ecc40379c7
> 7f:1:1:1:testqueues.testqueue",
> handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0,
> source=@source(40) [address="ID:8b0bc583-315f-4f5
> 4-8f17-ecc40379c77f:1:1:1",
> durable=0, timeout=0, dynamic=false,
> outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list",
> :"amqp:released:list", :"amqp:modified:list"]], target=@target(41)
> [address="testqueues.testqueue", durable=0, timeout=0, dynamic=false,
> capabilities=@PN_SYMBOL[:queue]], initial-delivery-count=0,
> max-message-size=0]
> [0x7f595400bdb0]:0 <- @close(24) [error=@error(29)
> [condition=:"amqp:internal-error", description="Unrecoverable error:
> AMQ119031: Unable to validate user from /192.168.0.1:52202. Username:
> null;
> SSL certificate subject DN: unavailable"]]
> [0x7f595400bdb0]: <- EOS
> [0x7f595400bdb0]:0 -> @close(24) []
> [0x7f595400bdb0]: -> EOS
> [0x7f5954027d60]:4 -> @attach(18)
> [name="qpid-jms:sender:ID:8b0bc583-315f-4f54-8f17-ecc40379c7
> 7f:1:1:1:testqueues.testqueue",
> handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0,
> source=@source(40) [durable=0, timeout=0, dynamic=false],
> target=@target(41)
> [durable=0, timeout=0, dynamic=false], initial-delivery-count=0,
> max-message-size=0]
> [0x7f5954027d60]:4 -> @detach(22) [handle=0, closed=false, error=@error(29)
> [condition=:"qd:routed-link-lost", description="Connectivity to the peer
> container was lost"]]
> [0x7f5954027d60]:4 <- @detach(22) [handle=0, closed=true]
>
> Username is null, as well as client-certificates not provided (which is
> logical, since there are none yet);
>
> When I add saslMechanisms: PLAIN to the connection{} I see a new error in
> the SERVER log module (server.log):
> proton:io:sasl_error SASL(-4): no mechanism available: No worthy mechs
> found (Authentication failed [mech=none])
>
Is it possible that you don't have the relevant cyrus-sasl-plain libraries
installed? Does the tests/system_tests_sasl_plain.py pass for you? If you
look at that test, you will notice that one router is trying to connect to
another router using PLAIN mech.
>
> which is weird, as it seems that PLAIN is offered by the broker. (or I am
> interpreting things completely wrong)
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936
> .html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: Qpid Dispatch authenticate through ldap, is this possible
Posted by mlange <ml...@anwb.nl>.
> That looks a bit as if artemis is trying to authenticate the connection
> via a client certificate. From the config snippet you supplied it
> doesn't look like it is using TLS, let alone supplying a client cert.
> Are you able to get a protocol trace for the interaction between the
> router and the broker? (A simple way to do this would be to start a
> router with that connector in with env var PN_TRACE_FRM=1 and capture
> the output)
It shouldn't do that, trying to authenticate via client certificate (well,
not yet at least)
With the same config, but then connecting directly to the broker (a
javax.jms.Connection(String user, String password); with the same
credentials) allows me to connect just fine.
The trace gives quite some output; I think the relevant parts are these:
[0x7f595400bdb0]: -> SASL
[0x7f595400bdb0]: <- SASL
[0x7f595400bdb0]:0 <- @sasl-mechanisms(64)
[sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
[0x7f595400bdb0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS,
initial-response=b"anonymous@masterbroker.host.name"]
[0x7f595400bdb0]:0 <- @sasl-outcome(68) [code=0]
Here it seems as if qpid chooses to use ANONYMOUS to connect with the broker
(which will not work, the broker is configured to require authentication)
whereas the broker seems to offer PLAIN as well.
a bit later I see the connection:
[0x7f5954027d60]:4 <- @begin(17) [next-outgoing-id=0,
incoming-window=2147483647, outgoing-window=2147483647]
[0x7f5954027d60]:4 <- @attach(18)
[name="qpid-jms:sender:ID:8b0bc583-315f-4f54-8f17-ecc40379c77f:1:1:1:testqueues.testqueue",
handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0,
source=@source(40) [address="ID:8b0bc583-315f-4f54-8f17-ecc40379c77f:1:1:1",
durable=0, timeout=0, dynamic=false,
outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list",
:"amqp:released:list", :"amqp:modified:list"]], target=@target(41)
[address="testqueues.testqueue", durable=0, timeout=0, dynamic=false,
capabilities=@PN_SYMBOL[:queue]], initial-delivery-count=0,
max-message-size=0]
[0x7f5954027d60]:4 -> @begin(17) [remote-channel=4, next-outgoing-id=0,
incoming-window=2147483647, outgoing-window=2147483647]
[0x7f595400bdb0]:0 -> @begin(17) [next-outgoing-id=0,
incoming-window=2147483647, outgoing-window=2147483647]
[0x7f595400bdb0]:0 -> @attach(18)
[name="qpid-jms:sender:ID:8b0bc583-315f-4f54-8f17-ecc40379c77f:1:1:1:testqueues.testqueue",
handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0,
source=@source(40) [address="ID:8b0bc583-315f-4f54-8f17-ecc40379c77f:1:1:1",
durable=0, timeout=0, dynamic=false,
outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list",
:"amqp:released:list", :"amqp:modified:list"]], target=@target(41)
[address="testqueues.testqueue", durable=0, timeout=0, dynamic=false,
capabilities=@PN_SYMBOL[:queue]], initial-delivery-count=0,
max-message-size=0]
[0x7f595400bdb0]:0 <- @close(24) [error=@error(29)
[condition=:"amqp:internal-error", description="Unrecoverable error:
AMQ119031: Unable to validate user from /192.168.0.1:52202. Username: null;
SSL certificate subject DN: unavailable"]]
[0x7f595400bdb0]: <- EOS
[0x7f595400bdb0]:0 -> @close(24) []
[0x7f595400bdb0]: -> EOS
[0x7f5954027d60]:4 -> @attach(18)
[name="qpid-jms:sender:ID:8b0bc583-315f-4f54-8f17-ecc40379c77f:1:1:1:testqueues.testqueue",
handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0,
source=@source(40) [durable=0, timeout=0, dynamic=false], target=@target(41)
[durable=0, timeout=0, dynamic=false], initial-delivery-count=0,
max-message-size=0]
[0x7f5954027d60]:4 -> @detach(22) [handle=0, closed=false, error=@error(29)
[condition=:"qd:routed-link-lost", description="Connectivity to the peer
container was lost"]]
[0x7f5954027d60]:4 <- @detach(22) [handle=0, closed=true]
Username is null, as well as client-certificates not provided (which is
logical, since there are none yet);
When I add saslMechanisms: PLAIN to the connection{} I see a new error in
the SERVER log module (server.log):
proton:io:sasl_error SASL(-4): no mechanism available: No worthy mechs
found (Authentication failed [mech=none])
which is weird, as it seems that PLAIN is offered by the broker. (or I am
interpreting things completely wrong)
--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Qpid Dispatch authenticate through ldap, is this possible
Posted by Gordon Sim <gs...@redhat.com>.
On 16/04/18 12:21, mlange wrote:
> But then I looked in the broker log... and there it is:
> 2018-04-16 13:05:04,657 WARN
> [org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler]
> AMQ119031: Unable to validate user from /192.168.0.1:33034. Username: null;
> SSL certificate subject DN: unavailable:
> ActiveMQAMQPInternalErrorException[errorType=INTERNAL_ERROR
> message=AMQ119031: Unable to validate user from /192.168.0.1:33034.
> Username: null; SSL certificate subject DN: unavailable]
That looks a bit as if artemis is trying to authenticate the connection
via a client certificate. From the config snippet you supplied it
doesn't look like it is using TLS, let alone supplying a client cert.
Are you able to get a protocol trace for the interaction between the
router and the broker? (A simple way to do this would be to start a
router with that connector in with env var PN_TRACE_FRM=1 and capture
the output)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Qpid Dispatch authenticate through ldap, is this possible
Posted by mlange <ml...@anwb.nl>.
So, now I have QDR able to authenticate via LDAP via SASL; When running some
tests, I got some errors that I could not relate... MessageProducer is
closed as IllegalStateException; Didn't have a clue...
But then I looked in the broker log... and there it is:
2018-04-16 13:05:04,657 WARN
[org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler]
AMQ119031: Unable to validate user from /192.168.0.1:33034. Username: null;
SSL certificate subject DN: unavailable:
ActiveMQAMQPInternalErrorException[errorType=INTERNAL_ERROR
message=AMQ119031: Unable to validate user from /192.168.0.1:33034.
Username: null; SSL certificate subject DN: unavailable]
The connector to the broker is built up like this:
connector {
name: broker1-conn
role: route-container
host: masterbroker.host.name
port: 10010
failoverList: amqp://slavebroker.host.name:10010
# saslMechanisms: DIGEST-MD5 PLAIN LOGIN EXTERNAL
saslUsername: <privileged user>
saslPassword: <password>
}
Apache Artemis does not use SASL, could that be the reason it does not see
any username provided?
In the java code I create a session with user X, QDR on the listener side
connects to LDAP as user Y (which has proxy authentication enabled as
authzTo), which works. and then I have this connector which actually is the
same as user X.
How do I make a valid authenticated connection as QDR to my Artemis broker?
--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Qpid Dispatch authenticate through ldap, is this possible
Posted by mlange <ml...@anwb.nl>.
Ganesh Murthy wrote
> If I am reading this correctly, you were able to get LDAP to work on the
> router after installing the correct rpms on CentOS? Congratulations.
> Share your steps so I can try this locally.
>
> Thanks.
I am and I have!
For the RPM: search on rpmfind.net to "cyrus-sasl-ldap", you're bound to
find the one I found.
There may be some overhead, and unneeded stuff I have done and installed, I
tried to filter those out, but can't promise I left none out :-)
Installed software:
yum install openldap openldap-clients compat-openldap
yum install cyrus-sasl-md5 cyrus-sasl-plain cyrus-sasl-scram
yum install python-saslwrapper
yum install cyrus-sasl*
and that other rpm: yum install
/tmp/cyrus-sasl-ldap-2.1.26-21.el7.x86_64.rpm
Next I had to do quite alot of stuff on LDAP; took most of my time to figure
those out.
in cn=config
olcAuthzPolicy: to
olcAuthzRegexp: uid=([^,]*),cn=digest-md5,cn=auth
ldap:///dc=test,o=org??sub?(uid=$1)
olcAuthzRegexp: uid=([^,]*),cn=myrealm,cn=digest-md5,cn=auth
ldap:///dc=test,o=org??sub?(uid=$1)
olcSaslHost: <fqdn hostname>
olcSaslRealm: <hostname>
In olcDatabase=bdb,cn=config:
olcAccess: to dn.children="cn=broker-users,dc=test,o=org" attrs=authzTo by
self auth
olcOverlay=ppolicy -> olcPPolicyHashCleartext: FALSE
Now create a user in cn=broker-users,dc=test,o=org (or whatever suits your
DIT)
uid=qdrouterd
password=qdrouterd (I'm just testing, so this should be fine)
authzTo: dn.regex:cn=[^,]*,ou=broker-users,dc=test,o=org$
authzTo: dn.regex:uid=[^,]*,ou=broker-users,dc=test,o=org$
authzTo: dn.regex:^uid=[^,]*,cn=digest-md5,cn=auth$
(This one got me busy for quite a while, I did this with Apache Directory
Studio, which does not show operational attributes (authzTo is) and
complains about the schema not allowing it. So, not seeing the entries, I
assumed they were not there... they were.... all the time... but got some
misspellings.
In /etc/sasl2/qdrouterd.conf
pwcheck_method: auxprop
auxprop_plugin: ldapdb
ldapdb_uri: ldap://my.ldap.host
ldapdb_id: qdrouterd
ldapdb_pw: qdrouterd
ldapdb_mech: DIGEST-MD5
log_level: 7
Mind the log-level :-)
And then the listener in qdrouterd:
listener {
name: ontvangst
host: 0.0.0.0
port: 5672
role: normal
authenticatePeer: yes
saslMechanisms: EXTERNAL DIGEST-MD5 PLAIN
}
Now I could do qdstat -a --sasl-user=qdrouterd --sasl-password=qdrouter
I havent yet tried to do more than this, but it shows I'm (almost) on track.
--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Qpid Dispatch authenticate through ldap, is this possible
Posted by Ganesh Murthy <gm...@redhat.com>.
On Wed, Apr 11, 2018 at 10:32 AM, mlange <ml...@anwb.nl> wrote:
> Thanks for that one; seems like a pretty complex way to get things done. In
> the mean time I found an rpm for CentOS 7, installed it and went a bit
> around things; when I can reproduce what I did (and leave out all the wrong
> steps in between)
>
If I am reading this correctly, you were able to get LDAP to work on the
router after installing the correct rpms on CentOS? Congratulations.
Share your steps so I can try this locally.
Thanks.
>
> It would then be a good idea to compare both solutions and check advantages
> / downsides from one method over the other.
> Expect an update soon(ish)!
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-
> f2158936.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: Qpid Dispatch authenticate through ldap, is this possible
Posted by mlange <ml...@anwb.nl>.
Thanks for that one; seems like a pretty complex way to get things done. In
the mean time I found an rpm for CentOS 7, installed it and went a bit
around things; when I can reproduce what I did (and leave out all the wrong
steps in between)
It would then be a good idea to compare both solutions and check advantages
/ downsides from one method over the other.
Expect an update soon(ish)!
--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Qpid Dispatch authenticate through ldap, is this possible
Posted by Ganesh Murthy <gm...@redhat.com>.
On Tue, Apr 10, 2018 at 10:58 AM, mlange <ml...@anwb.nl> wrote:
> Ganesh Murthy wrote
> > This seems to be very similar to the problem I ran into while trying to
> > setup LDAP. (I assume you have the latest cyrus-sasl-ldap library
> > installed)
> > Your configs look good. One thing you can do is to look at syslog output
> > and see the error messages from cyrus-sasl. Take a look at the "*Q:* It's
> > not working and won't tell me why! Help! " section in
> > https://www.cyrusimap.org/docs/cyrus-sasl/2.1.23/sysadmin.php
> > I remember when working on this a few months ago that there was a problem
> > in the initialization code of cyrus-sasl-ldap. and found some log
> messages
> > in syslog. I donwloaded the source code of cyrus-sasl-ldap and tried
> > looking thru it but could not exactly pin point the problem, so I
> > abandoned
> > the effort
> > (I seemed to have everything that the code was looking for but the
> > initialization still failed.)
> >
> > Please try looking at the syslog and reading the source code and see if
> > you
> > are able to figure out the problem.
>
> Of note here, regarding on what I'm doing, is that I am running a RHEL7
> machine, so need to do things the systemd way :-( My tough luck here is
> that
> I'm not that familiar with systemd;
>
Since you mentioned you are running on RHEL 7, I was able to authenticate a
client via the Qpid Dispatch router on a RHEL 7 machine. I had to use
Redhat IdM (https://access.redhat.com/products/identity-management) via PAM
and SSSD (
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/5.7_Release_Notes/sssd.html)
but any LDAP service can be used instead OF IdM.
Here are the steps I used to get the entire setup working. (assumes that
you have already installed the Qpid Dispatch Router)
1. Install the necessary cyrus-sasl libraries required by the router and
also set up listener
cyrus-sasl and cyrus-sasl-plain libraries need to be installed (yum install
cyrus-sasl cyrus-sasl-plain). The client sends the user name and password
in clear to the Router. Hence, in a production environment, this
client-router communication needs to be done over a TLS connection.
Setup the following listener in the router's config file (this is the
config file you use to start the router) - port number can be to your
choosing -
listener {
addr: 0.0.0.0
port: 15677
role: normal
authenticatePeer: yes
saslMechanisms: PLAIN
}
Notice that this sets up the Router listener to use PLAIN as the the only
mechanism used to communicate with the client. PLAIN is used because the
user name and password needs to be passed in clear to the PAM
authentication module.
2. Configure Dispatch Router to use a program called saslauthd to connect
to SSSD via PAM (Pluggable Authentication Modules)
The sasl config file is usually found in the /etc/sasl2/qdrouterd.conf
file. Add the following properties to this file -
pwcheck_method: saslauthd
auxprop_plugin:pam
mech_list: PLAIN
Notice that the pwcheck_method is set to saslauthd which is a program that
is installed as part of the cyrus-sasl library installation (yum install
cyrus-sasl). saslauthd is used to supply the user name and password to the
pam module. Notice here that the auxprop_plugin is set to pam which
instructs cyrus-sasl to enable authentication using PAM via saslauthd. The
mech_list is set to PLAIN to match the mech_list in step #1.
Make sure that the /etc/sysconfig/saslauthd file contains
MECH=pam
This enables saslauthd to use PAM.
3. Configure PAM
Every application has to have its own config file in the /etc/pam.d/
folder. The config file for Qpid Dispatch is called amqp. Open or create
the /etc/pam.d/amqp file and add the following to it -
#%PAM-1.0
auth required pam_securetty.so
auth required pam_nologin.so
account required pam_unix.so
session required pam_unix.so
What each of the above lines means is explained in detail here -
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/managing_smart_cards/pam_configuration_files
The above PAM configuration is not production grade but works in my
situation.
4. Configure PAM service on SSSD - This instructs PAM to use SSSD to
retrieve user information and is dealt with in detail here -
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/Configuration_Options-PAM_Configuration_Options.html
(I followed all steps in this link)
(SSSD is already installed on RHEL 7 machines)
5. Install Redhat IdM (Active Directory(AD) or any LDAP server can be used
instead of Redhat IdM)
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/install-server
Skip this step if you are not using IdM
6. Ask SSSD to discover AD or IdM services
realm discover test.example.com - This instructs SSSD to discover a
directory service running on the host test.example.com.
Use - realm discover --server-software=active-directory test.example.com -
to discovery AD
If the discovery is successful, to join the system SSSD to an identity
domain, use the realm join command and specify the domain name:
realm join test.example.com
SSSD will successfully join the realm. Test the whole setup with the
testsaslauthd program that comes as part of the cyrus-sasl installation
[root@test /]# testsaslauthd -u test -p test -r <your-realm-name> -s amqp
0: OK "Success."
If you don't get "OK", you are in trouble.
To troubleshoot watch the output of "journalctl -f" as you run testsaslauthd
7. In summary, now you have enabled SASL in Qpid Dispatch Router to talk to
PAM which in turn talks to SSSD which in turn can talk to any directory
service like AD, LDAP or IdM.
8. Finally start the router and run qdstat
reset; PN_TRACE_FRM=1 qdstat -b <host-name> -c --sasl-mechanisms=PLAIN
--sasl-username=mick@your-realm-name--sasl-password=mick
Note here again the the saslMechanisms is set to PLAIN and the realm is
included as part of the user name
Thanks.
>
> After installing a few more packages, of note: cyrus-sasl-md5
> cyrus-sasl-plain cyrus-sasl-scram and python-saslwrapper and restarting
> saslauthd and qdrouterd I finally got it to log things in "syslog"
>
> It appears that the plugin is missing, and for the life of me, I can't find
> any package that should provide it:
>
> qdstat -a --sasl-username=username --sasl-password=password
> 2018-04-10 16:49:11.966504 +0200 SERVER (info) Accepted connection to
> 0.0.0.0:5672 from 127.0.0.1:52900
> Apr 10 16:49:11 myserver qdrouterd[9031]: DIGEST-MD5 server step 1
> 2018-04-10 16:49:11.969892 +0200 SERVER (info) Connection from
> 127.0.0.1:52900 (to 0.0.0.0:5672) failed: proton:io:sasl_error SASL(-4):
> no
> mechanism available: unable to canonify user and get auxprops (Failed to
> authenticate client [mech=DIGEST-MD5])
> ConnectionException: Connection amqp://0.0.0.0:amqp/$management
> disconnected: Condition('amqp:unauthorized-access', 'Authentication failed
> [mech=DIGEST-MD5]')
> Apr 10 16:49:11 myserver python[9081]: DIGEST-MD5 client step 2
> Apr 10 16:49:11 myserver python[9081]: DIGEST-MD5 parse_server_challenge()
> Apr 10 16:49:11 myserver python[9081]: DIGEST-MD5 ask_user_info()
> Apr 10 16:49:11 myserver python[9081]: DIGEST-MD5 client step 2
> Apr 10 16:49:11 myserver python[9081]: DIGEST-MD5 ask_user_info()
> Apr 10 16:49:11 myserver python[9081]: DIGEST-MD5 make_client_response()
> Apr 10 16:49:11 myserver python[9081]: DIGEST-MD5 create_layer_keys()
> Apr 10 16:49:11 myserver qdrouterd[9031]: DIGEST-MD5 server step 2
> Apr 10 16:49:11 myserver qdrouterd[9031]: could not find auxprop plugin,
> was
> searching for 'ldapdb'
> Apr 10 16:49:11 myserver qdrouterd[9031]: could not find auxprop plugin,
> was
> searching for 'ldapdb'
> Apr 10 16:49:11 myserver qdrouterd[9031]: unable to canonify user and get
> auxprops
> Apr 10 16:49:11 myserver qdrouterd[9031]: DIGEST-MD5 common mech dispose
> Apr 10 16:49:11 myserver python[9081]: DIGEST-MD5 client mech dispose
> Apr 10 16:49:11 myserver python[9081]: DIGEST-MD5 common mech dispose
> Apr 10 16:49:11 myserver python[9081]: DIGEST-MD5 common mech free
>
> I get a similar error "could not find auxprop plugin" when using "slapd";
> this attempt is to use "ldapdb" in /etc/sasl2/qdrouterd.conf instead of
> slapd. Internet is not yet helping me find any package that would provide
> the plugin; Might be I have to revert to (re)compile some stuff; whether
> that would be openldap or sasl, I am not yet sure, trying to read me
> through
> these things.
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-
> f2158936.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: Qpid Dispatch authenticate through ldap, is this possible
Posted by mlange <ml...@anwb.nl>.
Ganesh Murthy wrote
> This seems to be very similar to the problem I ran into while trying to
> setup LDAP. (I assume you have the latest cyrus-sasl-ldap library
> installed)
> Your configs look good. One thing you can do is to look at syslog output
> and see the error messages from cyrus-sasl. Take a look at the "*Q:* It's
> not working and won't tell me why! Help! " section in
> https://www.cyrusimap.org/docs/cyrus-sasl/2.1.23/sysadmin.php
> I remember when working on this a few months ago that there was a problem
> in the initialization code of cyrus-sasl-ldap. and found some log messages
> in syslog. I donwloaded the source code of cyrus-sasl-ldap and tried
> looking thru it but could not exactly pin point the problem, so I
> abandoned
> the effort
> (I seemed to have everything that the code was looking for but the
> initialization still failed.)
>
> Please try looking at the syslog and reading the source code and see if
> you
> are able to figure out the problem.
Of note here, regarding on what I'm doing, is that I am running a RHEL7
machine, so need to do things the systemd way :-( My tough luck here is that
I'm not that familiar with systemd;
After installing a few more packages, of note: cyrus-sasl-md5
cyrus-sasl-plain cyrus-sasl-scram and python-saslwrapper and restarting
saslauthd and qdrouterd I finally got it to log things in "syslog"
It appears that the plugin is missing, and for the life of me, I can't find
any package that should provide it:
qdstat -a --sasl-username=username --sasl-password=password
2018-04-10 16:49:11.966504 +0200 SERVER (info) Accepted connection to
0.0.0.0:5672 from 127.0.0.1:52900
Apr 10 16:49:11 myserver qdrouterd[9031]: DIGEST-MD5 server step 1
2018-04-10 16:49:11.969892 +0200 SERVER (info) Connection from
127.0.0.1:52900 (to 0.0.0.0:5672) failed: proton:io:sasl_error SASL(-4): no
mechanism available: unable to canonify user and get auxprops (Failed to
authenticate client [mech=DIGEST-MD5])
ConnectionException: Connection amqp://0.0.0.0:amqp/$management
disconnected: Condition('amqp:unauthorized-access', 'Authentication failed
[mech=DIGEST-MD5]')
Apr 10 16:49:11 myserver python[9081]: DIGEST-MD5 client step 2
Apr 10 16:49:11 myserver python[9081]: DIGEST-MD5 parse_server_challenge()
Apr 10 16:49:11 myserver python[9081]: DIGEST-MD5 ask_user_info()
Apr 10 16:49:11 myserver python[9081]: DIGEST-MD5 client step 2
Apr 10 16:49:11 myserver python[9081]: DIGEST-MD5 ask_user_info()
Apr 10 16:49:11 myserver python[9081]: DIGEST-MD5 make_client_response()
Apr 10 16:49:11 myserver python[9081]: DIGEST-MD5 create_layer_keys()
Apr 10 16:49:11 myserver qdrouterd[9031]: DIGEST-MD5 server step 2
Apr 10 16:49:11 myserver qdrouterd[9031]: could not find auxprop plugin, was
searching for 'ldapdb'
Apr 10 16:49:11 myserver qdrouterd[9031]: could not find auxprop plugin, was
searching for 'ldapdb'
Apr 10 16:49:11 myserver qdrouterd[9031]: unable to canonify user and get
auxprops
Apr 10 16:49:11 myserver qdrouterd[9031]: DIGEST-MD5 common mech dispose
Apr 10 16:49:11 myserver python[9081]: DIGEST-MD5 client mech dispose
Apr 10 16:49:11 myserver python[9081]: DIGEST-MD5 common mech dispose
Apr 10 16:49:11 myserver python[9081]: DIGEST-MD5 common mech free
I get a similar error "could not find auxprop plugin" when using "slapd";
this attempt is to use "ldapdb" in /etc/sasl2/qdrouterd.conf instead of
slapd. Internet is not yet helping me find any package that would provide
the plugin; Might be I have to revert to (re)compile some stuff; whether
that would be openldap or sasl, I am not yet sure, trying to read me through
these things.
--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Qpid Dispatch authenticate through ldap, is this possible
Posted by Ganesh Murthy <gm...@redhat.com>.
On Mon, Apr 9, 2018 at 9:52 AM, mlange <ml...@anwb.nl> wrote:
> I went on and got a bit further, was hoping "to be there" though. Yet, no
> luck.
>
> So far, what I've been able to gather from around the interwebs, along with
> the new documentation (which is a huge step forward compared to the older
> documentation):
>
> I have configured openldap to use SASL (saslHost, extra mechanisms
> installed, and rewrite with olcAuthzRegexp for various sasl mechanisms)
>
> /etc/sasl2/qdrouterd.conf has been configured thus:
>
> pwcheck_method: auxprop
> auxprop_plugin: slapd
> ldapdb_uri: ldap://ldap.host
> # username and password are to be determined yet.
> ldapdb_id: username
> ldapdb_pw: password
> ldapdb_mech: DIGEST-MD5
>
> /etc/qpid-dispatch/qdrouterd.conf has the amqp listener configured thus:
> listener {
> name: ontvangst
> host: 0.0.0.0
> port: 5672
> role: normal
> authenticatePeer: yes
> saslMechanisms: EXTERNAL DIGEST-MD5
> }
>
> Yet, when I try to run a "qdstat -a --sasl-username=username
> --sasl-password=password --sasl-mechanisms=DIGEST-MD5"
> I get this response:
> ConnectionException: Connection amqp://0.0.0.0:amqp/$management
> disconnected: Condition('amqp:unauthorized-access', 'Authentication failed
> [mech=none]')
>
This seems to be very similar to the problem I ran into while trying to
setup LDAP. (I assume you have the latest cyrus-sasl-ldap library
installed)
Your configs look good. One thing you can do is to look at syslog output
and see the error messages from cyrus-sasl. Take a look at the "*Q:* It's
not working and won't tell me why! Help! " section in
https://www.cyrusimap.org/docs/cyrus-sasl/2.1.23/sysadmin.php
I remember when working on this a few months ago that there was a problem
in the initialization code of cyrus-sasl-ldap. and found some log messages
in syslog. I donwloaded the source code of cyrus-sasl-ldap and tried
looking thru it but could not exactly pin point the problem, so I abandoned
the effort
(I seemed to have everything that the code was looking for but the
initialization still failed.)
Please try looking at the syslog and reading the source code and see if you
are able to figure out the problem.
>
> I also added some log{ } entries, for a bunch of modules, but they don't
> seem to tell me what exactly happens and what is going wrong. What module
> should be used and probably also what level (could be I'm not seeing why
> due
> to a log level that's not telling the reason)
>
> The LDAP server itself is not the same server that hosts qpid-dispatch,
>
This should not matter (I think) but you could put the router on the same
machine as the LDAP host and see if it works.
> which may be making matters a bit more complicated, but there it is.
>
Goo luck!
>
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-
> f2158936.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: Qpid Dispatch authenticate through ldap, is this possible
Posted by mlange <ml...@anwb.nl>.
I went on and got a bit further, was hoping "to be there" though. Yet, no
luck.
So far, what I've been able to gather from around the interwebs, along with
the new documentation (which is a huge step forward compared to the older
documentation):
I have configured openldap to use SASL (saslHost, extra mechanisms
installed, and rewrite with olcAuthzRegexp for various sasl mechanisms)
/etc/sasl2/qdrouterd.conf has been configured thus:
pwcheck_method: auxprop
auxprop_plugin: slapd
ldapdb_uri: ldap://ldap.host
# username and password are to be determined yet.
ldapdb_id: username
ldapdb_pw: password
ldapdb_mech: DIGEST-MD5
/etc/qpid-dispatch/qdrouterd.conf has the amqp listener configured thus:
listener {
name: ontvangst
host: 0.0.0.0
port: 5672
role: normal
authenticatePeer: yes
saslMechanisms: EXTERNAL DIGEST-MD5
}
Yet, when I try to run a "qdstat -a --sasl-username=username
--sasl-password=password --sasl-mechanisms=DIGEST-MD5"
I get this response:
ConnectionException: Connection amqp://0.0.0.0:amqp/$management
disconnected: Condition('amqp:unauthorized-access', 'Authentication failed
[mech=none]')
I also added some log{ } entries, for a bunch of modules, but they don't
seem to tell me what exactly happens and what is going wrong. What module
should be used and probably also what level (could be I'm not seeing why due
to a log level that's not telling the reason)
The LDAP server itself is not the same server that hosts qpid-dispatch,
which may be making matters a bit more complicated, but there it is.
--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Qpid Dispatch authenticate through ldap, is this possible
Posted by Ganesh Murthy <gm...@redhat.com>.
2018-04-06 9:22 GMT-04:00 Michiel Lange <ml...@anwb.nl>:
> Hi,
>
> I use Qpid Dispatch to route JMS to an Artemis broker, which I have
> configured to use LDAP; allowing certain groups to create queues, send
> messages or receive.
> I am strugging getting Qpid dispatch to even use authentication, leave
> alone if the authentication information would be stored in LDAP (rather
> than a separate sasl database)
>
Would you rather have the router (instead of the broker) do the LDAP
authentication if it worked on the router ?
>
> At the moment I am running qpid-dispatch 1.0.0, running like this (all of
> these are currently using ANONYMOUS as saslMechanism, which is not really
> what I was hoping for)
>
> Host 1: contains only listeners
> Host 2: contains connectors, connecting to Host 1 (inter-router) and the
> actual brokers (route-container); This one also contains the linkRoutes to
> the defined brokers based on their prefix.
>
> I cannot really find that much in the documentation on how to setup
> authorization
> ________________________________
>
> Disclaimer
>
> E-mail wordt door ANWB niet gebruikt voor het aangaan van externe
> verplichtingen.
>
> Deze e-mail is uitsluitend bestemd voor geadresseerde(n). Indien deze
> e-mail onverhoopt niet voor u is bestemd dan verzoeken wij u vriendelijk
> contact op te nemen met de afzender en daarna het bericht te vernietigen.
> Deze e-mail mag niet worden doorgestuurd, openbaar gemaakt of
> verveelvoudigd worden zonder de toestemming van de afzender.
>
> ANWB betracht grote zorgvuldigheid bij het verzenden van e-mails. ANWB kan
> echter niet garanderen dat deze e-mail juist, volledig, tijdig en virusvrij
> wordt overgebracht. In een dergelijk geval is ANWB op geen enkele wijze
> aansprakelijk voor enige schade, direct dan wel indirect, in welke vorm dan
> ook.
>
> ANWB B.V.
>
> ________________________________
>
Re: Qpid Dispatch authenticate through ldap, is this possible
Posted by Ben Hardesty <bh...@redhat.com>.
Michiel,
There is some newer documentation on setting up authentication and
authorization, but it hasn't been published on the site yet. For now, you
can see it here:
https://github.com/apache/qpid-dispatch/blob/master/doc/new-book/configuration-security.adoc
If that doesn't help, or if you see other areas for improvement, please do
consider making a contribution to the documentation. I'm currently working
on some doc contribution guidelines, but for now I would suggest submitting
a bug against the doc (
https://issues.apache.org/jira/projects/DISPATCH/issues) and then creating
a pull request with your ideas/suggested edits. Also, please note that the
newest documentation is currently located in doc/new-book/.
Thanks,
Ben
On Fri, Apr 6, 2018 at 10:19 AM, mlange <ml...@anwb.nl> wrote:
> thanks; that helps alot already... Once I get this running, I'll try and
> see
> how I can contribute to the documentation, which I find a bit lacking in
> this respect.
>
> I have it running with saslMechanism ANONYMOUS, however, I'd like the
> dispatch router to "pass through" the credentials to the broker, rather
> than
> having a connection of its own with it's own credentials; Currently I have
> tried to setup the broker to allow anonymous connections, and that worked.
> When I set the username and password in the router-container connector that
> also worked.
>
> On my first host I have a configuration like this:
>
>
> Then I have another router that sits on the same machine that contains the
> brokers:
>
>
> I simplified it a bit (reduced the prefixes and sending to only one
> brokerpair, rather than the bunch I had defined, it breaks the purpose here
> :-) )
>
> As you can see, I have set everything, except the connection to the broker
> to ANONYMOUS; This because I have the broker configured to require login.
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-
> f2158936.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
--
BEN HARDESTY
TECHNICAL WRITER, CUSTOMER CONTENT SERVICES
Red Hat
<https://www.redhat.com/>
bhardest@redhat.com M: 412.913.3316 IM: bhardest
<https://red.ht/sig>
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
Re: Qpid Dispatch authenticate through ldap, is this possible
Posted by Ganesh Murthy <gm...@redhat.com>.
On Fri, Apr 6, 2018 at 10:21 AM, Michiel Lange <ml...@anwb.nl> wrote:
> Im sorry, I edited that one via the Nabble forums, but it seems <raw> tags
> don't get processed that well.
>
> So here it is again:
>
> thanks; that helps alot already... Once I get this running, I'll try and
> see how I can contribute to the documentation, which I find a bit lacking
> in this respect.
>
> I have it running with saslMechanism ANONYMOUS, however, I'd like the
> dispatch router to "pass through" the credentials to the broker, rather
> than having a connection of its own with it's own credentials; Currently I
> have tried to setup the broker to allow anonymous connections, and that
> worked. When I set the username and password in the router-container
> connector that also worked.
>
> On my first host I have a configuration like this:
>
> router {
> mode: interior
> id: router.clients.A
> }
>
> listener {
> host: 0.0.0.0
> port: 5670
> role: inter-router
> saslMechanisms: ANONYMOUS
> }
>
> listener {
> name: ontvangst
> host: 0.0.0.0
> port: 5672
> role: normal
> authenticatePeer: no
> saslMechanisms: ANONYMOUS
> }
>
> listener {
> name: mgmt
> host: 0.0.0.0
> port: 5673
> role: normal
> http: yes
> authenticatePeer: no
> saslMechanisms: ANONYMOUS
> }
>
>
> Then I have another router that sits on the same machine that contains the
> brokers:
>
> router {
> mode: interior
> id: router.broker.node.A
> }
>
> #
> # connectors to de client-facing qpid
> #
>
> connector {
> name: router.cli.A
> role: inter-router
> host: host_a
> port: 5670
> saslMechanisms: ANONYMOUS
> }
>
> connector {
> name: broker1-conn
> role: route-container
> host: broker1.master.host
> port: 10010
> failoverList: amqp://broker1.slave.host:10010
> saslUsername: administrator
> saslPassword: administrator
> }
>
you have set the saslUsername/saslPassword here. This information will be
sent to the broker during the initial sasl exchange. If you set the
environment variable PN_TRACE_FRM=1 you will see the router (via proton)
put out the frame traces
that are exchanged between the broker and the router. The router will send
the user name and password during the sasl exchange to the broker and you
can see that via the frame trace. Check the frame trace and let me know
what you see.
Your configs look good.
>
>
> # -------- link routes -------
>
> # this one is required for transactional sessions
> linkRoute {
> prefix: $coordinator
> dir: in
> connection: broker
> }
>
> linkRoute {
> prefix: myqueue
> connection: broker1-conn
> dir: in
> }
>
> linkRoute {
> prefix: myqueue
> connection: broker1-conn
> dir: out
> }
>
> linkRoute {
> prefix: theirqueue
> connection: broker1-conn
> dir: in
> }
>
> linkRoute {
> prefix: theirqueue
> connection: broker1-conn
> dir: out
> }
>
>
> I simplified it a bit (reduced the prefixes and sending to only one
> brokerpair, rather than the bunch I had defined, it breaks the purpose here
> :-) )
>
> As you can see, I have set everything, except the connection to the broker
> to ANONYMOUS; This because I have the broker configured to require login.
>
>
> -----Oorspronkelijk bericht-----
> Van: mlange [mailto:mlange@anwb.nl]
> Verzonden: vrijdag 6 april 2018 16:19
> Aan: users@qpid.apache.org
> Onderwerp: Re: Qpid Dispatch authenticate through ldap, is this possible
>
> thanks; that helps alot already... Once I get this running, I'll try and
> see how I can contribute to the documentation, which I find a bit lacking
> in this respect.
>
> I have it running with saslMechanism ANONYMOUS, however, I'd like the
> dispatch router to "pass through" the credentials to the broker, rather
> than having a connection of its own with it's own credentials; Currently I
> have tried to setup the broker to allow anonymous connections, and that
> worked.
> When I set the username and password in the router-container connector
> that also worked.
>
> On my first host I have a configuration like this:
>
>
> Then I have another router that sits on the same machine that contains the
> brokers:
>
>
> I simplified it a bit (reduced the prefixes and sending to only one
> brokerpair, rather than the bunch I had defined, it breaks the purpose here
> :-) )
>
> As you can see, I have set everything, except the connection to the broker
> to ANONYMOUS; This because I have the broker configured to require login.
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-
> f2158936.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For additional
> commands, e-mail: users-help@qpid.apache.org
>
> ________________________________
>
>
> Disclaimer
>
> E-mail wordt door ANWB niet gebruikt voor het aangaan van externe
> verplichtingen.
>
> Deze e-mail is uitsluitend bestemd voor geadresseerde(n). Indien deze
> e-mail onverhoopt niet voor u is bestemd dan verzoeken wij u vriendelijk
> contact op te nemen met de afzender en daarna het bericht te vernietigen.
> Deze e-mail mag niet worden doorgestuurd, openbaar gemaakt of
> verveelvoudigd worden zonder de toestemming van de afzender.
>
> ANWB betracht grote zorgvuldigheid bij het verzenden van e-mails. ANWB kan
> echter niet garanderen dat deze e-mail juist, volledig, tijdig en virusvrij
> wordt overgebracht. In een dergelijk geval is ANWB op geen enkele wijze
> aansprakelijk voor enige schade, direct dan wel indirect, in welke vorm dan
> ook.
>
> ANWB B.V.
> ________________________________
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
RE: Qpid Dispatch authenticate through ldap, is this possible
Posted by Michiel Lange <ml...@anwb.nl>.
Im sorry, I edited that one via the Nabble forums, but it seems <raw> tags don't get processed that well.
So here it is again:
thanks; that helps alot already... Once I get this running, I'll try and see how I can contribute to the documentation, which I find a bit lacking in this respect.
I have it running with saslMechanism ANONYMOUS, however, I'd like the dispatch router to "pass through" the credentials to the broker, rather than having a connection of its own with it's own credentials; Currently I have tried to setup the broker to allow anonymous connections, and that worked. When I set the username and password in the router-container connector that also worked.
On my first host I have a configuration like this:
router {
mode: interior
id: router.clients.A
}
listener {
host: 0.0.0.0
port: 5670
role: inter-router
saslMechanisms: ANONYMOUS
}
listener {
name: ontvangst
host: 0.0.0.0
port: 5672
role: normal
authenticatePeer: no
saslMechanisms: ANONYMOUS
}
listener {
name: mgmt
host: 0.0.0.0
port: 5673
role: normal
http: yes
authenticatePeer: no
saslMechanisms: ANONYMOUS
}
Then I have another router that sits on the same machine that contains the brokers:
router {
mode: interior
id: router.broker.node.A
}
#
# connectors to de client-facing qpid
#
connector {
name: router.cli.A
role: inter-router
host: host_a
port: 5670
saslMechanisms: ANONYMOUS
}
connector {
name: broker1-conn
role: route-container
host: broker1.master.host
port: 10010
failoverList: amqp://broker1.slave.host:10010
saslUsername: administrator
saslPassword: administrator
}
# -------- link routes -------
# this one is required for transactional sessions
linkRoute {
prefix: $coordinator
dir: in
connection: broker
}
linkRoute {
prefix: myqueue
connection: broker1-conn
dir: in
}
linkRoute {
prefix: myqueue
connection: broker1-conn
dir: out
}
linkRoute {
prefix: theirqueue
connection: broker1-conn
dir: in
}
linkRoute {
prefix: theirqueue
connection: broker1-conn
dir: out
}
I simplified it a bit (reduced the prefixes and sending to only one brokerpair, rather than the bunch I had defined, it breaks the purpose here :-) )
As you can see, I have set everything, except the connection to the broker to ANONYMOUS; This because I have the broker configured to require login.
-----Oorspronkelijk bericht-----
Van: mlange [mailto:mlange@anwb.nl]
Verzonden: vrijdag 6 april 2018 16:19
Aan: users@qpid.apache.org
Onderwerp: Re: Qpid Dispatch authenticate through ldap, is this possible
thanks; that helps alot already... Once I get this running, I'll try and see how I can contribute to the documentation, which I find a bit lacking in this respect.
I have it running with saslMechanism ANONYMOUS, however, I'd like the dispatch router to "pass through" the credentials to the broker, rather than having a connection of its own with it's own credentials; Currently I have tried to setup the broker to allow anonymous connections, and that worked.
When I set the username and password in the router-container connector that also worked.
On my first host I have a configuration like this:
Then I have another router that sits on the same machine that contains the
brokers:
I simplified it a bit (reduced the prefixes and sending to only one brokerpair, rather than the bunch I had defined, it breaks the purpose here
:-) )
As you can see, I have set everything, except the connection to the broker to ANONYMOUS; This because I have the broker configured to require login.
--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For additional commands, e-mail: users-help@qpid.apache.org
________________________________
Disclaimer
E-mail wordt door ANWB niet gebruikt voor het aangaan van externe verplichtingen.
Deze e-mail is uitsluitend bestemd voor geadresseerde(n). Indien deze e-mail onverhoopt niet voor u is bestemd dan verzoeken wij u vriendelijk contact op te nemen met de afzender en daarna het bericht te vernietigen. Deze e-mail mag niet worden doorgestuurd, openbaar gemaakt of verveelvoudigd worden zonder de toestemming van de afzender.
ANWB betracht grote zorgvuldigheid bij het verzenden van e-mails. ANWB kan echter niet garanderen dat deze e-mail juist, volledig, tijdig en virusvrij wordt overgebracht. In een dergelijk geval is ANWB op geen enkele wijze aansprakelijk voor enige schade, direct dan wel indirect, in welke vorm dan ook.
ANWB B.V.
________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Qpid Dispatch authenticate through ldap, is this possible
Posted by mlange <ml...@anwb.nl>.
thanks; that helps alot already... Once I get this running, I'll try and see
how I can contribute to the documentation, which I find a bit lacking in
this respect.
I have it running with saslMechanism ANONYMOUS, however, I'd like the
dispatch router to "pass through" the credentials to the broker, rather than
having a connection of its own with it's own credentials; Currently I have
tried to setup the broker to allow anonymous connections, and that worked.
When I set the username and password in the router-container connector that
also worked.
On my first host I have a configuration like this:
Then I have another router that sits on the same machine that contains the
brokers:
I simplified it a bit (reduced the prefixes and sending to only one
brokerpair, rather than the bunch I had defined, it breaks the purpose here
:-) )
As you can see, I have set everything, except the connection to the broker
to ANONYMOUS; This because I have the broker configured to require login.
--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Qpid Dispatch authenticate through ldap, is this possible
Posted by Ganesh Murthy <gm...@redhat.com>.
2018-04-06 9:22 GMT-04:00 Michiel Lange <ml...@anwb.nl>:
> Hi,
>
> I use Qpid Dispatch to route JMS to an Artemis broker, which I have
> configured to use LDAP; allowing certain groups to create queues, send
> messages or receive.
>
There is a cyrus-sal-ldap library that is available and *technically*
Dispatch could use it to connect to LDAP after making a few additions to
the Dispatch sasl config file *but* I have not been able to do this
successfully.
> I am strugging getting Qpid dispatch to even use authentication, leave
> alone if the authentication information would be stored in LDAP (rather
> than a separate sasl database)
>
You must be able enable authentication on the router using sasl plain
authentication . Please look at tests/system_tests_sasl_plain.py to see how
to set it up.
>
> At the moment I am running qpid-dispatch 1.0.0, running like this (all of
> these are currently using ANONYMOUS as saslMechanism, which is not really
> what I was hoping for)
>
ANONYMOUS should work right out of the box. Can you please share your
router config files so we can see if there is a configuration issue?
Thanks.
>
> Host 1: contains only listeners
> Host 2: contains connectors, connecting to Host 1 (inter-router) and the
> actual brokers (route-container); This one also contains the linkRoutes to
> the defined brokers based on their prefix.
>
> I cannot really find that much in the documentation on how to setup
> authorization
> ________________________________
>
> Disclaimer
>
> E-mail wordt door ANWB niet gebruikt voor het aangaan van externe
> verplichtingen.
>
> Deze e-mail is uitsluitend bestemd voor geadresseerde(n). Indien deze
> e-mail onverhoopt niet voor u is bestemd dan verzoeken wij u vriendelijk
> contact op te nemen met de afzender en daarna het bericht te vernietigen.
> Deze e-mail mag niet worden doorgestuurd, openbaar gemaakt of
> verveelvoudigd worden zonder de toestemming van de afzender.
>
> ANWB betracht grote zorgvuldigheid bij het verzenden van e-mails. ANWB kan
> echter niet garanderen dat deze e-mail juist, volledig, tijdig en virusvrij
> wordt overgebracht. In een dergelijk geval is ANWB op geen enkele wijze
> aansprakelijk voor enige schade, direct dan wel indirect, in welke vorm dan
> ook.
>
> ANWB B.V.
>
> ________________________________
>
Re: Qpid Dispatch authenticate through ldap, is this possible
Posted by Alan Conway <ac...@redhat.com>.
2018-04-06 9:22 GMT-04:00 Michiel Lange <ml...@anwb.nl>:
> Hi,
>
> I use Qpid Dispatch to route JMS to an Artemis broker, which I have
> configured to use LDAP; allowing certain groups to create queues, send
> messages or receive.
> I am strugging getting Qpid dispatch to even use authentication, leave
> alone if the authentication information would be stored in LDAP (rather
> than a separate sasl database)
>
> At the moment I am running qpid-dispatch 1.0.0, running like this (all of
> these are currently using ANONYMOUS as saslMechanism, which is not really
> what I was hoping for)
>
> Host 1: contains only listeners
> Host 2: contains connectors, connecting to Host 1 (inter-router) and the
> actual brokers (route-container); This one also contains the linkRoutes to
> the defined brokers based on their prefix.
>
> I cannot really find that much in the documentation on how to setup
> authorization
>
You are right about the doc, I've raised
https://issues.apache.org/jira/browse/DISPATCH-958 - feel free to add any
comments or suggestions.
I am fairly certain that dispatch can use LDAP, but unfortunately I don't
know the details. I am in an environment with Kerberos configured and the
SASL plugin in default-configured dispatch (all default SASL mechs enabled)
does send LDAP requests over my VPN - they don't do anything useful since
I am not set up for that but the plugin is definitely active and that
mechanism is being tried.
I'm quite certain this is just a (painful) configuration problem, so
hopefully we can help you through it and improve the doc in the process.