enabling kerberos

Fabien Wernli

unread,

Oct 5, 2016, 8:19:48 AM10/5/16

to Search Guard

Hi,

I followed the documentation [1] and [2] step by step, but am unable to get the kerberos plugin to load.

When starting up, there is no log message about the kerberos plugin whatsoever, even when enabling debug in `sg_config.yml`.

I tried adding another `jar`, namely the audit logging, and that seems to work as expected.

--

[1] https://github.com/floragunncom/search-guard-auth-http-kerberos/wiki

[2] https://github.com/floragunncom/search-guard-docs/blob/master/kerberos.md

Fabien Wernli

unread,

Oct 5, 2016, 10:28:28 AM10/5/16

to Search Guard

I managed to enable the plugin (PBCAK: didn't run sgadmin.sh).

However, I still have no clue as to what's going on. Even debug mode spits nothing on stdout (elasticsearch has been started in the foreground):

[INFO ][com.floragunn.dlic.auth.http.kerberos.HTTPSpnegoAuthenticator] Kerberos debug is enabled on stdout

Then running `curl -k --negotiate -u: https://localhost:9200/_searchguard/authinfo` returns nothing. Also, stdout of elasticsearch stays silent.

I would expect the debug mode to tell me what's going on, but it just stays silent when issuing SPNEGO requests.

Now when enabling `dynamic.http.anonymous_auth_enabled` to true, I can get the following output:

{"user":"User [name=sg_anonymous, roles=[sg_anonymous_backendrole]]","remote_address":"127.0.0.1:57934","sg_roles":["sg_public"],"principal":null,"peer_certificates":"0"}

I was hoping the principal to contain my principal's name, stripped of the realm, but apparently this doesn't happen.

Moreover, still nothing in the "debug" log.

Any help appreciated

SG

unread,

Oct 5, 2016, 2:33:50 PM10/5/16

to search...@googlegroups.com

Kerberos is tricky :-)

Pls post your

- elasticsearch.yml
- sg_config.yml and the output of these commands:
- krb5.conf

and the output of these commands:

- "curl -V" (not all precompiled curl binaries are working)
- "klist" (after a "kinit")

Please change the logging.yml to log on DEBUG level and post the output after a login attempt like

$ "kinit" (get a TGT)
$ "curl -k -u : --negotiate -u: https://localhost:9200/"

> --
> You received this message because you are subscribed to the Google Groups "Search Guard" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to search-guard...@googlegroups.com.
> To post to this group, send email to search...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/519fc713-ec63-4ead-b0b0-f2f535c40f84%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Fabien Wernli

unread,

Oct 6, 2016, 3:54:56 AM10/6/16

to Search Guard

Hi,

Thanks for your quick reply.

I added the config files and output of the shell session to a gist for clarity (and size restriction).

Cheers

Fabien Wernli

unread,

Oct 6, 2016, 4:37:36 AM10/6/16

to Search Guard

Hi,

Some additional info: from the KDC log it seems something is wrong:

kdc Server not found in database: HTTP/localhost@OUR.TLD: no such entry found in hdb

Fabien Wernli

unread,

Oct 6, 2016, 4:51:55 AM10/6/16

to Search Guard

Progress!

I changed the listening port of elasticsearch to the public interface, and modified the principal's attributes (which used to be too restrictive).

Now I see the following in ES log:

[WARN ][com.floragunn.dlic.auth.http.kerberos.HTTPSpnegoAuthenticator] Service login not successful due to java.security.PrivilegedActionException: GSSException: No credential found for: 1.2.840.113554.1.2.2 usage: Accept

in...@search-guard.com

unread,

Oct 6, 2016, 4:57:40 AM10/6/16

to Search Guard

Maybe the keytab entries are wrong? Can you list the contents of your /etc/elasticsearch/searchguard.our.tld.keytab?
Seems to be a hostname/dns resolution problem.

You can also try adding this to krb5.conf (not recommended for production of course):

[libdefaults]
	dns_lookup_realm = false
	dns_lookup_kdc = false
	forwardable=true
	dns_canonicalize_hostname = false
	rdns = false
	ignore_acceptor_hostname = true

Here is a gist with a working configuration (also not recommended for production):

https://gist.github.com/floragunncom/e12d2eee5c25e2ae0165d37df12bba4a

PS: Can you also please add the output of "curl -V"?

Fabien Wernli

unread,

Oct 6, 2016, 5:14:24 AM10/6/16

to Search Guard

I updated the gist with the info from `curl -V`.

I resolved the DNS issue (see earlier reply), and now I'm seeing the entry of the Service principal in `klist` after issuing the curl command:

Ticket cache: FILE:/tmp/krb5cc_3942_cacbU16950
Default principal: fwe...@OUR.TLD

Valid starting     Expires            Service principal
10/06/16 11:04:02  10/07/16 08:45:31  krbtgt/OUR...@OUR.TLD
10/06/16 11:04:03  10/07/16 08:45:31  HTTP/some_nod...@OUR.TLD

However, I'm getting `401 Unauthorized`.

If I set `authc.kerberos_auth_admin.http_authenticator.challenge` to `false`, then the ES log is empty.

If I set `authc.kerberos_auth_admin.http_authenticator.challenge` to `true`,then I get the following error in ES log:

[2016-10-06 11:12:17,330][WARN ][com.floragunn.dlic.auth.http.kerberos.HTTPSpnegoAuthenticator] Service login not successful due to java.security.PrivilegedActionException: GSSException: No credential found for: 1.2.840.113554.1.2.2 usage: Accept

in...@search-guard.com

unread,

Oct 6, 2016, 5:29:16 AM10/6/16

to Search Guard

`authc.kerberos_auth_admin.http_authenticator.challenge` must be set to `true` (more on this here in the comments https://github.com/floragunncom/search-guard/blob/master/sgconfig/sg_config.yml)

your curl is pretty old and curl has few known kerberos bugs in old versions

i recommend to compile a recent version:

sudo apt-get -yqq install libssl-dev autoconf libtool build-essential wget openssl libkrb5-dev

EXPORT CURLDIR="/curlk"

mkdir -p $CURLDIR

cd $CURLDIR

wget -nv https://github.com/curl/curl/archive/curl-7_49_1.tar.gz

tar -xzf curl-7_49_1.tar.gz

cd $CURLDIR/curl-curl-7_49_1

./buildconf

./configure --with-gssapi --with-ssl --prefix="$CURLDIR"

make

make install

chmod +x $CURLDIR/bin/curl

$CURLDIR/bin/curl -V

On Thursday, 6 October 2016 11:14:24 UTC+2, Fabien Wernli wrote:

I updated the gist with the info from `curl -V`.
I resolved the DNS issue (see earlier reply), and now I'm seeing the entry of the Service principal in `klist` after issuing the curl command:

Ticket cache: FILE:/tmp/krb5cc_3942_cacbU16950 Default principal: fwe...@OUR.TLD Valid starting Expires Service principal 10/06/16 11:04:02 10/07/16 08:45:31 krbtgt/OUR...@OUR.TLD

10/06/16 11:04:03 10/07/16 08:45:31 HTTP/some_node.our.tld@OUR.TLD

However, I'm getting `401 Unauthorized`.

Fabien Wernli

unread,

Oct 6, 2016, 6:04:07 AM10/6/16

to Search Guard

I'll try, but I am successfully using this curl version against another SPNEGO enabled service.

Moreover, could you comment on the `GSSException`?

Fabien Wernli

unread,

Oct 6, 2016, 6:37:38 AM10/6/16

to Search Guard

I tested using curl 7.49.1.

It still fails, but with a different error in the ES log:

[2016-10-06 12:36:04,001][WARN ][com.floragunn.dlic.auth.http.kerberos.HTTPSpnegoAuthenticator] Service login not successful due to java.security.PrivilegedActionException: GSSException: Failure unspecified at GSS-API level (Mechanism level: Encryption type AES256 CTS mode with HMAC SHA1-96 is not supported/enabled)
java.security.PrivilegedActionException: GSSException: Failure unspecified at GSS-API level (Mechanism level: Encryption type AES256 CTS mode with HMAC SHA1-96 is not supported/enabled)

For the record, the newer curl still works with our other SPNEGO enabled service

Fabien Wernli

unread,

Oct 6, 2016, 6:45:52 AM10/6/16

to Search Guard

I just tried using firefox, and the error message in ES is the same as for curl 7.49.1:

Fabien Wernli

unread,

Oct 6, 2016, 6:47:46 AM10/6/16

to Search Guard

I guess this is related to java then: https://knowledge.safe.com/articles/395/enabling-aes256-in-the-java-runtime-environment-fo.html

in...@search-guard.com

unread,

Oct 6, 2016, 6:53:16 AM10/6/16

to Search Guard

yes, you need to install the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files" on every node.

If you`re fine with AES128 you can configure this with "supported_enctypes" in kdc.conf/krb5.conf - see https://gist.github.com/floragunncom/e12d2eee5c25e2ae0165d37df12bba4a

Fabien Wernli

unread,

Oct 6, 2016, 7:06:39 AM10/6/16

to Search Guard

I did: replaced the two jar files from JCE, but it didn't change anything (after restarting ES).

I am now trying to use openssl instead by following the guide at https://github.com/floragunncom/search-guard-ssl-docs/blob/master/openssl.md

in...@search-guard.com

unread,

Oct 6, 2016, 7:15:36 AM10/6/16

to Search Guard

That will not help here - don't confuse kerberos with SSL

You can verify that JCE was installed correctly if you do NOT see something like "AES-256 not supported, max key length for AES ..." in elasticsearch logs.

On the other side if you have JCE not installed you see something like "AES-256 not supported, max key length for AES ..."

Fabien Wernli

unread,

Oct 6, 2016, 7:55:13 AM10/6/16

to Search Guard

I successfully enabled OpenSSL:

[2016-10-06 13:14:05,691][INFO ][com.floragunn.searchguard.ssl.SearchGuardKeyStore] Open SSL OpenSSL 1.0.2h  3 May 2016 available
[2016-10-06 13:14:06,022][INFO ][com.floragunn.searchguard.ssl.SearchGuardKeyStore] sslTransportClientProvider:OPENSSL with ciphers [TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA]

And the error is still the same:

java.security.PrivilegedActionException: GSSException: Failure unspecified at GSS-API level (Mechanism level: Invalid argument (400) - Cannot find key of appropriate type to decrypt AP REP - AES256 CTS mode with HMAC SHA1-96)

Using a weaker key as suggested in your krb5.conf results in almost the same message (matching the key type of AES128):

rbException: Invalid argument (400) - Cannot find key of appropriate type to decrypt AP REP - AES128 CTS mode with HMAC SHA1-96

in...@search-guard.com

unread,

Oct 6, 2016, 8:11:58 AM10/6/16

to Search Guard

as i said: don't confuse Kerberos with SSL

Make sure that you keytab and krb tickets have a the appropriate keytype (AES128 CTS mode with HMAC SHA1-96) - maybe you have created them with AES256 and will not work of course

Fabien Wernli

unread,

Oct 6, 2016, 8:32:14 AM10/6/16

to Search Guard

To leave no doubts, I removed all keys except AES128 CTS from the keyfile:

klist -k /etc/elasticsearch/searchguard.in2p3.fr.keytab -e
Keytab name: FILE:/etc/elasticsearch/searchguard.in2p3.fr.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   1 HTTP/node42....@OUR.TLD (aes128-cts-hmac-sha1-96)

I still get the same error message using new curl, and `No credential found for: 1.2.840.113554.1.2.2 usage: Accept` when using the old version

And yes, I confuse SSL and kerberos, of course I do it's so confusing :-)

in...@search-guard.com

unread,

Oct 6, 2016, 8:47:04 AM10/6/16

to Search Guard

`No credential found for: 1.2.840.113554.1.2.2 usage: Accept` is a curl bug with old curl -> https://curl.haxx.se/mail/tracker-2014-07/0067.html

Can you again post kdc.conf and krb5.conf with enctypes set?

In kdc.conf you should have something like supported_enctypes = aes128-cts-hmac-sha1-96:normal and in krb5.conf:

default_tkt_enctypes = aes128-cts-hmac-sha1-96 rc4-hmac

default_tgs_enctypes = aes128-cts-hmac-sha1-96 rc4-hmac

permitted_enctypes = aes128-cts-hmac-sha1-96 rc4-hmac

And pls check your KVNO -> https://docs.oracle.com/cd/E36784_01/html/E37126/makehtml-id-4.html

Fabien Wernli

unread,

Oct 6, 2016, 8:57:58 AM10/6/16

to Search Guard

we use heimdal as kdc and I'm not sure how to modify the supported enc_type list.

Fabien Wernli

unread,

Oct 13, 2016, 7:23:15 AM10/13/16

to Search Guard

Is ldap required?

in...@search-guard.com

unread,

Oct 16, 2016, 3:25:00 PM10/16/16

to Search Guard

For Kerberos ldap is not required (from Search Guard perspective)
Did you checked your KVNO?

On Thursday, 13 October 2016 13:23:15 UTC+2, Fabien Wernli wrote:

Is ldap required?

Fabien Wernli

unread,

Oct 28, 2016, 4:36:01 AM10/28/16

to Search Guard

yes, thanks I checked the KVNO is the same

Fabien Wernli

unread,

Jan 31, 2017, 9:40:45 AM1/31/17

to Search Guard

Hi,

I made some progress on our new test cluster. Now I get a different error when using `curl --negotiate...`:

[2017-01-31 15:34:16,942][DEBUG][com.floragunn.searchguard.auth.BackendRegistry] Try to extract auth creds from http spnego
[2017-01-31 15:34:16,943][WARN ][rest.suppressed          ] path: /, params: {}
java.lang.NoClassDefFoundError: Could not initialize class com.sun.security.auth.module.Krb5LoginModule
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java:278)
        at javax.security.auth.login.LoginContext.invoke(LoginContext.java:718)
        at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203)
        at javax.security.auth.login.LoginContext$4.run(LoginContext.java:690)
        at javax.security.auth.login.LoginContext$4.run(LoginContext.java:688)
        at java.security.AccessController.doPrivileged(Native Method)
        at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:687)
        at javax.security.auth.login.LoginContext.login(LoginContext.java:595)
        at com.floragunn.dlic.auth.http.kerberos.util.JaasKrbUtil.loginUsingKeytab(JaasKrbUtil.java:85)
        at com.floragunn.dlic.auth.http.kerberos.HTTPSpnegoAuthenticator.extractCredentials0(HTTPSpnegoAuthenticator.java:203)
        at com.floragunn.dlic.auth.http.kerberos.HTTPSpnegoAuthenticator.access$300(HTTPSpnegoAuthenticator.java:53)
        at com.floragunn.dlic.auth.http.kerberos.HTTPSpnegoAuthenticator$2.run(HTTPSpnegoAuthenticator.java:174)
        at com.floragunn.dlic.auth.http.kerberos.HTTPSpnegoAuthenticator$2.run(HTTPSpnegoAuthenticator.java:171)
        at java.security.AccessController.doPrivileged(Native Method)
        at com.floragunn.dlic.auth.http.kerberos.HTTPSpnegoAuthenticator.extractCredentials(HTTPSpnegoAuthenticator.java:171)
        at com.floragunn.searchguard.auth.BackendRegistry.authenticate(BackendRegistry.java:436)
        at com.floragunn.searchguard.filter.SearchGuardRestFilter.process(SearchGuardRestFilter.java:56)
        at org.elasticsearch.rest.RestController$ControllerFilterChain.continueProcessing(RestController.java:264)
        at org.elasticsearch.rest.RestController.dispatchRequest(RestController.java:161)
        at org.elasticsearch.http.HttpServer.internalDispatchRequest(HttpServer.java:153)
        at org.elasticsearch.http.HttpServer$Dispatcher.dispatchRequest(HttpServer.java:101)
        at org.elasticsearch.http.netty.NettyHttpServerTransport.dispatchRequest(NettyHttpServerTransport.java:451)
        at com.floragunn.searchguard.ssl.http.netty.SearchGuardSSLNettyHttpServerTransport.dispatchRequest(SearchGuardSSLNettyHttpServerTransport.java:162)
        at org.elasticsearch.http.netty.HttpRequestHandler.messageReceived(HttpRequestHandler.java:61)
        at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
        at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
        at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
        at org.elasticsearch.http.netty.pipelining.HttpPipeliningHandler.messageReceived(HttpPipeliningHandler.java:60)
        at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:88)
        at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
        at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
        at org.jboss.netty.channel.SimpleChannelUpstreamHandler.messageReceived(SimpleChannelUpstreamHandler.java:124)
        at org.elasticsearch.http.netty.cors.CorsHandler.messageReceived(CorsHandler.java:87)
        at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
        at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
        at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
        at org.jboss.netty.handler.codec.http.HttpChunkAggregator.messageReceived(HttpChunkAggregator.java:145)
        at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
        at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
        at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
        at org.jboss.netty.handler.codec.http.HttpContentDecoder.messageReceived(HttpContentDecoder.java:108)
        at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
        at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
        at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
        at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296)
        at org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:459)
        at org.jboss.netty.handler.codec.replay.ReplayingDecoder.callDecode(ReplayingDecoder.java:536)
        at org.jboss.netty.handler.codec.replay.ReplayingDecoder.messageReceived(ReplayingDecoder.java:435)
        at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
        at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
        at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
        at org.elasticsearch.common.netty.OpenChannelsHandler.handleUpstream(OpenChannelsHandler.java:75)
        at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
        at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
        at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296)
        at org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:462)
        at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:443)
        at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:303)
        at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
        at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
        at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559)
        at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268)
        at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255)
        at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88)
        at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:108)
        at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:337)
        at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:89)
        at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178)
        at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
        at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:745)

SG

unread,

Jan 31, 2017, 10:14:57 AM1/31/17

to search...@googlegroups.com

Whats your JVM version and vendor? This class (com.sun.security.auth.module.Krb5LoginModule) is part of the JVM standard library.

> --
> You received this message because you are subscribed to the Google Groups "Search Guard" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to search-guard...@googlegroups.com.
> To post to this group, send email to search...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/13f5c83b-785e-4323-a805-bb6bfc84dfec%40googlegroups.com.

Fabien Wernli

unread,

Jan 31, 2017, 10:49:41 AM1/31/17

to Search Guard

/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.111-2.6.7.2.el7_2.x86_64

Fabien Wernli

unread,

Jan 31, 2017, 10:52:18 AM1/31/17

to Search Guard

I just retried with openjdk 1.8, and am back to square 1 :-):

java.security.PrivilegedActionException: GSSException: No credential found for: 1.2.840.113554.1.2.2 usage: Accept

Fabien Wernli

unread,

Jan 31, 2017, 10:59:34 AM1/31/17

to Search Guard

I'll give the new curl version another try

SG

unread,

Jan 31, 2017, 11:00:18 AM1/31/17

to search...@googlegroups.com

make sure that you curl version fits, see https://gist.github.com/faxm0dem/383bcce16c91d61ebec94e2d1e999902
curl prior to 7.49 contains some nasty bogus Kerberos related bugs.
If you need help with compiling a recent curl version including GSS-AP, Kerberos, SPNEGO and OpenSSL i am happy to provide a script for that
(in that case i need to know your linux distro/version)

To make curl work use a command like this:
curl -Ss -vv -u : --negotiate http://server:9200/

And "curl -V" should look like:

curl 7.49.1-DEV (x86_64-pc-linux-gnu) libcurl/7.49.1-DEV OpenSSL/1.0.2g zlib/1.2.8
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP UnixSockets

• Make sure you have curl 7.49 or later (older versions have know kerberos bugs)
• Make sure GSS-API and Kerberos and SPNEGO are listed in as Features

> Am 31.01.2017 um 16:52 schrieb Fabien Wernli <swis...@gmail.com>:
>
> I just retried with openjdk 1.8, and am back to square 1 :-):
>
> java.security.PrivilegedActionException: GSSException: No credential found for: 1.2.840.113554.1.2.2 usage: Accept
>
>
>
>

> --
> You received this message because you are subscribed to the Google Groups "Search Guard" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to search-guard...@googlegroups.com.
> To post to this group, send email to search...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/e4015423-07ee-4884-a134-9047f6595b1f%40googlegroups.com.

Fabien Wernli

unread,

Jan 31, 2017, 11:20:45 AM1/31/17

to Search Guard

This time it works \o/
Thanks for all your help

Reply all

Reply to author

Forward