npm does not support Windows Auth. Unfortunately IIS/ASP.NET does not allow for some things to be Anon, some things to be Windows -- the whole site is one or the other. Best workaround is to create two IIsSites on the site server with different ports. You can point both of them to the same application directory. Note this does not require a separate license because it's considered the same instance, and largely a workaround for the authentication problem.

We don't have a tutorial or guide on creating one, but it basically just involves making a UserDirectory class, and then implementing the methods. Note that in BuildMaster 4.9, we changed the interfaces a bit to be more inline with ProGet. You can use a disassembly tool to see how the current ones work, or request the source.

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