# Signals Watch getting "Failed to Fetch"

**URL:** https://forum.search-guard.com/t/signals-watch-getting-failed-to-fetch/2091
**Category:** Signals Alerting
**Created:** [February 10, 2021, 6:58pm UTC](https://forum.search-guard.com/t/signals-watch-getting-failed-to-fetch/2091 "2021-02-10T18:58:53Z")
**Posts on this page:** 1
**Showing post:** 3

<div class="post-metadata">

### Author: ![Doug\_Renze](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.search-guard.com/doug_renze/32/720_2.png) [@Doug\_Renze](https://forum.search-guard.com/u/Doug_Renze)
#### Post date: [February 11, 2021, 2:18pm UTC](https://forum.search-guard.com/t/signals-watch-getting-failed-to-fetch/2091/3 "2021-02-11T14:18:44Z")

</div>

> [@nils](#):
>
> When exactly do you get the “failed to fetch” error message? When trying to manually executing the watch from the Kibana plugin?

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?

> [@nils](#):
>
> For both problems, we would need more information from the Elasticsearch logs. In case of manually executing a watch, you can also check the Browser console log for more logs.

What log settings do you need me to enable to get the correct information?

> [@nils](#):
>
> Regarding the LDAP error: Can you also please post your complete `sg_config.yml` configuration? Remember to redact passwords. While redacting, please double check that LDAP passwords are correct, both in the `authc` section and the `authz` section.

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:

```yaml
---
_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: []

```

> [@nils](#):
>
> Also, how are you assigning roles to users? In the log message, the user has the roles `SG_ADMIN` and `SG_USER`. There are two ways: You can use the role mapping feature to directly map user names to roles. Alternatively, you can assign roles coming from LDAP to Search Guard roles.

We loaded initial roles per SG config, with the following additional role defined:

```yaml
---
_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:

```yaml
---
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.

---

_[View the full topic](https://forum.search-guard.com/t/signals-watch-getting-failed-to-fetch/2091)._