Multiple base_dn Values LDAP authentication

Elastic Stack Elasticsearch
1

We had an issue regarding ldap authentication not working correctly and not identifying users. To resolve this we had to be more specific when we configured our base DN

Old:
DC=Root,DC=COMPANY,DC=com
New:
DC=Child,DC=Root,DC=COMPANY,DC=com

This is fine for now but the issue is that in the future other groups from the Root forest will need to be able to connect to our elastic instance. Is it possible to provide mutiple base_dn values? for example:

DC=Child2,DC=Root,DC=COMPANY,DC=com
DC=Child3,DC=Root,DC=COMPANY,DC=com

Thank you

2

Can you explain (in more detail) what issues you were running into without your previous setup?

We could implement multiple base DNs, but it would be very inefficient as we would need to search each base independently, and in the end it would be not much different than simply configuring multiple realms.

If you're going to have multiple DC=Child* that you need to search, then the best solution will be to get it working with the DC=Root DN, and work through whatever problems you ran into.

3

Hi Tim,

working with the DC=Root for some reason will not authenticate any of the children DCs. The error I recieve is that the user is not found in the ldap cache.
I read by default sub_tree searches are performed. So I assumed that it should be fine. On another application I setup ldap using user filters and group filters. Though these filters I applied using:
(&(bjectClass=group(|(distingiushedName=CN=GROUPNAME1,OU=Universal Groups, OU=Accounts, DC=Root,DC=COMPANY,DC=COM)(distingiushedName=CN=GROUPNAME2,OU=Universal Groups, OU=Accounts, DC=Root,DC=COMPANY,DC=COM)
When I provided the same thing user_search.filters I would get complaints at authentication that ldap would find multiple results.

Another thing is with this other application I was able to set a paging limit, this helped with searching. I don't know if elastic offers the same configuration.

Thanks

4

If you can provide specifics (by which I mean copy-and-paste your configuration and the exact error messages) then I'm happy to help work through it and get this working, but the description you've provided isn't clear enough to be able to give you any concrete advice.

A subtree search is exactly what you want.

If you have duplicate users in the tree, then that will be a problem, as we need to know which user to authenticate. We might be able to resolve that with a filter, but I would need to see the exact details.

5

Hi Tim,

for sure, please see my ldap config:

         ldap1:
           type: ldap
            order: 0
          url: "ldap://sai.co.com:3268"
          bind_dn: "CN=[AD_USER],OU=Service Accounts,OU=Accounts,DC=SAI,DC=CO,DC=com"
          bind_password: ---------
          user_search:
           base_dn: "DC=CHILD,DC=SAI,DC=CO,DC=com"
           attribute: sAMAccountName
          group_search:
           base_dn: "OU=Universal Groups,OU=Accounts,DC=SAI,DC=RBC,DC=com"
          files:
           role_mapping: "F:\\apps\\ELK\\elasticsearch\\config\\x-pack\\role_mapping.yml"
           unmapped_groups_as_roles: false
          #timeout.tcp_read: 30s
           #timeout.tcp_connect: 30s
           #timeout.ldap_search: 30s
        file1:
         type: file
         order: 1

Error message:

user [Stevenmarrocco] not found in cache for realm [ldap1], proceeding with normal authentication
6

That's not an error message, it's just perfectly normal debug logging (which is only shown because you've turned on debug logs).

What happens in the logs after that?

7

Hi Tim,

Yes I understand that it is normal debug level logging.

Sorry, the config provided works as expected. Once we change base_dn: 'DC=SAI,DC=CO,DC=com we then see the error provided.

The issue is that authentication is not being done on a sub_tree level and failing to authenticate the user on that realm.

The only option i can see right now is create a new ldap realm per sub domain

8

I really want to make this work for you, because it is intended to work, and I'm reasonably confident that we can sort out the problem but ...

Unless I'm missing something, you haven't provided an error.
The only log message you've posted is a debug message indicating that the user is not cached. That's exactly what you'd expect to see - we cache users after they're authenticated, so if you're unable to authenticate then the cache will never be populated.

The implementation of the LDAP realm most certainly does use sub_tree searches, so there's something specific to your environment that is causing whatever problem you're running into.
I'm happy to help diagnose that if you can show me an actual error message.

As a side note, why are you using the ldap realm rather than the active_directory realm?

9

You're correct. Technically. There isn't an error. We are just unable to authenticate users that are in a sub_tree domain.

We did try using active_directory realm but ran into issue. The issues being that it was trying to use the auth.username & auth.password to authenticate against the ad collection for querying. Even when we specified another user.
Thinking back to this now.. we may have mislead ourselves looking at the DEBUG level logging and considering it ERROR. I'll try again tomorrow with the active_directory realm and see if I'm correct.

In the meantime, I've created multiple ldap realms for each sub domain (we have 4). Don't know if this is a correct approach.

Another question, we have 3 nodes for our elastic cluster. Do each have to have the same configuration (aside from the minor node names/addresses)?

Thanks

10

If you can provide the logs, I'm happy to work out why that's the case. "It doesn't work" is hard to diagnose (for you, as well as us) but there's a lot of logging available that can show what's going on.

There are specific configurations that are needed for AD to make it work the way you want, but it should be possible to have it work for you (assuming you're on a recent version).

Strictly speaking, No you don't; but in practice it is better to do so.
Elasticsearch only does authentication at the edge, so the node that you connect to (via the Rest API, or Transport client) needs to have the realm configured.
For most use cases that means that all nodes need the realm, because it's common to use a rest client with node sniffing / load balancing, and you could connect to any node.

11

For sure, i can provide some logs. I can also open a ticket if that will make things work smoother.

We're using 6.2.2 currently. What specific configurations are you referring to? I can maybe look into the prior to my day tomorrow.

Awesome, thank you. There reason why I ask is I'm want to figure out the quickest way of testing my changes, instead of having to go through, make sure each node has the same config and then restart each service.

Thanks

12

It's easier to share confidential details through a ticket, so it may well be smoother.
If you mention this thread in your ticket, then your support rep can ping me if they need any addition input.

From memory, it should just work fine if you set bind_dn and bind_password, and don't disable connection pooling.
But there might be some minor detail that I don't remember right now. There's a lot of config options on the ldap and active_directory realms, and sometimes 2 settings can interact in perculiar ways.

13

Hey Tim,

Going to go ahead and open a ticket and refer to this thread. Tried AD and now I'm getting authentication failed with invalid credentials. I think I'm not enterting the url/domain correctly.

Thanks

14

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.