Connection issues when configuring LDAP on Linux container

kichikawa_2913

@rhessinger disabled LDAPS per your instruction, all users testing were able to log in and navigate around without issues.

Re-enabled LDAPS using the same steps, but setting them instead of removing them, users also did not see any issues.

rhessinger

Hi @kichikawa_2913,

Did those users still experience the long initial login? Or did that go away?

Thanks,
Rich

kichikawa_2913

@rhessinger The long initial login only happened once, they have not had it since. I even had another user who never logged in attempt with LDAPS enabled again, he received the 403 message on initial attempt but was able to get in on second attempt. Neither one of his attempts were slow.

atripp

@kichikawa_2913 we've reviewed this a bit more as a team, and believe that there are a few things to consider here.

At first, it's clear you have a large, "older" Active Directory. There is a tremendous amount of customization one can do to Active Directory, and do enough of them over the years, and you end up with a "older" directory that has layer of layer of compatibility shims. You should see the crazy hacks they had to implement to get MSA accounts working...

It's important to note here is the fact that Microsoft Active Directory and .NET (Core) do not play nicely together. It took Microsoft over 10 years to get .NET Framework to work with Active Directory, and it's still really quirky. We've worked-around as many of the bugs as we can.

Microsoft is still trying to get .NET Core on Linux to work properly with Active Directory, but it's got a very long way to go as you're seeing. There are so many strange behaviors we've already had to work-around (like methods sometimes returning strings, sometimes returning byte arrays) -- and these behaviors will just come with new versions of their library.

For all we know, the crazy "2 or so minutes" to do a login query could be a parsing error in their library? Or something timing out in their network code, but not logging an error? We saw all that in .NET Framework. In any case, we can only guess because their library provides no diagnostic information for us to use.

At this point, you should open a support ticket to Microsoft. This is the only way we can see how to identify why you have a "2 minute or so" delay to run a basic login query.

The code we have is really, really simple. It follows all of Microsoft's guidelines, and it'd be super-simple for you to reproduce the exact problems for them to show them. They have some advanced monitoring tools that can detect exactly what crazy stuff is happening between the query and Active Directory.

We can't do this, because we don't have access to your directory. It's unique to your setup and
configuration, somehow.

Alternatively, just use Windows instead. It will be significantly cheaper in the long-run (I suspect we've already burned through a lifetime's worth of licensing fees diagnosing this problem). Microsoft is still years away from even having the support infrastructure to help their customers with Linux problems, so any time there's a slight problem on Microsoft's end (SQL Server, .NET Core) , it will be "DIY" -- which really means, spend a lot of your time fixing quirks on their software.

kichikawa_2913

@atripp I'm okay with the problem shifting over to Microsoft, I was just happy to help with anything that can be resolved on your end. Ultimately, we want to use SAML, but because that's only available to use with an actual Enterprise license I needed another way to get a feel on how administering permissions felt with ProGet.

I appreciate the time put into this and I'm glad I could help resolve some issues. @rhessinger has been super responsive and great to work with, thank you!

kichikawa_2913

@rhessinger do you have an ETA on an actual release for the LDAP fixes?

rhessinger

Hi @kichikawa_2913,

I just released this extension to production now. Please let me know if you don't see an official release.

Thanks,
Rich

kichikawa_2913

@rhessinger Looks like version 1.10.7 is the new version correct?

rhessinger

Hi @kichikawa_2913,

I'm sorry for not including that in my previous comment. You are correct 1.10.7 is the new version of the InedoCore extension that includes these fixes for LDAP and LDAPS on Docker.

Thanks,
Rich

kichikawa_2913

@rhessinger we upgraded to the most recent version of ProGet using the Docker image by following these steps:

Pull new image.
Stop current container.
Create new container using new image with a new name.
Make sure CA certs are present in the container and made sure OS identifies them.
Load ProGet web UI.
Attempt to log in, getting incorrect credentials error.
Attempt to log in with an admin user we manually created in the Built-In directory, same error.

To resolve this; I had to bring back the old container, log in using AD, switch to Built-In directory for auth, stop old container, start new version container, log in with admin account under Built-In directory, go to Administration, update the InedoCore extension to most recent, and enable LDAP directory.

Doesn't seem like ProGet reaches out for most recent extensions or the default installed version of the InedoCore extension should be 1.10.7. We shouldn't have this issue going forward, but I can see this being an issue later if an extension resolves issues that provide a major functionality.

Another solution I guess that could work would be to manually download all extensions, put them in a directory on the host, and mount a volume that maps to the default extensions directory. I didn't try this out though.

rhessinger

Hi @kichikawa_2913,

Sorry, this is actually expected. When we release our products, they include the extensions that were released at the time of the product release. In this case, I released this version of InedoCore after we did the product release.

If you look at our documentation for upgrading your docker image, the command includes --volumes-from=proget-old. This will auto migrate the previous volumes created from the previous version of ProGet and that will keep the updated extension (as long as the previous extensions is newer than the included extension version).

Also, in Administration -> Advanced Settings, you can change Extensions.ExtensionsPath to a mapped path and that will also do the same thing (if the version in this directory is newer than the included) and give you easier access to the extension files.

Thanks,
Rich