Ok, thanks, feel free to open a new thread if should there be any more issues!
The warning message about the disabled enterprise features is there since 6.1.x, that’s why I asked. But it is probably hard to spot in the ES log on startup.
···
On Friday, August 31, 2018 at 5:40:09 PM UTC-4, dchan@galileo.io wrote:
That helps immensely, thanks for the confirmation.
I did not notice the Enterprise icon in the upper right corner. I think I scanned over every other part of the page, but my eyes never noticed the Enterprise icon. That makes more sense.
The message:
Can not load ‘com.floragunn.dlic.auth.http.saml.HTTPSamlAuthenticator’ because enterprise modules are disabled
did not appear because I did not have com.floragunn.dlic set to debug?
Either that, or I never noticed it.
Coincidentally, I did also upgrade from 6.3.2 to 6.4.0. It’s possible that I didn’t notice that log in 6.3.2, or the message did not appear.
It does appear, definitively, in 6.4.0, and I do have com.floragunn.dlic set to debug in the transient settings.
Capturing the HTTP traffic makes sense, but because the HTTPSamlAuthenticator was never started, I don’t think I ever saw that acs entry in the Network tab of my browser. After I enable Enterprise license, I’ll keep an eye out for the acs entry for debugging purposes. Decoding the base64 encoded XML from the IdP should yield some more information, if I run into more issues.
I’ll abandon this thread, as it stands. I think there is enough information here on how to debug, after I enable the enterprise functionality.
Thanks again,
Dan
On Friday, August 31, 2018 at 5:28:07 PM UTC-4, Jochen Kressin wrote:
Yes, it is. For an overview about the Enterprise and non-Enterprise features you can refer to the website:
In the docs the features are also marked in the upper right corner:
That would explain why you get some strange SAML errors. However, if you install SG fresh it will automatically create a trial license with all features enabled, that’s why it actually did not came to my mind that disabled enterprise features could be the cause. Sorry about that.
That also explains why enabling the debug setting for the Token logger would not yield any effect. But in my opinion the message:
Can not load ‘com.floragunn.dlic.auth.http.saml.HTTPSamlAuthenticator’ because enterprise modules are disabled
``
should appear every time you either try to change the sg_config settings or restart the cluster. Did it not appear before on your system?
To answer your question regaring other ways of debugging, you can always try to capture the HTTP traffic between Kibana/Elasticsearch/Idp manually for debugging. A bit more work, but should work in any case. The first request you should see is the post-back from the IdP to the acs endpoint:
The SAMLResponse is the base64 encoded XML from the IdP. You can just decode it and check whether the content matches your expectations. That would be the first step. If you want to also inspect the traded JWT then you need to activate the Token logger.
Hope that helps and let me know if you need further information.
On Friday, August 31, 2018 at 4:59:30 PM UTC-4, Dan Chan wrote:
After changing my authc entry to:
saml_auth_domain_google:
http_enabled: true
transport_enabled: true
order: 1
http_authenticator:
type: ‘saml’
challenge: true
config:
idp:
metadata_file: GoogleIDPMetadata-galileo.io.xml
sp:
entity_id: __SP_ENTITY_ID__searchguard/saml/acs
kibana_url: KIBANA_URL
roles_key: role
exchange_key: ‘SAML_EXCHANGE_KEY’
authentication_backend:
type: noop
After booting up Elasticsearch, I found in the logs:
[2018-08-31T20:43:15,351][ERROR][c.f.s.a.BackendRegistry ] Unable to initialize auth domain saml_auth_domain_google due to ElasticsearchException[Can not load ‘com.floragunn.dlic.auth.http.saml.HTTPSamlAuthenticator’ because enterprise modules are disabled]
org.elasticsearch.ElasticsearchException: Can not load ‘com.floragunn.dlic.auth.http.saml.HTTPSamlAuthenticator’ because enterprise modules are disabled
Is HTTPSamlAuthenticator an enterprise feature of Search Guard? Do I require a Search Guard enterprise license to use this feature?
My cluster settings are set to:
{"persistent":{},"transient":{"logger":{"com":{"floragunn":{"dlic":"debug"}}}}}
On Fri, Aug 31, 2018 at 4:20 PM, Dan Chan dc...@galileo.io wrote:
I think my question boils down to: What are the different reasons that Google SAML app could be redirecting me to https://kibana.xxx/customerror?type=samlAuthError#?_g=()? I’ve read the troubleshooting guide at https://docs.search-guard.com/latest/troubleshooting-saml, but have run out of ideas for how to proceed with the setup.
On Fri, Aug 31, 2018 at 12:29 PM dc...@galileo.io wrote:
Would it matter if https://kibana.xxx and https://elasticsearch.xxx are not accessible from the public internet? These are currently resources that reside within a private AWS VPC.
Trying to rule out any possible sources of failure.
On Friday, August 31, 2018 at 12:23:06 PM UTC-4, dc...@galileo.io wrote:
Something feels a bit off to me.
I reconfigured Elasticsearch and disabled the authc SAML configuration. I’m still receiving the same https://kibana.xxx/customerror?type=samlAuthError#?_g=() page from Kibana when attempting to SSO with Google.
Is my Kibana setup not forwarding the request to Elasticsearch properly? It feels strange to not have any logs in Elasticsearch, showing the POST request from Kibana. And receiving the same error page on the Kibana side also seems suspicious.
Thanks for the patience so far, I really appreciate the responses.
On Thursday, August 30, 2018 at 6:53:14 PM UTC-4, dc...@galileo.io wrote:
If it helps, this is the POST from Kibana.
{
“type”: “response”,
“@timestamp”: “2018-08-30T22:32:18Z”,
“tags”: ,
“pid”: 56,
“method”: “post”,
“statusCode”: 302,
“req”: {
“url”: “/searchguard/saml/acs”,
“method”: “post”,
“headers”: {
“x-forwarded-for”: “172.31.3.26”,
“x-forwarded-proto”: “https”,
“x-forwarded-port”: “443”,
“host”: “kibana.xxx”,
“x-amzn-trace-id”: “Root=1-5b887072-d2b37cf4630cf00895ef73c4”,
“content-length”: “5997”,
“cache-control”: “max-age=0”,
“origin”: “https://accounts.google.com”,
“upgrade-insecure-requests”: “1”,
“content-type”: “application/x-www-form-urlencoded”,
“user-agent”: “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36”,
“accept”: “text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,
“referer”: “https://accounts.google.com/o/saml2/initsso?idpid=#####&spid=#####&forceauthn=false”,
“accept-encoding”: “gzip, deflate, br”,
“accept-language”: “en-US,en;q=0.9”
},
“remoteAddress”: “x.x.x.x”,
“userAgent”: “x.x.x.x”,
“referer”: “https://accounts.google.com/o/saml2/initsso?idpid=#####&spid=#####&forceauthn=false”
},
“res”: {
“statusCode”: 302,
“responseTime”: 29,
“contentLength”: 9
},
“message”: “POST /searchguard/saml/acs 302 29ms - 9.0B”
}
On Thursday, August 30, 2018 at 6:35:28 PM UTC-4, dc...@galileo.io wrote:
Hi Jochen,
Okay, so I don’t know why it initially failed to boot, but took your advice in setting
logger.token.name = com.floragunn.dlic.auth.http.saml.Token
logger.token.level = debug
in log4j2.properties, and Elasticsearch boots properly.
I’m still not seeing any debug logs for Token however, when attempting to login using SAML Google SSO. I receive the SAML authentication error on https://kibana.xxx/customerror?type=samlAuthError#?_g=(), but can’t seem to find any corresponding logs in Elasticsearch.
Is there another set of logs that I can look at that might provide more information?
Thanks,
Dan
On Thursday, August 30, 2018 at 5:43:17 PM UTC-4, Jochen Kressin wrote:
Well, the error message indicates that you confused the logger name with the log level (“Unknown level constant”). Something like:
logger.token.name: error
logger.token.level: com.floragunn.dlic.auth.http.saml.Token
``
Can you check for this both in log4j2.properties and elasticsearch.yml?
On Thursday, August 30, 2018 at 5:32:01 PM UTC-4, dc...@galileo.io wrote:
Hi Jochen,
Thanks for the replies so far.
I’m seeing an error when I add the logger in log4j2 properties in my Elasticsearch cluster, along the lines of Unknown level constant [COM.FLORAGUNN.DLIC.AUTH.HTTP.SAML.TOKEN].
Is there a way to get around this, or is this error supposed to not be happening?
Thanks,
Dan
On Thursday, August 30, 2018 at 5:28:21 PM UTC-4, Jochen Kressin wrote:
I think you can only change log levels via the cluster API. You will not be able to add a new logger that way.
So you can add the logger in log4j2.properties and set it to error:
logger.token.name = com.floragunn.dlic.auth.http.saml.Token
logger.token.level = error
``
And then use the cluster API to dynamically switch on debug level when needed.
On Thursday, August 30, 2018 at 2:43:13 PM UTC-4, dc...@galileo.io wrote:
Update with a new question!
Figured out that my Kibana setup was not deploying properly, and now I am correctly forwarding requests from Kibana to Elasticsearch, using “/searchguard/saml/acs”. Also, removed the duplicate YAML key for “server.xsrf.whitelist”
New question:
I am trying to debug SAML authentication error from the SSO (https://docs.search-guard.com/latest/troubleshooting-saml)
I attempted to enable com.floragunn.dlic.auth.http.saml.Token via cluster settings, but I am receiving an error response of illegal_argument_exception
$ curl -X PUT “https://user:password@elasticsearch.xxx:443/_cluster/settings” -H ‘Content-Type: application/json’ -d’
{
“transient”: {
"[logger.token2.name](http://logger.token2.name)": "com.floragunn.dlic.auth.http.saml.Token",
"logger.token2.level": "debug"
}
}
’
{“error”:{“root_cause”:[{“type”:“remote_transport_exception”,“reason”:“[CEPj10A][1.2.3.4:9300][cluster:admin/settings/update]”}],“type”:“illegal_argument_exception”,“reason”:“Unknown level constant [COM.FLORAGUNN.DLIC.AUTH.HTTP.SAML.TOKEN].”},“status”:400}
What else can I try to debug the SAML authentication error?
Thanks for the help so far,
Dan
On Wednesday, August 29, 2018 at 3:28:49 PM UTC-4, dc...@galileo.io wrote:
For additional information, my Kibana configuration looks like such:
server.name: kibana
server.host: 0.0.0.0
server.ssl.enabled: true
server.ssl.certificate: /usr/share/kibana/config/kibana.crt.pem
server.ssl.key: /usr/share/kibana/config/kibana.key.pem
elasticsearch.url: ELASTICSEARCH_URL
elasticsearch.username: ELASTICSEARCH_USERNAME
elasticsearch.password: ELASTICSEARCH_PASSWORD
searchguard.basicauth.enabled: true
searchguard.cookie.secure: true
searchguard.cookie.name: SEARCHGUARD_COOKIE_NAME
searchguard.cookie.password: SEARCHGUARD_COOKIE_PASSWORD
searchguard.cookie.ttl: 28800000
searchguard.session.ttl: 28800000
searchguard.session.keepalive: false
searchguard.auth.type: “saml”
server.xsrf.whitelist: [“/searchguard/saml/acs”]
server.xsrf.whitelist: [“/searchguard/saml/acs”, “/searchguard/saml/logout”]
–
You received this message because you are subscribed to a topic in the Google Groups “Search Guard Community Forum” group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/search-guard/meqs61LQa9s/unsubscribe.
To unsubscribe from this group and all its topics, 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/e8e4fe9e-e5ce-4371-97b8-6a701120a1e4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.