LDAP Authorisation for one-way trusted domain

We use ProGet with LDAP integration.

We have to provide access to ProGet feeds to our customers.
We have a single domain which trusts the 6 domains from a single customer.
Domain groups in our domain are assigned privileges in ProGet.
Groups and users from the trusted domains are added to the domain groups from 3.

Accessing the server with internally works fine.

When we attempt access to a different website on the same server (only differs by port) with anonymous access, this works fine, so there are no other issues with configuration.

We cannot access any of the feeds from the customer network. We are continually presented with a login screen for credentials.

This sounds like we have a currently unsupported scenario - domains in different forests and one-way-trusts.

Any help towards a solution would be useful.

Product: ProGet
Version: 3.1.0

This scenario should already be supported.

Have you set the value of LDAPMultipleDomainEnabled to true in all settings? This will search the global catalog for users instead of the domain of the machine that ProGet is installed on. It may require that the privileges are reconfigured since it stores them in "username@domain" format instead of just "username".

If it works with the same users from one network but not another, then the issue is in your IIS configuration. These prompts are occurring before the request even hits ProGet.

If your browser is being prompted for credentials, that means a 401/WindowsAuth challenge is being sent and either the browser doesn't accept the challenge (hence the prompt), or the server doesn't accept the NTLM response and returns another 401.

This could be a lot of things. 80% of the time you can fix it by registering an SPN.

Any time I have set LDAPMultipleDomainEnabled = True, I cannot access the system afterwards and have to re-install.

@Alana - good spot.

ProGet bombs with a 500 if it's an authorisation issue not the browser login window.

I haven't tried to enter my local network credentials in the browser when accessing from the other network. Trying now... and of course that worked.

Looking hard at our current implementation (not my team so it wasn't readily available to me) and how they allowed access from the other network. They've used the filing system to secure access but I can put similar setting on my IIS.

This means I should at least be able to get past this part of the issue soon.

I'll get back to you.

Finally got the authentication issue fixed. Now for the authorisation. Currently we get:

[SecurityException: User xxx not found in directory LDAP.]
Inedo.ProGet.WebApplication.ProGetHttpModule.AuthorizeRequest(HttpApplication app) +526
System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +80
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +165

I'm assuming it's attempting to authenticate against the local AD. How can I point it towards the other 6?

That "User xxx not found in directory LDAP" error is a bit of an edge case; what it generally means is that the service user (i.e. credentials the website is running under) does not have permission to query the directory for user information. It can validate the Kerberos auth ticket, but just not query the directory.

We can now support 99% of our clients using the Network Credential Manager. Only one edge case, as discussed with Alex, is still outstanding. We will address that by customising the code in the near future.