Wazuh LDAP Integration issue

[Jerome Nelson Jayaprakash]

Hello everyone,

Good day!!!

I ran into an issue during LDAP configuration in our Wazuh server. 

I had made a mistake when entering the LDAP auth data in the config file. Instead of having the usersearch as usersearch: '(sAMAccountName={0})', I let it be usersearch: '(cn={0})'.

Then, I changed it to 

" usersearch: '(sAMAccountName={0})'
  username_attribute: cn "

However, the configuration changes don't take effect. I tried restarting Wazuh-Indexer, Manager and dashboard. But I haven't had any luck.

Is there any way that the old configuration got cached?

Could someone help me with this?

Below is the snap of the backend configuration with the old attributes even after it was changed in the config file.

Thanks

[José Luis Cosentino]

Hello, Jerome


As you test the new fixed configuration, can you share how you are testing it? Can you try authenticating using an incognito/inPrivate session? Could you share a screenshot, log, or evidence that your changes are not working and the test you are running?

Regards!

[Jerome Nelson Jayaprakash]

Hello Jose,

Let me explain the scenerio.

I tried authenticating with LDAP user accounts in the wazuh dashboard, but it fails. Stating "Invalid username or password. Please try again."

And, I tried authenticating using incognito window, but it failed too.

As a newbie to Wazuh, I have a limited knowledge on troubleshooting. All I could find why the authentication fails is incorrect usersearch attribute in the config file that got cached. And the only evidence I could produce is the screenshot of Backend configuration from Security>Authentication>Authentication sequences>LDAP>View expression

Is there any other way to test this or could u please assist to get the ldap authentication logs? Hope that might give some clues on this.

Also, I have tried creating a new user account with same "cn" & "sAMACCOUNTNAME", it works. So, the issue is that the configuration changes made lately didn't take effect at the backend configuration. 

[José Luis Cosentino]

Hello, Jerome

Regarding the official documentation: Once you fixed the parameters in the config.yml, did you execute step #4? Because it is not enough to modify de config.yml. You must run the  securityadmin.sh  To load the updated information.

If so, can you share the output of that script?

Regards!

[José Luis Cosentino]

Hello, I am not sure if my previous response reached you. I will mail it again.

In reference to your symptoms, may I inquire if you—regarding the official documentation- carried out step #4?

You need to run the  securityadmin script in order for the indexer to receive the updated data as soon as you make modifications to the config.yml file and save them. So simply saving the modifications and restarting the manager is insufficient for these changes to take effect.

Please let us know if you still have problems with your configuration. We are here to help.

[Jerome Nelson Jayaprakash]

Hi Jose,

I just ran the script you suggested and the configuration got updated.

But login failed. I guess my password expired. Let me check and let you know once I reach the office.

I, now, understand how this works. Thanks for the valuable information....

[Jerome Nelson Jayaprakash]

Hi Jose,

Even after changing the usersearch, I am still facing authentication issues for the LDAP users.

Could you please help me figure out where to check next?

[José Luis Cosentino]

Ok, let me replicate an LDAP server in my internal lab to check this before coming back to you. Is this a windows server installation? or is an LDAP server in Linux?

[José Luis Cosentino]

Hello, Jerome.

I integrated Wazuh and replicated an LDAP server on my end. It is also effective.

I have my configuration file here. You will see that I removed any data that I was not utilizing for the Kerberos configuration, avoiding parts that would interfere with the user's validation.

 Kindly focus on the "Authc" and "AuthZ" sections:


--- # This is the main OpenSearch Security configuration file where authentication # and authorization is defined. # # You need to configure at least one authentication domain in the authc of this file. # An authentication domain is responsible for extracting the user credentials from # the request and for validating them against an authentication backend like Active Directory for example. # # If more than one authentication domain is configured the first one which succeeds wins. # If all authentication domains fail then the request is unauthenticated. # In this case an exception is thrown and/or the HTTP status is set to 401. # # After authentication authorization (authz) will be applied. There can be zero or more authorizers which collect # the roles from a given backend for the authenticated user. # # Both, authc and auth can be enabled/disabled separately for REST and TRANSPORT layer. Default is true for both. # http_enabled: true # transport_enabled: true # # For HTTP it is possible to allow anonymous authentication. If that is the case then the HTTP authenticators try to # find user credentials in the HTTP request. If credentials are found then the user gets regularly authenticated. # If none can be found the user will be authenticated as an "anonymous" user. This user has always the username "anonymous" # and one role named "anonymous_backendrole". # If you enable anonymous authentication all HTTP authenticators will not challenge. # # # Note: If you define more than one HTTP authenticators make sure to put non-challenging authenticators like "proxy" or "clientcert" # first and the challenging one last. # Because it's not possible to challenge a client with two different authentication methods (for example # Kerberos and Basic) only one can have the challenge flag set to true. You can cope with this situation # by using pre-authentication, e.g. sending a HTTP Basic authentication header in the request. # # Default value of the challenge flag is true. # # # HTTP # basic (challenging) # proxy (not challenging, needs xff) # kerberos (challenging) # clientcert (not challenging, needs https) # jwt (not challenging) # host (not challenging) #DEPRECATED, will be removed in a future version. # host based authentication is configurable in roles_mapping # Authc # internal # noop # ldap # Authz # ldap # noop _meta: type: "config" config_version: 2 config: dynamic: # Set filtered_alias_mode to 'disallow' to forbid more than 2 filtered aliases per index # Set filtered_alias_mode to 'warn' to allow more than 2 filtered aliases per index but warns about it (default) # Set filtered_alias_mode to 'nowarn' to allow more than 2 filtered aliases per index silently #filtered_alias_mode: warn #do_not_fail_on_forbidden: false #kibana: # Kibana multitenancy #multitenancy_enabled: true #private_tenant_enabled: true #default_tenant: "" #server_username: kibanaserver #index: '.kibana' http: anonymous_auth_enabled: false xff: enabled: false internalProxies: '192\.168\.0\.10|192\.168\.0\.11' # regex pattern #internalProxies: '.*' # trust all internal proxies, regex pattern #remoteIpHeader: 'x-forwarded-for' ###### see https://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html for regex help ###### more information about XFF https://en.wikipedia.org/wiki/X-Forwarded-For ###### and here https://tools.ietf.org/html/rfc7239 ###### and https://tomcat.apache.org/tomcat-8.0-doc/config/valve.html#Remote_IP_Valve 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: internal ldap: description: "Authenticate via LDAP or Active Directory" http_enabled: true transport_enabled: true order: 1 http_authenticator: type: basic challenge: false authentication_backend: # LDAP authentication backend (authenticate users against a LDAP or Active Directory) type: ldap config: # enable ldaps enable_ssl: false # enable start tls, enable_ssl should be false enable_start_tls: false # send client certificate enable_ssl_client_auth: false # verify ldap hostname verify_hostnames: false hosts: - 192.168.34.106:389 bind_dn: 'CN=user1,OU=TeamMKT,DC=wazuhlab,DC=com' password: 'abcABC1234*' userbase: 'DC=wazuhlab,DC=com' # Filter to search for users (currently in the whole subtree beneath userbase) # {0} is substituted with the username usersearch: '(sAMAccountName={0})' # Use this attribute from the user as username (if not set then DN is used) username_attribute: 'cn' authz: roles_from_myldap: description: "Authorize via LDAP or Active Directory" http_enabled: false transport_enabled: false authorization_backend: # LDAP authorization backend (gather roles from a LDAP or Active Directory, you have to configure the above LDAP authentication backend settings too) type: ldap config: # enable ldaps enable_ssl: false # enable start tls, enable_ssl should be false enable_start_tls: false # send client certificate enable_ssl_client_auth: false # verify ldap hostname verify_hostnames: true hosts: - 192.168.34.106:389 bind_dn: 'CN=user1,OU=TeamMKT,DC=wazuhlab,DC=com' password: 'abcABC1234*' rolebase: 'OU=TeamMKT,DC=wazuhlab,DC=com' # Filter to search for roles (currently in the whole subtree beneath rolebase) # {0} is substituted with the DN of the user # {1} is substituted with the username # {2} is substituted with an attribute value from user's directory entry, of the authenticated user. Use userroleattribute to specify the name of the attribute rolesearch: '(member={0})' # Specify the name of the attribute which value should be substituted with {2} above userroleattribute: null # Roles as an attribute of the user entry userrolename: 'memberOf' #userrolename: memberOf # The attribute in a role entry containing the name of that role, Default is "name". # Can also be "dn" to use the full DN as rolename. rolename: 'cn' # Resolve nested roles transitive (roles which are members of other roles and so on ...) resolve_nested_roles: false userbase: 'DC=wazuhlab,DC=com' # Filter to search for users (currently in the whole subtree beneath userbase) # {0} is substituted with the username usersearch: '(uid={0})' username_attribute: 'sAMAccountName' rolesearch_enabled: true # Skip users matching a user name, a wildcard or a regex pattern #skip_users:


Let me know if you are still having issues besides this information.


Regards!

[José Luis Cosentino]

Jerome, I apologize for the previous format. I'm attaching the file keeping the correct format.

[Jerome Nelson Jayaprakash]

Hi Jose,

I tried this configuration. but it didn't work for me. 

[José Luis Cosentino]

Hi, Jerome

Can you explain in detail what are you trying to achieve exactly? Also, could you share screenshots to show the errors, or maybe in what step of LDAP integration this didn´t work?