Hi Alana, Any chance of sending that C# code to me as well? We are also facing issues getting multi-domain AD working. TIA

Thanks, it works (after we updated to the latest version).

The upgrade is a coincidence, and the problem could have been triggered by something as simple as restarting the application pool; this is handled entirely by IIS (more specifically, Microsoft Negotiate). Negotiate authentication uses Kerberos (see Kerberos Explained), and this is difficult to debug. You can search for things like “windows negotiate authentication fails” to find all sorts of tips, but this article has been a good resource. In my experience, the most common reasons this doesn’t work: accessing by a different url (buildmastersv vs buildmastersv.mydomain.local) having a time difference between server and domain controller not having certain patches/windows updates NTLM is a different type of authentication, which may not be desirable.

This answer doesn't answer the question. Is there anything else to check or try?

As long as the Global Catalog can search the other forest it should work, if there is a restriction on that, then it will not find the user. By default however, it uses the Forest.GetCurrentForest() to determine which GC to query. We are now planning to make some improvements to the way authentication works as it is slowly becoming the #1 requested feature/improvement.

Thank you very much guys for pushing this feature to the last release. I've upgraded our server today, turned the option on, and it works great. Cheers.

4.0 is available for download now; we've tested it about as far as we can, the main reason it's still considered "beta" is to see how the Docker/installation process works in the wild. So, please give it a try. Depending on the requirements of non-AD LDAP, if it's easy to do, we can implement it quite soon.

That worked! Definitely a big work around. We additionally had to set the AppPool for the new site to Classic and disable Forms Auth in the bindings.

While the "switch to LDAP page" should not allow changing directories if it's not configured properly, most likely the BuildMaster server is unable to query ldap.

Sorry yes, I meant ProGet (though the implementations are actually the same :)) Anyway, the way that it's currently implemented does require the machine to be a part of the domain. We are aware that this is not ideal and will likely change the way LDAP is queried to make more settings configurable in a future version.

I can see how to add named groups, but "Domain Users", "Everyone", "Authentication Users" don't seem to be recognized by the add users window. I think we are just going to use a large organizational group that covers most everyone so true anonymous access isn't needed anymore. Thanks!

If you go to Admin->All Settings and change IntegratedAuthenticationEnabled to False and click Save, then it should use forms/basic authentication with LDAP as the user directory source. Note that if you are hosting the web site with IIS, you'll also have to enable Forms authentication and disable Windows authentication in there for the site. If you're using the integrated web server, it should just work. Once configured like this, you can supply the username and password in the url for the client. There is an example of this available if you click on the configuring Bower link visible on the page for any Bower package in ProGet. As far as I know, this is the only way to get it to work.

This depends on the setup, if you use Integrated Windows Authentication, you cannot have anonymous access to any feeds because the authentication will be required before the request even hits ProGet. However, there is an option on the "All Settings" page named "IntegratedAuthenticationEnabled" that when set to false will allow you to use the Forms-based approach using your Active Directory credentials. Another option with regard to the build server is to just copy the .nupkg files on disk to the feed's storage path, which will in turn be picked up by the indexer and added to the feed.

LDAPMultipleDomainEnabled needs to be true to see users in a different domain from the one that the server is running on. The privileges for multiple domain enabled will also be different since the domain becomes a part of the username e.g. principal@domain instead of just principal

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.

In this case, it sounds like the service account has some sort of enumeration problem with groups. This is not uncommon. As a test, i would suggestto run the ProGet webapp (either in IIS or the hosted web service) with your domain account. And of course, if you do find out specifically what caused this from the groups/permissions side of things, an update would most certainly be appreciated :)

Hi Riko Was this issue resolved for you I am facing similar issues with ldap in my company.

The exact process is detailed on the page used to switch over, but here are some troubleshooting ideas: ensure both Windows Auth & Forms Auth enabled for the website ensure Anonymous Authentication is disabled ensure there are administrator privileges granted before switching perform an iisreset on the web server if using IIS

I will copy my answer to another question "PROGET ALLOWS LOGIN ONCE USING LDAP AUTH, THEN CRASHES UNTIL IISRESET" here since i'm pretty sure they're tightly related: --- snip ----------------------------------------------------------------- Thinking about your answer, i'm pretty sure that this is not a problem with the .Net API. I guess that is tightly related to the second question, I've filed here (see "USE ACCOUNTS FROM TRUSTED DOMAIN FOR RIGHTS ASSIGNMENT"). Whenever i open a browser on machine.dev.local and go to the ProGet Server (located in dev.local - see explanation of the infrastructure in above mentioned question), I'm authenticated as company\John (which is a user of a different domain but dev.local has a trust with company.com). As long as the ProGet implementation assumes the accounts used for authentication to be members of the domain where proget is located in (and i guess that's the case!), you will get null back from the .Net API. So for scenario like mine, this would fail (principal = null): var ctx = new PrincipalContext(ContextType.Domain); var principal = UserPrincipal.FindByIdentity(ctx, @"company\John"); and this would work (principal has the expected value): var ctx = new PrincipalContext(ContextType.Domain, null, "company.com", @"AnAccountFromCompanyDomain", "TheAccountsPassword")); var principal = UserPrincipal.FindByIdentity(ctx, @"company\John"); I guess you need, you just have to make the account domain configurable for cases, it differs from the domain where ProGet is located in and let the user apply credentials fro Account- Queries in the Account- Domain and then use the example above to query and you're done. Right? ;-) So big question for me now is if and when can i expect a version that supports our scenario. As i told Karl last week, we're looking for a commercial solution to replace our Inhouse- Solution to reduce our maintenance efforts for package management tools. Unfortunately we run out of time for the decision to go with an external tool or to keep our internal stuff running. Would be great to get some info about if and if yes, when we can expect a ProGet version that fits our needs. Best Regards, Joachim --- snap -----------------------------------------------------------------

Thinking about your answer, i'm pretty sure that this is not a problem with the .Net API. I guess that is tightly related to the second question, I've filed here (see "USE ACCOUNTS FROM TRUSTED DOMAIN FOR RIGHTS ASSIGNMENT"). Whenever i open a browser on machine.dev.local and go to the ProGet Server (located in dev.local - see explanation of the infrastructure in above mentioned question), I'm authenticated as company\John (which is a user of a different domain but dev.local has a trust with company.com). As long as the ProGet implementation assumes the accounts used for authentication to be members of the domain where proget is located in (and i guess that's the case!), you will get null back from the .Net API. So for scenario like mine, this would fail (principal = null): var ctx = new PrincipalContext(ContextType.Domain); var principal = UserPrincipal.FindByIdentity(ctx, @"company\John"); and this would work (principal has the expected value): var ctx = new PrincipalContext(ContextType.Domain, null, "company.com", @"AnAccountFromCompanyDomain", "TheAccountsPassword")); var principal = UserPrincipal.FindByIdentity(ctx, @"company\John"); I guess you need, you just have to make the account domain configurable for cases, it differs from the domain where ProGet is located in and let the user apply credentials fro Account- Queries in the Account- Domain and then use the example above to query and you're done. Right? ;-) So big question for me now is if and when can i expect a version that supports our scenario. As i told Karl last week, we're looking for a commercial solution to replace our Inhouse- Solution to reduce our maintenance efforts for package management tools. Unfortunately we run out of time for the decision to go with an external tool or to keep our internal stuff running. Would be great to get some info about if and if yes, when we can expect a ProGet version that fits our needs. Best Regards, Joachim