No. I get it after I’ve configured the watch, while I’m still connected during that session. I have the watch set to execute every 10m, and I’m getting it about every 10m, so my assumption is that they’re connected, especially since it goes away when I disable the watch.
How do I manually execute a watch? Will this allow me to see what’s being returned by Elasticsearch, for troubleshooting purposes?
What log settings do you need me to enable to get the correct information?
We use ADFS as our primary authentication. With the sole exception of this error, we’re not receiving any regular errors. LDAP is configured as a secondary authentication, so that users are able to authenticate directly to Elasticsearch to execute queries, etc. with the same permissions as they have when using the Kibana UI. Since we’re using EKS, we follow best practice and mount all secrets as environment variables in the pods. All authentication (ADFS & LDAP) is working as expected, with the exception of this issue, so passwords should be correct.
My sg_config.yml is:
---
_sg_meta:
type: 'config'
config_version: 2
sg_config:
dynamic:
auth_failure_listeners: {}
disable_rest_auth: false
disable_intertransport_auth: false
do_not_fail_on_forbidden: true
do_not_fail_on_forbidden_empty: false
filtered_alias_mode: 'warn'
hosts_resolver_mode: 'ip-only'
multi_rolespan_enabled: true
respect_request_indices_options: false
license: '${env.SG_LICENSE}'
http:
anonymous_auth_enabled: false
xff:
enabled: true
internalProxies: '.*' # Trust all internl proxies, regex pattern.
remoteIpHeader: 'X-Forwarded-For'
kibana:
multitenancy_enabled: true
server_username: 'kibanaserver'
index: '.kibana'
rbac_enabled: false
authc:
basic_internal_auth_domain:
http_enabled: true
transport_enabled: true
order: 0
http_authenticator:
challenge: false # true for ldap/basic auth
type: 'basic'
config: {}
authentication_backend:
type: 'intern'
config: {}
description: 'Internal Users'
skip_users: []
adfs_ldap:
http_enabled: true
transport_enabled: true
order: 1
http_authenticator:
challenge: false # true for ldap/basic auth
type: 'basic'
config: {}
authentication_backend:
type: 'ldap'
config:
enable_ssl: true
enable_start_tls: false
enable_ssl_client_auth: false
verify_hostnames: false
pemtrustedcas_filepath: 'certs/app/ca_bundle.pem'
hosts:
- '${env.SG_LDAP_HOST}'
bind_dn: '${env.SG_LDAP_BIND_DN}'
password: '${env.SG_LDAP_BIND_DN_PASSWD}'
users:
athene:
base: '${env.SG_LDAP_USER_BASE}'
search: '(sAMAccountName={0})'
username_attribute: 'cn'
description: 'LDAP Authentication'
skip_users: []
adfs_saml:
http_enabled: true
order: 2
http_authenticator:
type: 'com.floragunn.dlic.auth.http.saml.HTTPSamlAuthenticator' # Was: 'saml'
# type: 'saml'
challenge: true # false for ldap/basic auth
config:
idp:
metadata_url: '${env.SG_SAML_METADATA_URL}'
entity_id: '${env.SG_SAML_IDP_ENTITY_ID}'
enable_ssl: true
verify_hostnames: false
# verify_hostnames: true
pemtrustedcas_filepath: 'certs/host/ca-bundle.crt'
sp:
entity_id: '${env.SG_SAML_SP_ENTITY_ID}'
roles_key: 'Role'
# roles_key: 'http://schemas.microsoft.com/ws/2008/06/identity/claims/role'
# roles_key: 'role'
exchange_key: '${env.SG_SAML_EXCHANGE_KEY}'
kibana_url: '${env.KIBANA_URL}'
authentication_backend:
type: 'noop'
authz:
adfs_ldap_roles:
http_enabled: true
transport_enabled: true
authorization_backend:
type: 'ldap'
config:
enable_ssl: true
enable_start_tls: false
enable_ssl_client_auth: false
verify_hostnames: false
pemtrustedcas_filepath: '/usr/share/elasticsearch/config/certs/app/ca_bundle.pem'
hosts:
- '${env.SG_LDAP_HOST}'
bind_dn: '${env.SG_LDAP_BIND_DN}'
password: '${env.SG_LDAP_BIND_DN_PASSWD}'
roles:
athene:
base: '${env.SG_LDAP_ROLE_BASE}'
search: '(member={1})'
userroleattribute: null
userrolename: 'memberOf'
rolename: 'cn'
resolve_nested_roles: true
users:
athene:
base: '${env.SG_LDAP_USER_BASE}'
search: '(sAMAccountName={0})'
username_attribute: 'cn'
description: 'LDAP Roles'
skipped_users: []
We loaded initial roles per SG config, with the following additional role defined:
---
_sg_meta:
type: 'roles'
config_version: 2
TLD_BASIC_ACCESS:
reserved: false
hidden: false
description: 'Grant RO access to indices for users.'
cluster_permissions:
- 'SGS_CLUSTER_COMPOSITE_OPS_RO'
index_permissions:
- index_patterns:
- '/^(?!sg7-)\S*$/'
fls: []
masked_fields: []
allowed_actions:
- 'SGS_READ'
tenant_permissions: []
static: false
This is the role-mapping we loaded:
---
TLD_BASIC_ACCESS:
reserved: false
hidden: false
backend_roles:
- '${env.SG_LDAP_IT_USERS}'
- '${env.SG_LDAP_NONIT_USERS}'
- '${env.SG_SAML_USERS}'
hosts: []
users: []
and_backend_roles: []
description: 'Grant RO access to indices for users.'
SGS_LOGSTASH:
reserved: false
hidden: false
backend_roles:
- 'logstash'
hosts: []
users: []
and_backend_roles: []
SGS_ALL_ACCESS:
reserved: true
hidden: false
backend_roles:
- 'admin'
- '${env.SG_LDAP_ADMINS}'
- '${env.SG_SAML_ADMINS}'
hosts: []
users: []
and_backend_roles: []
description: 'Map admin users to SGS_ALL_ACCESS.'
SGS_KIBANA_SERVER:
reserved: true
hidden: false
backend_roles: []
hosts: []
users:
- 'kibanaserver'
and_backend_roles: []
SGS_MANAGE_SNAPSHOTS:
reserved: true
hidden: false
backend_roles:
- 'snapshotrestore'
hosts: []
users: []
and_backend_roles: []
_sg_meta:
type: 'rolesmapping'
config_version: 2
SGS_OWN_INDEX:
reserved: false
hidden: false
backend_roles: []
hosts: []
users:
- '*'
and_backend_roles: []
description: 'Allow full access to an index named like the username'
SGS_KIBANA_USER:
reserved: false
hidden: false
backend_roles:
- 'kibanauser'
- '${env.SG_LDAP_IT_USERS}'
- '${env.SG_LDAP_NONIT_USERS}'
- '${env.SG_SAML_USERS}'
hosts: []
users: []
and_backend_roles: []
description: 'Grant basic access to Kibana.'
SGS_READALL:
reserved: true
hidden: false
backend_roles:
- 'readall'
hosts: []
users: []
and_backend_roles: []
description: 'Grant read-only permission to all indices.'
I’ve created a few additional roles/mappings since then (I probably need to pull a new copy of everything for backup, in fact), but again, all these are working.
What I do not see defined, when I look at defined roles in the UI (including system roles) are the SG_USER or SG_ADMIN roles. Is this something I need to create?
Update
I just checked the 49.0.0 initial config files and don’t see the SG_USER or SG_ADMIN roles defined in them, either.