I have not passed those parameters. Is this something I need to set in
Zookeeper (zoo.cfg) ?
On Wed, Jan 15, 2020 at 12:12 PM Enrico Olivelli - Diennea <
enrico.olive...@diennea.com> wrote:
> Usually with SASL auth you are using:
> kerberos.removeHostFromPrincipal=true
> kerberos.removeRealmFromPrincipal=true
>
> is this the case for you ?
>
> Enrico
>
> Il giorno 15/01/20, 13:01 "Arpit Jain" <jain.arp...@gmail.com> ha
> scritto:
>
> I have asked in Curator mailing list as well but not much help. I am
> able
> to set ACL with sasl scheme by using zkCli.sh client in Zookeeper
> server.
> The idea is to use Curator to set the ACLs so that only my client
> application can access its Znodes.
>
>
> On Wed, Jan 15, 2020 at 9:21 AM Szalay-Bekő Máté <
> szalay.beko.m...@gmail.com>
> wrote:
>
> > I am not sure what is wrong with the code... I am not familiar with
> > Curator. I can try to google / reproduce this and see what is wrong,
> but it
> > will take a while for me. So first I would ask the others, maybe
> there is
> > someone who knows both ZooKeeper SASL and Curator and can help you
> more in
> > this mailing list. If noone replies, then I will try to setup a dummy
> > project with Curator to test this.
> >
> > Did you also ask around the Curator mailing list maybe? Would it
> help if I
> > send you code about setting the ACLs using plain ZooKeeper (and no
> Curator)?
> >
> > On Tue, Jan 14, 2020 at 2:48 PM Arpit Jain <jain.arp...@gmail.com>
> wrote:
> >
> >> Thanks for the clarification.
> >> I am able to authenticate client with Zookeeper. However, when I
> started
> >> to set ACLs with the same client, I get error messages. This is how
> I am
> >> creating curator client for setting ACLs
> >>
> >> CuratorFrameworkFactory.Builder builder =
> >>
> >> CuratorFrameworkFactory.builder().connectString(
> >> coordinatorHosts).retryPolicy(retryPolicy)
> >>
> >> .connectionTimeoutMs(coordinatorConnectionTimeout
> >> ).sessionTimeoutMs(coordinatorSessionTimeout);
> >>
> >> final CuratorFramework curatorFramework =
> >>
> >> builder.authorization("sasl", "zkclient/
> z...@example.com"
> >> .getBytes()).aclProvider(new ACLProvider() {
> >>
> >> @Override
> >>
> >> public List<ACL> getDefaultAcl() {
> >>
> >> return ZooDefs.Ids.CREATOR_ALL_ACL;
> >>
> >> }
> >>
> >>
> >> @Override
> >>
> >> public List<ACL> getAclForPath(String path) {
> >>
> >> return ZooDefs.Ids.CREATOR_ALL_ACL;
> >>
> >> }
> >>
> >> }).build();
> >>
> >>
> >> I see below logs in Zookeeper node:
> >>
> >>
> >>
> >>
> >>
> >> *2020-01-14 13:27:53,174 [myid:1] - INFO
> >> [NIOWorkerThread-3:SaslServerCallbackHandler@120] - Successfully
> >> authenticated client: authenticationID=zkclient/z...@example.com
> >> <z...@example.com>; authorizationID=zkclient/z...@example.com
> >> <z...@example.com>.2020-01-14 13:27:53,175 [myid:1] - INFO
> >> [NIOWorkerThread-3:SaslServerCallbackHandler@136] - Setting
> authorizedID:
> >> zkclient/z...@example.com <z...@example.com>2020-01-14 13:27:53,175
> >> [myid:1] - INFO [NIOWorkerThread-3:ZooKeeperServer@1170] - adding
> SASL
> >> authorization for authorizationID: zkclient/z...@example.com
> >> <z...@example.com>2020-01-14 13:27:53,182 [myid:1] - INFO
> >> [NIOWorkerThread-7:ZooKeeperServer@1095] - got auth packet
> >> /172.30.0.6:36658 <http://172.30.0.6:36658>2020-01-14 13:27:53,183
> [myid:1]
> >> - WARN [NIOWorkerThread-7:ZooKeeperServer@1123] - Authentication
> failed
> >> for scheme: sasl*
> >>
> >> Is this not the correct way to do it ?
> >>
> >>
> >>
> >> On Tue, Jan 14, 2020 at 11:52 AM Szalay-Bekő Máté <
> >> szalay.beko.m...@gmail.com> wrote:
> >>
> >>> The system property name is a bit misleading... this parameter is
> >>> actually specifies the username used in the ZooKeeper server
> principal.
> >>> (in your case the server principal is: zookeeper/z...@example.com)
> >>> AFAIK the ZooKeeper client (after authenticated as zkclient/
> >>> z...@example.com in Kerberos based on the jaas.conf file) needs
> to know
> >>> the ZooKeeper server principal in order to ask for a specific
> token from
> >>> kerberos which can be read by the ZooKeeper server.
> >>>
> >>> In 3.5.5 (or 3.5.6) you can use the zookeeper.sasl.client.username
> >>> parameter (plus some other parameters) to configure how the server
> >>> principal will be determined by the client.
> >>> See:
> >>>
> https://github.com/apache/zookeeper/blob/c11b7e26bc554b8523dc929761dd28808913f091/zookeeper-server/src/main/java/org/apache/zookeeper/SaslServerPrincipal.java#L48
> >>>
> >>> In future releases (3.5.7, 3.6, ...) you can also use
> >>> the zookeeper.server.principal parameter (a much better name I
> think) to
> >>> use a fix server principal name in the client.
> >>> See:
> >>>
> https://github.com/apache/zookeeper/blob/1c5d135d74f16275876c024401dc2de92909b20a/zookeeper-server/src/main/java/org/apache/zookeeper/SaslServerPrincipal.java#L50
> >>>
> >>> On Mon, Jan 13, 2020 at 6:03 PM Arpit Jain <jain.arp...@gmail.com>
> >>> wrote:
> >>>
> >>>> Does this user name have to be "Zookeeper"
> >>>> (-Dzookeeper.sasl.client.username=zookeeper) always ?
> >>>> And the client principal name is different than this
> username..Correct
> >>>> me if I am wrong ?
> >>>>
> >>>> On Mon, Jan 13, 2020 at 4:58 PM Arpit Jain <jain.arp...@gmail.com
> >
> >>>> wrote:
> >>>>
> >>>>> Thanks you so much !
> >>>>> It worked finally. I had to change
> >>>>> -Dzookeeper.sasl.client.username=zookeeper parameter.
> >>>>>
> >>>>> On Mon, Jan 13, 2020 at 4:40 PM Szalay-Bekő Máté <
> >>>>> szalay.beko.m...@gmail.com> wrote:
> >>>>>
> >>>>>> You are using 3.5.5 or 3.5.6, right?
> >>>>>> I think you need to specify:
> >>>>>> -Dzookeeper.sasl.client.username=zookeeper
> >>>>>> can you give it a try? If it doesn't work then I can take a
> deeper
> >>>>>> look (also we can enable some debug logging)
> >>>>>>
> >>>>>> On Mon, Jan 13, 2020 at 5:31 PM Arpit Jain <
> jain.arp...@gmail.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Hi
> >>>>>>>
> >>>>>>> I have Kerberos, Zookeeper and my application (using curator)
> >>>>>>> running in 3 docker containers with ZK SASL authentication
> enabled. The ZK
> >>>>>>> can login to Kerberos and starts successfully.
> >>>>>>>
> >>>>>>> The ZK server principal is zookeeper/z...@example.com
> >>>>>>> The client principal is : zkclient/z...@example.com
> >>>>>>>
> >>>>>>> While starting my application, I am seeing failure while
> obtaining
> >>>>>>> TGS.
> >>>>>>> See the log at Kerberos side:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> *Jan 13 15:22:19 kdc krb5kdc[20](info): AS_REQ (2 etypes {18
> 17})
> >>>>>>> 172.30.0.6 <http://172.30.0.6>: NEEDED_PREAUTH: zkclient/
> z...@example.com
> >>>>>>> <z...@example.com> for krbtgt/example....@example.com
> >>>>>>> <example....@example.com>, Additional pre-authentication
> requiredJan 13
> >>>>>>> 15:22:19 kdc krb5kdc[20](info): AS_REQ (2 etypes {18 17})
> 172.30.0.6
> >>>>>>> <http://172.30.0.6>: ISSUE: authtime 1578928939, etypes
> {rep=18 tkt=18
> >>>>>>> ses=18}, zkclient/z...@example.com <z...@example.com> for
> >>>>>>> krbtgt/example....@example.com <example....@example.com>Jan
> 13 15:22:19 kdc
> >>>>>>> krb5kdc[20](info): TGS_REQ (4 etypes {18 17 16 23}) 172.30.0.6
> >>>>>>> <http://172.30.0.6>: ISSUE: authtime 1578928939, etypes
> {rep=18 tkt=18
> >>>>>>> ses=18}, zkclient/z...@example.com <z...@example.com> for
> >>>>>>> zkclient/z...@example.com <z...@example.com>*
> >>>>>>>
> >>>>>>> However, if I use the zkCli.sh to login to Zookeeper, it
> >>>>>>> successfully logs in. See the log on Kerberos side. See the
> difference in
> >>>>>>> the last line while requesting TGS.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> *Jan 13 15:26:14 kdc krb5kdc[20](info): AS_REQ (2 etypes {18
> 17})
> >>>>>>> 172.30.0.3 <http://172.30.0.3>: NEEDED_PREAUTH: zkclient/
> z...@example.com
> >>>>>>> <z...@example.com> for krbtgt/example....@example.com
> >>>>>>> <example....@example.com>, Additional pre-authentication
> requiredJan 13
> >>>>>>> 15:26:14 kdc krb5kdc[20](info): AS_REQ (2 etypes {18 17})
> 172.30.0.3
> >>>>>>> <http://172.30.0.3>: ISSUE: authtime 1578929174, etypes
> {rep=18 tkt=18
> >>>>>>> ses=18}, zkclient/z...@example.com <z...@example.com> for
> >>>>>>> krbtgt/example....@example.com <example....@example.com>Jan
> 13 15:26:14 kdc
> >>>>>>> krb5kdc[20](info): TGS_REQ (4 etypes {18 17 16 23}) 172.30.0.3
> >>>>>>> <http://172.30.0.3>: ISSUE: authtime 1578929174, etypes
> {rep=18 tkt=18
> >>>>>>> ses=18}, zkclient/z...@example.com <z...@example.com> for
> >>>>>>> zookeeper/z...@example.com <z...@example.com>*
> >>>>>>>
> >>>>>>> The client section in JAAS config file is same in both the
> cases but
> >>>>>>> the server it is looking for is different in both the cases.
> >>>>>>> Could someone suggest why there is a difference ?
> >>>>>>>
> >>>>>>> Thanks
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On Mon, Jan 13, 2020 at 4:17 PM Szalay-Bekő Máté <
> >>>>>>> szalay.beko.m...@gmail.com> wrote:
> >>>>>>>
> >>>>>>>> Also please note, that the
> >>>>>>>> 'Configuration.getConfiguration().refresh()' will reload only
> the
> >>>>>>>> jaas.config.
> >>>>>>>> If you also need to reload the kerberos client config, then
> you can
> >>>>>>>> add the "refreshKrb5Config=true" line to your jaas.conf file.
> This will
> >>>>>>>> trigger to reload the krb.cfg file as well if needed.
> >>>>>>>>
> >>>>>>>> I am just working on a PR where I had to use both of these:
> >>>>>>>>
> https://github.com/apache/zookeeper/pull/1204/files#diff-0c01d3c68a71c68701d778cc556c8e0a
> >>>>>>>>
> >>>>>>>> Cheers,
> >>>>>>>> Mate
> >>>>>>>>
> >>>>>>>> On Thu, Jan 9, 2020 at 10:02 PM Damien Diederen <
> >>>>>>>> ddiede...@sinenomine.net> wrote:
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Hi Enrico,
> >>>>>>>>>
> >>>>>>>>> > There is a method to force JAAS to reload the system
> property.
> >>>>>>>>> >
> >>>>>>>>> > Something like Configuration.getConfiguration().refresh()
> >>>>>>>>>
> >>>>>>>>> Great to know! Thanks!
> >>>>>>>>>
> >>>>>>>>> > You have to call that method after changing the system
> property
> >>>>>>>>>
> >>>>>>>>> Cheers, -D
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> > Il gio 9 gen 2020, 20:05 Damien Diederen <
> >>>>>>>>> ddiede...@sinenomine.net> ha
> >>>>>>>>> > scritto:
> >>>>>>>>> >
> >>>>>>>>> >>
> >>>>>>>>> >> Hi Arpit, Máté,
> >>>>>>>>> >>
> >>>>>>>>> >> Arpit wrote:
> >>>>>>>>> >>
> >>>>>>>>> >> > The solution is to pass JAAS file
> >>>>>>>>> >> > with
> -Djava.security.auth.login.config=/path/to/jaas.conf.
> >>>>>>>>> >>
> >>>>>>>>> >> Okay—good.
> >>>>>>>>> >>
> >>>>>>>>> >> > Using System.setProperty does not work for me.
> >>>>>>>>> >>
> >>>>>>>>> >> Ah, I see. And I'm not surprised; I think Máté is on the
> right
> >>>>>>>>> track:
> >>>>>>>>> >>
> >>>>>>>>> >> >> I also faced this exception not long ago. I think it
> is an
> >>>>>>>>> edge case,
> >>>>>>>>> >> most
> >>>>>>>>> >> >> probably you have something else, but still... maybe it
> >>>>>>>>> helps:
> >>>>>>>>> >> >>
> >>>>>>>>> >> >> I tried to write a unit test which dynamically
> generated
> >>>>>>>>> multiple
> >>>>>>>>> >> >> jaas.conf files. Then I was setting the
> >>>>>>>>> >> >> java.security.auth.login.config system property to the
> >>>>>>>>> config file I
> >>>>>>>>> >> needed
> >>>>>>>>> >> >> in the given testcase, and when I tried to establish a
> >>>>>>>>> ZooKeeper
> >>>>>>>>> >> connection
> >>>>>>>>> >> >> in the unit test, I also got the same exception that
> you got.
> >>>>>>>>> >> >>
> >>>>>>>>> >> >> The problem was, that the security configuration file I
> >>>>>>>>> referred in the
> >>>>>>>>> >> >> java.security.auth.login.config system property file
> was
> >>>>>>>>> read only once,
> >>>>>>>>> >> >> then stored in memory. And it haven't got reloaded,
> even if
> >>>>>>>>> the file (or
> >>>>>>>>> >> >> its path in the system property) changed.
> >>>>>>>>> >>
> >>>>>>>>> >> My understanding is that the property is read very early
> after
> >>>>>>>>> "VM boot"
> >>>>>>>>> >> (the first time any class tries to access the
> >>>>>>>>> java.security.Provider):
> >>>>>>>>> >> the resource it points to is parsed at that point, and the
> >>>>>>>>> property
> >>>>>>>>> >> "never" checked again.
> >>>>>>>>> >>
> >>>>>>>>> >> (It *may* be possible to flush the "Spi" or something,
> but it's
> >>>>>>>>> clearly
> >>>>>>>>> >> not the kind of usage it was designed for.)
> >>>>>>>>> >>
> >>>>>>>>> >> >> Maybe the best in this case is to
> >>>>>>>>> >> >> specify separate JAAS config sections for each tests
> and use
> >>>>>>>>> a single
> >>>>>>>>> >> >> JAAS.conf file per JVM.
> >>>>>>>>> >>
> >>>>>>>>> >> That's probably the easiest if the set is enumerable.
> >>>>>>>>> >>
> >>>>>>>>> >> "Real dynamism" might require overriding the "Spi" or
> >>>>>>>>> "Provider," but
> >>>>>>>>> >> that's probably overkill for a few tests.
> >>>>>>>>> >>
> >>>>>>>>> >> (Now that I think of it… our tests are already run under
> the
> >>>>>>>>> JMockit
> >>>>>>>>> >> agent, so live-patching JAAS methods using mockit.MockUp
> might
> >>>>>>>>> be
> >>>>>>>>> >> another option :)
> >>>>>>>>> >>
> >>>>>>>>> >> Anyway. It looks like setting the property externally
> worked
> >>>>>>>>> for Arpit.
> >>>>>>>>> >>
> >>>>>>>>> >> Cheers, -D
> >>>>>>>>> >>
> >>>>>>>>>
> >>>>>>>>
>
>
>
> ________________________________
>
> CONFIDENTIALITY & PRIVACY NOTICE
> This e-mail (including any attachments) is strictly confidential and may
> also contain privileged information. If you are not the intended recipient
> you are not authorised to read, print, save, process or disclose this
> message. If you have received this message by mistake, please inform the
> sender immediately and destroy this e-mail, its attachments and any copies.
> Any use, distribution, reproduction or disclosure by any person other than
> the intended recipient is strictly prohibited and the person responsible
> may incur in penalties.
> The use of this e-mail is only for professional purposes; there is no
> guarantee that the correspondence towards this e-mail will be read only by
> the recipient, because, under certain circumstances, there may be a need to
> access this email by third subjects belonging to the Company.
>
