Re: AxiosError: Error getting the authorization token

989 views
Skip to first unread message
Message has been deleted

Antonio Kim (Wazuh)

unread,
Nov 23, 2023, 5:47:24 AM11/23/23
to Wazuh | Mailing List
Hi Леонид Ильин
Thanks for using Wazuh.

Based on the provided configuration, it seems that you have correctly set up the OpenSearch authorization using Windows AD.

This could be due to the character encoding or formatting issue in the configuration. To troubleshoot this problem, you can try the following steps:

  1. Ensure that the character encoding of the username is correctly configured in the LDAP settings. It should match the encoding used for the user 'Иванов_ИИ'.
  2. Check if there are any special characters or spaces in the username that might be causing the authorization failure. You can try using the username in a different format or escaping special characters.
  3. Verify that the LDAP server is properly configured to handle usernames with non-Latin characters. It's possible that the LDAP server is not configured to support the specific character set used by 'Иванов_ИИ'.
You can follow this documentation: https://documentation.wazuh.com/current/user-manual/user-administration/ldap.html

If the issue persists, please let me know and we can keep researching it until we find a solution.

Antonio



On Thursday, November 23, 2023 at 9:40:33 AM UTC+1 Леонид Ильин wrote:
Hello everyone. I have deployed a wazuh cluster on 6 machines. I would like to set up authorization using Windows AD. I have configured the OpenSearch configuration according to the documentation. Here is my config

```
root@wazuh-indexer01:/# cat /etc/wazuh-indexer/opensearch-security/config.yml
_meta:
  type: "config"
  config_version: 2

config:
  dynamic:
    http:
      anonymous_auth_enabled: false
      xff:
        enabled: false
        internalProxies: '192\.168\.0\.10|192\.168\.0\.11' # regex pattern
    authc:
      basic_internal_auth_domain:
        description: "Authenticate via HTTP Basic against internal users database"
        http_enabled: true
        transport_enabled: true
        order: 4
        http_authenticator:
          type: basic
          challenge: true
        authentication_backend:
          type: intern
      ldap:
        description: "Authenticate via LDAP or Active Directory"
        http_enabled: true
        transport_enabled: true
        order: 5
        http_authenticator:
          type: basic
          challenge: true
        authentication_backend:
          type: ldap
          config:
            hosts:
            - aebank.lan:389
            bind_dn: "cn=wazuh,cn=Users,dc=my,dc=dom"
            password: "********"
            userbase: 'dc=my,dc=dom'
            usersearch: '(sAMAccountName={0})'
            username_attribute: null
    authz:
      roles_from_myldap:
        description: "Authorize via LDAP or Active Directory"
        http_enabled: true
        transport_enabled: true
        authorization_backend:
          type: ldap
          config:
            hosts:
            - aebank.lan:389
            bind_dn: "cn=wazuh,cn=Users,dc=my,dc=dom"
            password: "********"
            rolebase: 'ou=normalOU,dc=my,dc=dom'
            rolesearch: '(member={0})'
            userroleattribute: null
            userrolename: disabled
            rolename: 'dn'
            resolve_nested_roles: true
            userbase: 'dc=my,dc=dom'
            usersearch: '(uniqueMember={0})'
            skip_users:
      roles_from_another_ldap:
        description: "Authorize via another Active Directory"
        http_enabled: false
        transport_enabled: false
        authorization_backend:
          type: ldap
```

## Default roles mapping
```roles_mapping.yaml
all_access:
  reserved: false
  backend_roles:
  - "admin"
  - "CN=Admins,OU=normalOU,DC=my,DC=dom"
  - "*"
  description: "Maps admin to all_access"

own_index:
  reserved: false
  users:
  - "*"
  description: "Allow full access to an index named like the username"

logstash:
  reserved: false
  backend_roles:
  - "logstash"

readall:
  reserved: false
  backend_roles:
  - "readall"

manage_snapshots:
  reserved: false
  hidden: false
  backend_roles:
  - "snapshotrestore"

kibana_server:
  reserved: true
  users:
  - "kibanaserver"

kibana_user:
  reserved: false
  backend_roles:
  - "kibanauser"

  # Wazuh monitoring and statistics index permissions
manage_wazuh_index:
  reserved: false
  users:
  - "kibanaserver"
```

There are users with Russian and Latin names in this OU. The user ``ldap`` and ``wazuh`` are being authorized. But ```Иванов_ИИ``` it does not pass. I'm asking for help, I haven't been able to solve this problem for several months. 


Message has been deleted

Antonio Kim (Wazuh)

unread,
Nov 24, 2023, 4:20:10 AM11/24/23
to Wazuh | Mailing List
Hi Леонид Ильин,

Are those authorized users able to log in successfully?

Antonio
On Friday, November 24, 2023 at 1:47:41 AM UTC+1 Леонид Ильин wrote:
Thanks a lot for the answer. Are there any other configuration files besides the ones I have already configured? All our hosts are connected to our AD domain and they are authorized with the following usernames
четверг, 23 ноября 2023 г. в 19:47:24 UTC+9, Antonio Kim (Wazuh):

Antonio Kim (Wazuh)

unread,
Nov 24, 2023, 4:21:30 AM11/24/23
to Wazuh | Mailing List
In a quick response, I would say there are no additional configurations, but I'll delve into it to investigate further.

Antonio Kim (Wazuh)

unread,
Nov 28, 2023, 3:58:25 AM11/28/23
to Wazuh | Mailing List
Hi Леонид Ильин

After some research, I could not find additional configurations.
Could you test the usernames that you could find in the list?

Antonio
Reply all
Reply to author
Forward
Message has been deleted
Message has been deleted
Message has been deleted
0 new messages