From user-return-12518-archive-asf-public=cust-asf.ponee.io@zookeeper.apache.org Mon Jan 13 16:40:27 2020 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 69A9718064E for ; Mon, 13 Jan 2020 17:40:27 +0100 (CET) Received: (qmail 84059 invoked by uid 500); 13 Jan 2020 16:40:26 -0000 Mailing-List: contact user-help@zookeeper.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@zookeeper.apache.org Delivered-To: mailing list user@zookeeper.apache.org Received: (qmail 84041 invoked by uid 99); 13 Jan 2020 16:40:25 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 13 Jan 2020 16:40:25 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 8AB14C0620 for ; Mon, 13 Jan 2020 16:40:24 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.2, NUMERIC_HTTP_ADDR=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-he-de.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id aX8vaXpguEoa for ; Mon, 13 Jan 2020 16:40:22 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2a00:1450:4864:20::535; helo=mail-ed1-x535.google.com; envelope-from=szalay.beko.mate@gmail.com; receiver= Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) by mx1-he-de.apache.org (ASF Mail Server at mx1-he-de.apache.org) with ESMTPS id B14177DDF3 for ; Mon, 13 Jan 2020 16:40:21 +0000 (UTC) Received: by mail-ed1-x535.google.com with SMTP id j17so9059382edp.3 for ; Mon, 13 Jan 2020 08:40:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=x8HjVbL/d3mO1SlpjidudjepVPQMprymdaic1DN1ddk=; b=nl83BJBdA7cL2ROCev7lRYw/TllnX3+F5vw+qg/HFVy0fNs2Y4wWrHFTbMTw45l2lQ 7aBygNRPojF6f8Jc02PnDlEw/X2D3rd3BOQAiybu02EUJqPm9fMXYwNRWTTIz/Z76/xz U08EWmwu8aVRhj1B0S3Kmu38vjHhBJv9ndyFAmSDVPXHfGePLO2VwbeH7YOTxWUP7EhE scYh7vifTfq0Y8LdkOY2Sb8DgAcBO9Gs1/CN4856HoldzYu3N8/oYfSnkP0/w9T2bnlW NvkmmuWbc6rzyP7OSmVPGrfsbkayiOE5Su5+oBLzdvNRzNgmtBYcm9MGbZoI2NasJ5Wz GyBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=x8HjVbL/d3mO1SlpjidudjepVPQMprymdaic1DN1ddk=; b=XH94iapTrRhoEOFOdlX5pvdpdtGdPqCZagH55ugtjMuvtkvVjtEXurnX6/mxCGzzC3 yGL+OEn0LdAys2wHJvDtZ55RlxE2t0hYWbMdnp2RSUv1klaZazf+iYsAO3OE37YVLBsM oz8LD1pNDHl51bISklXlqq+m+dpKuvPwC1zS4jR09hLBnfvYRwoetxEPe7u4CSynngV8 kiDBxQTlFOpghq4ySJ2zGHrsAYcVHj9F5feA99sLs52ODldk/gA7jEAOOhpeLhBa0Jjg djEDZ++hcm1u4sYlPVpa6UKFs/7iX5omGPHX3aZMri2iLDvEBo/F+BQc7QyGPUaAV/mO AioA== X-Gm-Message-State: APjAAAVhJupmh2Ps59NKdAi6l+ZZ5jRhx49+Z3xI++k12YCcpB2nsuOb 0leIxM3LpYs17KvgHUHvAhA6hTEW+jvuZ+oH6Q== X-Google-Smtp-Source: APXvYqwcqSdfoVXjx8EDQbQ1cgu9ttav2G25yfYj54UoF1rZECn6nG/1vY/Y1GUfS1MXz4upJJ9euWthdycYAowlWvU= X-Received: by 2002:a05:6402:1343:: with SMTP id y3mr15492730edw.324.1578933621135; Mon, 13 Jan 2020 08:40:21 -0800 (PST) MIME-Version: 1.0 References: <87h814n37k.fsf@sinenomine.net> <87blrcmow9.fsf@sinenomine.net> <877e20mjh7.fsf@sinenomine.net> In-Reply-To: From: =?UTF-8?B?U3phbGF5LUJla8WRIE3DoXTDqQ==?= Date: Mon, 13 Jan 2020 17:40:09 +0100 Message-ID: Subject: Re: Zookeeper and curator SASL authentication To: Arpit Jain Cc: Damien Diederen , Enrico Olivelli , UserZooKeeper Content-Type: multipart/alternative; boundary="0000000000009c9d93059c0821bd" --0000000000009c9d93059c0821bd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable You are using 3.5.5 or 3.5.6, right? I think you need to specify: -Dzookeeper.sasl.client.username=3Dzookeeper 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 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 t= o > Kerberos and starts successfully. > > The ZK server principal is zookeeper/zoo1@EXAMPLE.COM > The client principal is : zkclient/zoo1@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 : NEEDED_PREAUTH: zkclient/zoo1@EXAMPLE.COM > for krbtgt/EXAMPLE.COM@EXAMPLE.COM > , Additional pre-authentication requiredJan 13 > 15:22:19 kdc krb5kdc[20](info): AS_REQ (2 etypes {18 17}) 172.30.0.6 > : ISSUE: authtime 1578928939, etypes {rep=3D18 tkt=3D1= 8 > ses=3D18}, zkclient/zoo1@EXAMPLE.COM for > krbtgt/EXAMPLE.COM@EXAMPLE.COM Jan 13 15:22:19 k= dc > krb5kdc[20](info): TGS_REQ (4 etypes {18 17 16 23}) 172.30.0.6 > : ISSUE: authtime 1578928939, etypes {rep=3D18 tkt=3D1= 8 > ses=3D18}, zkclient/zoo1@EXAMPLE.COM for > zkclient/zoo1@EXAMPLE.COM * > > However, if I use the zkCli.sh to login to Zookeeper, it successfully log= s > in. See the log on Kerberos side. See the difference in the last line whi= le > requesting TGS. > > > > *Jan 13 15:26:14 kdc krb5kdc[20](info): AS_REQ (2 etypes {18 17}) > 172.30.0.3 : NEEDED_PREAUTH: zkclient/zoo1@EXAMPLE.COM > for krbtgt/EXAMPLE.COM@EXAMPLE.COM > , Additional pre-authentication requiredJan 13 > 15:26:14 kdc krb5kdc[20](info): AS_REQ (2 etypes {18 17}) 172.30.0.3 > : ISSUE: authtime 1578929174, etypes {rep=3D18 tkt=3D1= 8 > ses=3D18}, zkclient/zoo1@EXAMPLE.COM for > krbtgt/EXAMPLE.COM@EXAMPLE.COM Jan 13 15:26:14 k= dc > krb5kdc[20](info): TGS_REQ (4 etypes {18 17 16 23}) 172.30.0.3 > : ISSUE: authtime 1578929174, etypes {rep=3D18 tkt=3D1= 8 > ses=3D18}, zkclient/zoo1@EXAMPLE.COM for > zookeeper/zoo1@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=C5=91 M=C3=A1t=C3=A9 < > szalay.beko.mate@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=3Dtrue" line to your jaas.conf file. This will tr= igger >> 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-0c01d3c68a71c68= 701d778cc556c8e0a >> >> Cheers, >> Mate >> >> On Thu, Jan 9, 2020 at 10:02 PM Damien Diederen >> 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 h= a >>> > scritto: >>> > >>> >> >>> >> Hi Arpit, M=C3=A1t=C3=A9, >>> >> >>> >> Arpit wrote: >>> >> >>> >> > The solution is to pass JAAS file >>> >> > with -Djava.security.auth.login.config=3D/path/to/jaas.conf. >>> >> >>> >> Okay=E2=80=94good. >>> >> >>> >> > Using System.setProperty does not work for me. >>> >> >>> >> Ah, I see. And I'm not surprised; I think M=C3=A1t=C3=A9 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 fil= e >>> 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 onl= y >>> 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," bu= t >>> >> that's probably overkill for a few tests. >>> >> >>> >> (Now that I think of it=E2=80=A6 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 >>> >> >>> >> --0000000000009c9d93059c0821bd--