Hello.

I've seen this error a couple of times and while it's a very generic error that can mean that different things may be happening, I found that it usually is related to the permissions the user querying the AD has.

Are you having issues only with search? 

Check if you can do the get method to retrieve just one user and we'll see what we get from there. Sometimes it may be very specific to an object in AD or attribute. So, I'd suggest also checking the permissions the user you've specified for the connection has on the AD, if you have the chance of trying with an administrator, then you'll at least be able to remove the permission possibility quickly.

Ok so after some poking around I think made a discovery deep in the archives of the internet:

Is there a .Net method to escape charactes in a LDPA path? (microsoft.com)

It appears that the forward slash in the LDAP: domain path can cause issues for some users. It doesn't appear to cause issues for everyone, but it does in our case for whatever reason. Possibly because we do no specify any further containers so we end up with a path that looks like this:

LDAP://AD.DOMAIN.COM/

Perhaps it's the fact that it's trailing. Unfortunately that path is set in ActiveDirectory_BL in the TokenValidate action which populates it from whatever you have set in the ADAccessToken entity so there is no straightforward way to keep it from adding that trailing slash. I also have tried "tricking" it by attempting to escape the trailing slash by putting \\ at the end of my domain, but while it does not throw the same error it still doesn't work.

So I went ahead and made a replacement for the action which basically does a custom version of TokenValidate which sets things up in such a way it does not have that trailing slash. I am not really sure what this would look like in terms of an update to the forge component itself. I think more testing would be required to figure out under precisely what conditions the slash is causing problems. Is it only when it's trailing? I don't know.

Regardless I have my workaround for now and I would be happy to help out with figuring out an update to the forge component so future users don't need to think about it. 

Wow. Thank you so much for digging in and finding what's causing your issues.

I'm going to investigate this and see if there's something we can do directly in the component so that you don't have to make the workaround and with it make it more robust.

Looking at the ActiveDirectory_BL, seems I can just check if the container is filled in and avoid adding the training slash in that case. But I'm curious, the container field is mandatory in the backoffice. Are you saving the token any other way? Still, I'll make sure the container is not mandatory and that way if it does not exist it wont add the training slash.

Thanks.

Uploaded a new version to forge: https://www.outsystems.com/forge/component-overview/11128/active-directory-core-simplified

This should work for your case now as well. Let me know how it goes.

Oh hey @Renato Pauleta it looks like the change may have broken AD_ValidateLogin. This little snippet of code really depends on that last "/" as you can see here:

Not sure how you would like to proceed but I figured you would like to know so you can patch it.

You’re right. Thanks so much for spotting this Grayson.

I’ll fix it.

Weird, I finally added a container to the LDAP path so I would have that "/" again. It fixed AD_ValidateLogin. It re-broke AD_UserSearch... I have to figure out how to have both of these functioning at the same time lol. What is especially weird is that it seems I may be the only person to be experiencing issues that are directly related to the slash in the LDAP path. I will do a little more testing.

Even weirder, it works if I specify the whole DC as the container. So this does not work:

LDAP://ACTIVE.DIRECTORY.DOMAIN.COM/

But for whatever reason, this does:

LDAP://ACTIVE.DIRECTORY.DOMAIN.COM/DC=active,DC=directory,DC=domain,DC=com

I am properly stumped, not gonna lie. I feel like there's some really obscure mechanism at play here that I simply do not know enough about AD to figure out.

The second way is what I normally see, but it shouldn't be mandatory.

Using the second approach, you can make it less specific by choosing your container as:

DC=domain,DC=com

which would result in the following connection:

LDAP://ACTIVE.DIRECTORY.DOMAIN.COM/DC=domain,DC=com 

Still, using just the domain should work, but the code needs to be smarter on the component to check if there's indeed an "/" in the connection, otherwise it will result in not finding that "domain.LastIndexOf."

There are a few other things that will stop working as well.

I'll change the code here to make it more robust.

I have a new version ready to publish to the Forge; I just need a bit more time to make a few more tests.

On the extension side, I've added a few more validations to ensure that the domain is correct. During a few tests, I discovered that calling the DirectoryEntry method with a trailing "/" is what causes the problem; if the domain does not have it, there is no problem.

To avoid this, I've added some validations in both the library and the business logic module, removing the trailing "/" when nothing else is added to the path.

Hi Grayson.

There's a new version of the active directory library, https://www.outsystems.com/forge/component-overview/11126/active-directory-library and a new version of the simplified component, https://www.outsystems.com/forge/component-overview/11128/active-directory-core-simplified.

This should allow all levels of domain and container definitions and prevents the trailing slash issue.