Am 12.07.2017 um 16:39 schrieb Brian Sanders <brian.sanders@gmail.com>:
I'll have to try reinstalling, perhaps I'll upgrade to the most current versions of plugins as well since this isn't live and there are new versions.
From your suggested settings in kibana.yml
1) what is searchguard.cookie.password I haven't seen mention of that before
I have the other settings, and some of those are defaults so I omitted them. I will specificaly add them and see if this makes much difference before trying to re-install.
On Wednesday, July 12, 2017 at 10:04:28 AM UTC-4, Search Guard wrote:
I verified that the configuration i sent was is working locally for me.
I suggest to reinstall Kibana and the SG Kibana plugin https://github.com/floragunncom/search-guard-kibana-plugin/releases/download/v5.4.2-3/searchguard-kibana-5.4.2-3.zip
The relevant config in kibana.yml (maybe you miss that) looks like:
elasticsearch.requestHeadersWhitelist: ["sg_tenant", "x-authenticated-user", "authorization", "x-forwarded-for", "x-forwarded-server", "x-forwarded-by", "x-proxy-user", "x-proxy-roles"]
searchguard.multitenancy.enabled: true
searchguard.multitenancy.show_roles: true
searchguard.multitenancy.enable_filter: true
searchguard.multitenancy.tenants.enable_global: true
searchguard.multitenancy.tenants.enable_private: true
searchguard.cookie.password: "<long secure string>"
elasticsearch.username: "kibanaserver"
elasticsearch.password: "kibanaserver"
see https://github.com/floragunncom/search-guard-docs/blob/master/multitenancy.md#kibana-plugin-configuration
On Wednesday, 12 July 2017 15:34:52 UTC+2, Brian Sanders wrote:
This is a configuration I have tried previously, but I tried again this morning before logging in to anything to document the exact order of tests and errors seen.
When I first log in, I do see the log message that it can not authenticate the user with ad 0 (the internal database) and it says it says it is going to the next (eg "try next") However after an extended period the attempted login just shows
{"statusCode":500,"error":"Internal Server Error","message":"An internal server error occurred"}
After that shows up, I simply reselect my URL and press enter again, which this time loads Kibana with out any further prompting for user input. I can perform searches on my data an things appear normal. If I select tenants tab, and change to another tenant, I receive the same:
{"statusCode":500,"error":"Internal Server Error","message":"An internal server error occurred"}
This time pressing enter to reload the page eventually brings me back to the Search Guard login screen. After providing my ldap credentials, I am finally authentiacted and put into Kibana as the tenant. Now I can switch between the 2 tenants just fine... but if I select yet another tenant it takes a long time and eventually puts me at the Search Guard login website, at least it didn't 500 error this time.
So it would seem that first login does this, as well as having issues with switching to a tenant for the first time as well. I am using FreeIPA as an ldap backend, which is a fairly popular user management group of packages, but as far as this is concerned, it is simply authing against the LDAP portion which clearly CAN work. It just doesn't seem to work on the first try.
On Tuesday, July 11, 2017 at 4:01:37 PM UTC-4, Search Guard wrote:
can you try this?
searchguard:
dynamic:
kibana:
multitenancy_enabled: true
server_username: "kibanaserver"
index: '.kibana'
http:
anonymous_auth_enabled: false
xff:
enabled: false
remoteIpHeader: 'x-forwarded-for'
proxiesHeader: 'x-forwarded-by'
authc:
basic_internal_auth_domain:
enabled: true
order: 0
http_authenticator:
type: basic
challenge: false
authentication_backend:
type: intern
ldap:
enabled: true
order: 1
http_authenticator:
type: basic
challenge: false
authentication_backend:
config:
enable_ssl: false
enable_start_tls: true
enable_ssl_client_auth: false
verify_hostnames: false
hosts:
- ipa1.example.com:389
bind_dn: 'uid=admin,cn=users,cn=accounts,dc=example,dc=com'
password: 'FAKEPASS'
userbase: 'cn=users,cn=accounts,dc=example,dc=com'
usersearch: '(uid={0})'
username_attribute: uid
#only valid for authz (not authc)
#skip_users:
# - kibanaserver
# - logstash
(more complete example here https://gist.github.com/floragunncom/fdad5c8f1cab838962842d590c408538\)
On Monday, 10 July 2017 21:56:25 UTC+2, Brian Sanders wrote:
Seems I didn't include the Search Guard version: search-guard-5:5.4.2-12
On Monday, July 10, 2017 at 3:55:25 PM UTC-4, Brian Sanders wrote:
Sorry I just saw this question, I never had the issue with the local only accounts. I didn't test that extensively as I was looking to test the LDAP, but it seemed that it worked just fine.
We are running the current versions:
ES: 5.4.2
kibana-multitenancy-5.4-3
authbackend-ldap-5.0-7
And after looking these up it would appear there is now a 5.5 version of elasticsearch. This being in dev, I can always attempt to upgrade, but these were all the latest available versions as of sometime last week when I was starting my build.
On Monday, July 10, 2017 at 1:51:24 PM UTC-4, Search Guard wrote:
Which ES/SG/LDAP/MT versions are you using?
Does it work without LDAP (internal users only)?
> Am 10.07.2017 um 16:56 schrieb Brian Sanders <brian....@gmail.com>:
>
> I am testing out the LDAP authentication module with Kibana multi tenancy to see if this will fit our needs, and I am having some strange login issues. I believe I have configured it as described in the example documentation, but the FIRST time I attempt to log in I always end up at the 500 internal server error. If I attempt to log in a few more times, eventually it works and seems to keep working for a bit. I have also logged in and then seen this issue when switching tenants. After logging back in a second time everything works including switching.
>
> I don't really know how to proceed troubleshooting this, but I can't demo this to anyone and expect them to want me to take this live to production if LDAP is flaky.
>
> I am still using the basic_internal_auth, since I don't want to add a kibanaserver or logstash user to my LDAP directory, and would prefer those just be in the local database. Authz is being done by mapping users to rolls, which does work once I am logged in.
>
> Here is the relevant section from my sg_config.yml
>
>
> searchguard:
> dynamic:
> kibana:
> multitenancy_enabled: true
> server_username: "kibanaserver"
> index: '.kibana'
> http:
> anonymous_auth_enabled: false
> xff:
> enabled: false
> remoteIpHeader: 'x-forwarded-for'
> proxiesHeader: 'x-forwarded-by'
> authc:
> basic_internal_auth_domain:
> enabled: true
> order: 4
> http_authenticator:
> type: basic
> challenge: false
> authentication_backend:
> type: intern
> ldap:
> enabled: true
> order: 1
> http_authenticator:
> type: basic
> challenge: true
> authentication_backend:
> config:
> enable_ssl: false
> enable_start_tls: true
> enable_ssl_client_auth: false
> verify_hostnames: false
> hosts:
> - ipa1.example.com:389
> bind_dn: 'uid=admin,cn=users,cn=accounts,dc=example,dc=com'
> password: 'FAKEPASS'
> userbase: 'cn=users,cn=accounts,dc=example,dc=com'
> usersearch: '(uid={0})'
> username_attribute: uid
> skip_users:
> - kibanaserver
> - logstash
>
>
>
>
> --
> 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/9eba0f76-cbbe-4ea7-85f2-a2a90d750f26%40googlegroups.com\.
> For more options, visit https://groups.google.com/d/optout\.
--
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+unsubscribe@googlegroups.com.
To post to this group, send email to search-guard@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/d487734a-1beb-4a13-93d1-4686a32fc203%40googlegroups.com\.
For more options, visit https://groups.google.com/d/optout\.