Return-Path: X-Original-To: apmail-accumulo-user-archive@www.apache.org Delivered-To: apmail-accumulo-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4B9DE186BC for ; Tue, 26 Jan 2016 18:51:47 +0000 (UTC) Received: (qmail 87224 invoked by uid 500); 26 Jan 2016 18:51:47 -0000 Delivered-To: apmail-accumulo-user-archive@accumulo.apache.org Received: (qmail 87175 invoked by uid 500); 26 Jan 2016 18:51:47 -0000 Mailing-List: contact user-help@accumulo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@accumulo.apache.org Delivered-To: mailing list user@accumulo.apache.org Received: (qmail 87165 invoked by uid 99); 26 Jan 2016 18:51:47 -0000 Received: from Unknown (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 26 Jan 2016 18:51:47 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 957F4C240E for ; Tue, 26 Jan 2016 18:51:46 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.981 X-Spam-Level: ** X-Spam-Status: No, score=2.981 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=phemi-com.20150623.gappssmtp.com Received: from mx1-us-west.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id hQTyuwCQenhb for ; Tue, 26 Jan 2016 18:51:42 +0000 (UTC) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) by mx1-us-west.apache.org (ASF Mail Server at mx1-us-west.apache.org) with ESMTPS id E1C9E205FA for ; Tue, 26 Jan 2016 18:51:41 +0000 (UTC) Received: by mail-lb0-f174.google.com with SMTP id cl12so97350754lbc.1 for ; Tue, 26 Jan 2016 10:51:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=phemi-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=1/EDojCAOYp3pjVq6X1sPTbR7gR0s/JhMfhnEhkzqWQ=; b=jT04zDtRdJPeYxfyUuwUP5fyLWl14mzvj+Ahv7LVAoCexh8E6sysJSV8oPG5vT6WQS NeYZ7H7PbEYgVlby3zXcEZtk4emxGPInoYVV605bnMnUGlQF082xX6KRtTOC5DkukkNu LX0KSi7oTxLO93ULjWamWycoi2T8/Vm9S5KZK0DycdA17rk2ZZ7Mm1u2SpQ1gHdxEv27 GBJ5oqT27R5bv/HQEczRIlY9ODI8n6dWrMsqTNJ332WKxUFhsU694J92QSBgt+Gu0sZ6 Zfl7y46u7W+V4YJrb9krEneeSymEoOFANh8pyNTOBL2MrEmxsmG5IuopRdQF8Tug5SV3 lLKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=1/EDojCAOYp3pjVq6X1sPTbR7gR0s/JhMfhnEhkzqWQ=; b=gCuAzw2wPwjPu4vjiOEfMf6v/7IabRSd8W8gssiYrf++pnBozL3xDhuDqotmRsR/yw UKhTBTwq8tmWxSTbBCgEg7+OtI21y1OPVAOO8kTMo6znt+hrTusVM5RWKyOkmzi30Sef mUgtvvT1gEm34ZYiBACZoIW5MEGvZDqyUe15DFOCP9lEVRdgMDY1iNWr1WR9tgZTYAd3 P8ww+kE1XjX3+J3bWb7vjygYIqFH6yvWCirRsMHnfinXBIY9Y4gQyJjcTUG3AUTERDeO +IzlyGlwNCAFD8LsweTkwRhZcuMqcGLcdnHlVkzhrriUKoFmqlZakQGlGBcHFoKLGHeu I4dg== X-Gm-Message-State: AG10YORSCOgXwkYPZCLcBiLOrP7KEGT0lRUI/B6H8ryleX8OWYbBLCmY2uvrVJPHsecrUjJubXkK1njMF5PMuxn9 MIME-Version: 1.0 X-Received: by 10.112.139.104 with SMTP id qx8mr4726056lbb.88.1453834300163; Tue, 26 Jan 2016 10:51:40 -0800 (PST) Received: by 10.25.139.2 with HTTP; Tue, 26 Jan 2016 10:51:40 -0800 (PST) In-Reply-To: References: <56A6F144.5000505@gmail.com> Date: Tue, 26 Jan 2016 10:51:40 -0800 Message-ID: Subject: Fwd: Kerberos and the Accumulo Proxy From: Tristen Georgiou To: user@accumulo.apache.org Content-Type: multipart/alternative; boundary=089e0115fb8e0625ea052a412d34 --089e0115fb8e0625ea052a412d34 Content-Type: text/plain; charset=UTF-8 Forgot to cc the user list, sorry for the forward: Thanks for the response, and yes, the explanation makes sense and de-mystifies the process. I was trying to get the impersonation working, but as Russ pointed out we were unable to set impersonation key's through Ambari since it rejects various characters like forward slashes and @ symbols. The impersonation documentation ( https://accumulo.apache.org/1.7/accumulo_user_manual.html#_impersonation) does explain the concept, but I struggled a bit with what the keys should look like; IMHO a real-world example would go a long way (I ended up looking at the proxy code to figure out how it was actually reading the principal from the key). Using the example I gave, then (correct me if I'm wrong) I would need to set the following properties: instance.rpc.sasl.impersonation.accumulo/mas3.example.com@EXAMPLE.COM.users = central@EXAMPLE.COM instance.rpc.sasl.impersonation.accumulo/mas3.example.com@EXAMPLE.COM.hosts = foo.example.com Getting this working isn't a priority at this point; I'm just doing some investigation into securing our clusters, but eventually we will need to set these keys. It sounds like Russ has had a chat with you, so I'll catch up with him tomorrow. Thanks! Tristen On Mon, Jan 25, 2016 at 8:08 PM, Josh Elser wrote: > Hi Tristen, > > I'm glad you found that issue. As much as I griped about it, I had > completely forgotten about the issue. Sadly, it looks like that fix is > already contained in 2.3.2.0[1] Your client code does look correct as well > (compared to the tests for this[2]). There are some good Kerberos tests in > the codebase if you know to look for 'em. > > The error message is a bit confusing since it's a client (your python) > talking to a client (the proxy) talking to the servers (Accumulo services). > I think this error message is saying that the Proxy is failing to > authenticate to Accumulo. This is about to get lengthy. > > A little bit of background on how this is supposed to work which hinges on > this fact: A Kerberos client's "secret" information is not made available > to the server. This means that your client keytab is not made available to > the Proxy server. The implications this creates for the use case you > outline is that the Proxy server *cannot* make a connection to Accumulo on > your behalf because Kerberos knows that the Proxy isn't actually you! (this > is actually cool if you think about it). > > This is where the Proxy impersonation configuration that Russ recently > asked about comes into play. The common approach (e.g. Hive, HBase) is to > configure Accumulo to "trust" the Proxy (identified by the Kerberos > principal) to "act" as a different user. In other words, impersonation > allows a client to authenticate to Accumulo as a different user than the > client's Kerberos credentials says it is. > > So, client <-> Proxy works like a normal connection. However, proxy <-> > {tserver,master} has the connection set up as the Proxy's Kerberos > identity, but Accumulo *allows* the Proxy to actually say that it is your > client. > > As such, your code is 100% correct, but it isn't going to work in the way > you're trying to use it. If you want a centralized Proxy server instance, > you'll need to set up impersonation. The other option is (which, I think it > better since we don't have a good multi-tenancy story for the Proxy) is to > run a Proxy server instance with your client Kerberos credentials instead > of the "accumulo" principal. This gets around the problem because both the > client and the Proxy act as "client" and you don't get the mismatch. > > This got really long, and I'm sorry for that :). Let me know, I'd be happy > to put some of this into the user manual if it's lacking. > > - Josh > > [1] > https://github.com/hortonworks/accumulo-release/blob/HDP-2.3.2.0-tag/proxy/src/main/java/org/apache/accumulo/proxy/Proxy.java#L245-L248 > [2] > https://github.com/hortonworks/accumulo-release/blob/HDP-2.3.2.0-tag/proxy/src/main/java/org/apache/accumulo/proxy/TestProxyClient.java > > Tristen Georgiou wrote: > >> I'm using Ambari 2.1.2.1, HDP 2.3.2 (so Accumulo 1.7.0) and I'm trying >> to get a Kerberized Accumulo proxy up and running; I can successully >> start the proxy, but I am having trouble connecting with it. >> >> Here is my Accumulo proxy properties file (I've censored my actual >> FQDN's): >> >> useMockInstance=false >> useMiniAccumulo=false >> protocolFactory=org.apache.thrift.protocol.TCompactProtocol$Factory >> tokenClass=org.apache.accumulo.core.client.security.tokens.KerberosToken >> port=42425 >> maxFrameSize=16M >> thriftServerType=sasl >> kerberosPrincipal=accumulo/mas3.example.com@EXAMPLE.COM >> >> kerberosKeytab=/etc/security/keytabs/accumulo.service.keytab >> instance=agile_accumulo >> zookeepers=mas1.example.com:2181 >> ,mas2.example.com:2181 >> ,mas3.example.com:2181 >> >> >> The proxy starts up fine, and then via Python I am doing the following: >> >> transport = >> TTransport.TSaslClientTransport(TSocket.TSocket('mas3.example.com >> ', 42425), 'mas3.example.com >> ', 'accumulo', QOP='auth') >> protocol = TCompactProtocol.TCompactProtocol(transport) >> client = AccumuloProxy.Client(protocol) >> transport.open() >> login = client.login('central@EXAMPLE.COM ', >> {}) >> >> Where I've created the principal central@EXAMPLE.COM >> and have run kinit on the server where I am >> trying to connect to the proxy from (not from mas3) >> >> The proxy log responds with this: >> >> 2016-01-25 21:42:01,294 [proxy.ProxyServer] ERROR: Failed to login >> org.apache.accumulo.core.client.AccumuloSecurityException: Error >> BAD_CREDENTIALS for user Principal in credentials object should match >> kerberos principal. Expected 'accumulo/mas3.example.com@example.COM' but >> was 'central@EXAMPLE.COM ' - Username or >> >> Password is Invalid >> at >> >> org.apache.accumulo.core.client.impl.ServerClient.execute(ServerClient.java:63) >> at >> >> org.apache.accumulo.core.client.impl.ConnectorImpl.(ConnectorImpl.java:67) >> at >> >> org.apache.accumulo.core.client.ZooKeeperInstance.getConnector(ZooKeeperInstance.java:248) >> at >> org.apache.accumulo.proxy.ProxyServer.getConnector(ProxyServer.java:232) >> at org.apache.accumulo.proxy.ProxyServer.login(ProxyServer.java:1574) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at >> >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:497) >> at >> >> org.apache.accumulo.core.trace.wrappers.RpcServerInvocationHandler.invoke(RpcServerInvocationHandler.java:39) >> at org.apache.accumulo.server.rpc.RpcWrapper$1.invoke(RpcWrapper.java:47) >> at com.sun.proxy.$Proxy14.login(Unknown Source) >> at >> >> org.apache.accumulo.proxy.thrift.AccumuloProxy$Processor$login.getResult(AccumuloProxy.java:5723) >> at >> >> org.apache.accumulo.proxy.thrift.AccumuloProxy$Processor$login.getResult(AccumuloProxy.java:5707) >> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39) >> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39) >> at >> >> org.apache.accumulo.server.rpc.UGIAssumingProcessor.process(UGIAssumingProcessor.java:102) >> at >> >> org.apache.accumulo.server.rpc.TimedProcessor.process(TimedProcessor.java:63) >> at >> >> org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:225) >> at >> >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >> at >> >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> at >> org.apache.accumulo.fate.util.LoggingRunnable.run(LoggingRunnable.java:35) >> at java.lang.Thread.run(Thread.java:745) >> Caused by: ThriftSecurityException(user:Principal in credentials object >> should match kerberos principal. Expected >> 'accumulo/mas3.example.com@EXAMPLE.COM >> ' but was 'central@EXAMPLE.COM >> ', code:BAD_CREDENTIALS) >> >> at >> >> org.apache.accumulo.core.client.impl.thrift.ClientService$authenticate_result$authenticate_resultStandardScheme.read(ClientService.java:15613) >> at >> >> org.apache.accumulo.core.client.impl.thrift.ClientService$authenticate_result$authenticate_resultStandardScheme.read(ClientService.java:15591) >> at >> >> org.apache.accumulo.core.client.impl.thrift.ClientService$authenticate_result.read(ClientService.java:15535) >> at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:78) >> at >> >> org.apache.accumulo.core.client.impl.thrift.ClientService$Client.recv_authenticate(ClientService.java:500) >> at >> >> org.apache.accumulo.core.client.impl.thrift.ClientService$Client.authenticate(ClientService.java:486) >> at >> >> org.apache.accumulo.core.client.impl.ConnectorImpl$1.execute(ConnectorImpl.java:70) >> at >> >> org.apache.accumulo.core.client.impl.ConnectorImpl$1.execute(ConnectorImpl.java:67) >> at >> >> org.apache.accumulo.core.client.impl.ServerClient.executeRaw(ServerClient.java:98) >> at >> >> org.apache.accumulo.core.client.impl.ServerClient.execute(ServerClient.java:61) >> ... 22 more >> >> I've tried to update my configuration for impersonation but have had no >> luck; my colleague did send out an email to this list about questions to >> do with impersonation, so perhaps that is the problem. >> >> Otherwise, anyone see anything obviously wrong with what I'm doing? >> Could it be related to this: >> https://issues.apache.org/jira/browse/ACCUMULO-3849 >> > --089e0115fb8e0625ea052a412d34 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Forgot to cc the user list= , sorry for the forward:

T= hanks for the response, and yes, the explanation makes sense and de-mystifi= es the process. I was trying to get the impersonation working, but as Russ = pointed out we were unable to set impersonation key's through Ambari si= nce it rejects various characters like forward slashes and @ symbols.
<= br>
Getting this working isn't a priority at this point;= I'm just doing some investigation into securing our clusters, but even= tually we will need to set these keys. It sounds like Russ has had a chat w= ith you, so I'll catch up with him tomorrow.

T= hanks!

<= div>Tristen

<= br>

On Mon, Jan 25= , 2016 at 8:08 PM, Josh Elser <josh.elser@gmail.com> wrot= e:
Hi Tristen,

I'm glad you found that issue. As much as I griped about it, I had comp= letely forgotten about the issue. Sadly, it looks like that fix is already = contained in 2.3.2.0[1] Your client code does look correct as well (compare= d to the tests for this[2]). There are some good Kerberos tests in the code= base if you know to look for 'em.

The error message is a bit confusing since it's a client (your python) = talking to a client (the proxy) talking to the servers (Accumulo services).= I think this error message is saying that the Proxy is failing to authenti= cate to Accumulo. This is about to get lengthy.

A little bit of background on how this is supposed to work which hinges on = this fact: A Kerberos client's "secret" information is not ma= de available to the server. This means that your client keytab is not made = available to the Proxy server. The implications this creates for the use ca= se you outline is that the Proxy server *cannot* make a connection to Accum= ulo on your behalf because Kerberos knows that the Proxy isn't actually= you! (this is actually cool if you think about it).

This is where the Proxy impersonation configuration that Russ recently aske= d about comes into play. The common approach (e.g. Hive, HBase) is to confi= gure Accumulo to "trust" the Proxy (identified by the Kerberos pr= incipal) to "act" as a different user. In other words, impersonat= ion allows a client to authenticate to Accumulo as a different user than th= e client's Kerberos credentials says it is.

So, client <-> Proxy works like a normal connection. However, proxy &= lt;-> {tserver,master} has the connection set up as the Proxy's Kerb= eros identity, but Accumulo *allows* the Proxy to actually say that it is y= our client.

As such, your code is 100% correct, but it isn't going to work in the w= ay you're trying to use it. If you want a centralized Proxy server inst= ance, you'll need to set up impersonation. The other option is (which, = I think it better since we don't have a good multi-tenancy story for th= e Proxy) is to run a Proxy server instance with your client Kerberos creden= tials instead of the "accumulo" principal. This gets around the p= roblem because both the client and the Proxy act as "client" and = you don't get the mismatch.

This got really long, and I'm sorry for that :). Let me know, I'd b= e happy to put some of this into the user manual if it's lacking.

- Josh

[1] https://github.com/hortonworks/accum= ulo-release/blob/HDP-2.3.2.0-tag/proxy/src/main/java/org/apache/accumulo/pr= oxy/Proxy.java#L245-L248
[2] https://github.com/hortonworks/accum= ulo-release/blob/HDP-2.3.2.0-tag/proxy/src/main/java/org/apache/accumulo/pr= oxy/TestProxyClient.java

Tristen Georgiou wrote:
I'm using Ambari 2.1.2.1, HDP 2.3.2 (so Accumulo 1.7.0) and I'm try= ing
to get a Kerberized Accumulo proxy up and running; I can successully
start the proxy, but I am having trouble connecting with it.

Here is my Accumulo proxy properties file (I've censored my actual FQDN= 's):

useMockInstance=3Dfalse
useMiniAccumulo=3Dfalse
protocolFactory=3Dorg.apache.thrift.protocol.TCompactProtocol$Factory
tokenClass=3Dorg.apache.accumulo.core.client.security.tokens.KerberosToken<= br> port=3D42425
maxFrameSize=3D16M
thriftServerType=3Dsasl
kerberosPrincipal=3Daccumulo/mas3.example.com@EXAMPLE.COM
 <mailto:mas3.example.com@EXAMPLE.COM>
kerberosKeytab=3D/etc/security/keytabs/accumulo.service.keytab
instance=3Dagile_accumulo
zookeepers=3Dmas1.example.com:2181
<http://mas1.example.com:2181/>,mas2.example.com:2181<= br> <http://mas2.example.com:2181/>,mas3.example.com:2181<= br> <http://mas3.example.com:2181/>

The proxy starts up fine, and then via Python I am doing the following:

transport =3D
TTransport.TSaslClientTransport(TSocket.TSocket('mas3.example.com
= <http://mas3.example.com/>', 42425), 'mas3.example.com <http://mas3.example.com/>', 'accumulo', QOP=3D'au= th')
protocol =3D TCompactProtocol.TCompactProtocol(transport)
client =3D AccumuloProxy.Client(protocol)
transport.open()
 login =3D client.login('central@EXAMPLE.COM <mailto:central@EXAMPLE.COM>', {})
Where I've created the principal central@EXAMPLE.COM
 <mailto:central= @EXAMPLE.COM> and have run kinit on the server where I am
trying to connect to the proxy from (not from mas3)

The proxy log responds with this:

2016-01-25 21:42:01,294 [proxy.ProxyServer] ERROR: Failed to login
org.apache.accumulo.core.client.AccumuloSecurityException: Error
BAD_CREDENTIALS for user Principal in credentials object should match
kerberos principal. Expected 'accumulo/mas3.example.com@example.COM'= ; but
 was 'central@E= XAMPLE.COM <mailto:central@EXAMPLE.COM>' - Username or

Password is Invalid
at
org.apache.accumulo.core.client.impl.ServerClient.execute(ServerClient.java= :63)
at
org.apache.accumulo.core.client.impl.ConnectorImpl.<init>(ConnectorIm= pl.java:67)
at
org.apache.accumulo.core.client.ZooKeeperInstance.getConnector(ZooKeeperIns= tance.java:248)
at org.apache.accumulo.proxy.ProxyServer.getConnector(ProxyServer.java:232)=
at org.apache.accumulo.proxy.ProxyServer.login(ProxyServer.java:1574)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:6= 2)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp= l.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.apache.accumulo.core.trace.wrappers.RpcServerInvocationHandler.invoke(R= pcServerInvocationHandler.java:39)
at org.apache.accumulo.server.rpc.RpcWrapper$1.invoke(RpcWrapper.java:47) at com.sun.proxy.$Proxy14.login(Unknown Source)
at
org.apache.accumulo.proxy.thrift.AccumuloProxy$Processor$login.getResult(Ac= cumuloProxy.java:5723)
at
org.apache.accumulo.proxy.thrift.AccumuloProxy$Processor$login.getResult(Ac= cumuloProxy.java:5707)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
at
org.apache.accumulo.server.rpc.UGIAssumingProcessor.process(UGIAssumingProc= essor.java:102)
at
org.apache.accumulo.server.rpc.TimedProcessor.process(TimedProcessor.java:6= 3)
at
org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolSer= ver.java:225)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1= 142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:= 617)
at
org.apache.accumulo.fate.util.LoggingRunnable.run(LoggingRunnable.java:35)<= br> at java.lang.Thread.run(Thread.java:745)
Caused by: ThriftSecurityException(user:Principal in credentials object
should match kerberos principal. Expected
'accumulo/mas3.example.com@EXAMPLE.COM
<mailto:mas3.example.com@EXAMPLE.COM>' but was 'central@EXAMPLE.COM
<mailto:central= @EXAMPLE.COM>', code:BAD_CREDENTIALS)

at
org.apache.accumulo.core.client.impl.thrift.ClientService$authenticate_resu= lt$authenticate_resultStandardScheme.read(ClientService.java:15613)
at
org.apache.accumulo.core.client.impl.thrift.ClientService$authenticate_resu= lt$authenticate_resultStandardScheme.read(ClientService.java:15591)
at
org.apache.accumulo.core.client.impl.thrift.ClientService$authenticate_resu= lt.read(ClientService.java:15535)
at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:78)
at
org.apache.accumulo.core.client.impl.thrift.ClientService$Client.recv_authe= nticate(ClientService.java:500)
at
org.apache.accumulo.core.client.impl.thrift.ClientService$Client.authentica= te(ClientService.java:486)
at
org.apache.accumulo.core.client.impl.ConnectorImpl$1.execute(ConnectorImpl.= java:70)
at
org.apache.accumulo.core.client.impl.ConnectorImpl$1.execute(ConnectorImpl.= java:67)
at
org.apache.accumulo.core.client.impl.ServerClient.executeRaw(ServerClient.j= ava:98)
at
org.apache.accumulo.core.client.impl.ServerClient.execute(ServerClient.java= :61)
... 22 more

I've tried to update my configuration for impersonation but have had no=
luck; my colleague did send out an email to this list about questions to do with impersonation, so perhaps that is the problem.

Otherwise, anyone see anything obviously wrong with what I'm doing?
Could it be related to this:
https://issues.apache.org/jira/browse/ACCUMULO-38= 49


--089e0115fb8e0625ea052a412d34--