AD Entity Analytics - invalid Base DN

I'm aware that the Active Directory Entity Analytics is new and Technical Preview but wanted to check if its me doing something wrong and if not, perhaps it is worth raising for the developers feedback.

During configuration, it appears that the Active Directory Base DN parameter requires a Container of Users and doesn't support any other option.

In our AD, we do have that container, but it is not where we store all of our User accounts.

For example; if I configure the Integration to look at CN=users,DC=domain,DC=com if will work and pull the small amount of data in that container.

The problem is that we have our Users in OU's. We may have an OU for IT_staff, permanent_staff and contractor_staff so would want to pull data from all of those. When I add any of those, for example OU=Permanent_Staff,DC=domain,DC=com I get an error message in the Elastic Agent:

Error running incremental update
invalid base distinguished name: ou=Permanent_Staff,dc=domain,dc=com does not have cn=Users

I have tried several variations but no matter what I try, if it doesn't contain cn=users it will fail. Does this imply that there is a hard-coded requirement for the Base DN to include CN=Users in the config?

Thank you

Hey,

Does this imply that there is a hard-coded requirement for the Base DN to include CN=Users in the config?

As per this block of code, your intuition might be correct:

where
var cnUsers = &ldap.RelativeDN{Attributes: []*ldap.AttributeTypeAndValue{{Type: "CN", Value: "Users"}}}

So, the error appears when your ad_base_dn config option does not start with CN=Users.

I'm checking further to see if this is intentional.

Thank you for your reply - I'm not a developer so wouldn't have been able to find that!

I think a lot of organisations would be similar to ours and potentially have multiple areas within AD where they may need to point the Elastic Agent at so some flexibility would be valuable.

@PhilA Can you provide a complete (contextually sanitized) LDAP base for your set-up. The issue here is that LDAP is wonderfully loose in what it allows and AD documentation does not give guidance on what can be expected to be being used. If you do not want to share any information publicly, I'm happy to take this to the community slack DMs.

Hi

Hopefully this will help as a guide for how our AD looks:

example.domain.com

Base DN

DC=example,DC=domain,DC=com

Within there, we do have the default Users container, but we don't use it:

CN=Users,DC=example,DC=domain,DC=com

What we actually use is Organisational Units for group our users, examples include (I left the underscores in there as we do have some in our structure in case there would be any issues with special characters):

OU=_Permanent_Staff,DC=example,DC=domain,DC=com
OU=_Contractors,DC=example,DC=domain,DC=com
OU=IT,DC=example,DC=domain,DC=com

At this level, we would have other OUs such as:

OU=Business_Computers,DC=example,DC=domain,DC=com
OU=SiteA_Servers,DC=example,DC=domain,DC=com
OU=SiteB_Servers,DC=example,DC=domain,DC=com
etc...

Obviously with this structure, we couldn't just point Elastic at the Base DN as this would start searching OU's and CN's for valid user objects but would also find objects we wouldn't want to sync like Computers and Groups. I would therefore need to point the Elastic Agent at multiple OU's for full user sync.

Does that help? Happy to provide more details if you need more.

Phil

Thanks. That's very helpful. I will look into what we can do to accommodate that.

ISTM that it should be enough to provide an option for the type of the base root. If we default to "CN", then we would have a backwards compatible change, but you would be able to set it to "OU". Do you think that would work for you?

I notice that you have multiple OUs. Would having that expressible on the config be something that is important? This would take more thinking to sort out, but I'm happy to look into it.

Just re-emphasising that I'm not a developer so ignore me if I suggest things that are very difficult!

Would it make sense for this field to be renamed from AD Base DN to something more generic like 'AD location' or 'AD Container or Organisational Unit'?

In my mind, the Base DN refers more to the domain name; in this case it would be example.domain.com (which is what I put in in the first instance) so the user should actually know to be more specific with where they point the Agent.

For multiple entries, would it be possible to have a plus icon to add an additional line and add multiple entries? If not, my workaround would be to add the integration multiple times and each integration query a different OU in AD.

Another thing worth considering; which doesn't impact our environment but others may have a set up where they want to query multiple domains. For example, if someone had:

In this case I think it makes sense to have different integrations for each child domain but would there be any conflicts or issues in the data if the same username existed in both domains? For example, you query both domains and in each you find a user with username 'phil' and email address 'phil@example.domain.com'. There may not be any issues with this but just thought it was worth considering.

Phil

Base DN is just the term that is used and is an LDAP thing. I think the best option at the moment is to remove the restriction on the base prefix. I'll send that change now so that we can see about getting it in to 8.15.

Can you confirm that you can do a search on your directory with a query like (objectClass=user) and (objectClass=groups)?

Yes that search works and the user search returns a list of users only, computers only returns users.

Thank you for your support, I'll keep an eye out for any integration updates and test when available.

Phil

The change will be happening in the backing beat (PR is here). I'm still thinking about the option of having multiple target directories.

1 Like

We have decided not to add the multiple target directories at this stage, but please file an issue in the integrations repo to add this kind of feature so that we can track need.