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

Sorry to resurrect my old post, but I'm trying to use LDAP in ProGet and am running into the same issue. Users and groups that are in the domain of the server running ProGet are found, but users in a different domain are not.

You're right, at the moment the LDAP provider uses whatever domain it happens to be a part of. We'll put it in the roadmap, but we also offer the ability to "speed up the process" so-to-speak for our enterprise customers via our professional services. If you would be interested in this option for your organization, just send us a message using the contact form (http://inedo.com/contact).

The 1000 is a limit imposed by Active Directory presumably for performance reasons. Typically, you shouldn't ever need to be on the users page when using Integrated Security because once a user is assigned privileges via the "Assign Security Privileges" page, they automatically become a named user if there are licenses available when they visit the BuildMaster URL. We are planning an enhancement that will determine based on the assigned privileges whether the user should be approval-only or full, but for now it will default to full (if available) and downgrade to approval-only if no full user licenses are available. Once the user has become a named user, you can manually edit the type of user on the "License Key and Activation" page which allows you to select "[change]" to toggle the user between full or approval-only as needed.

That error message says "DirectoryProvider 1" which is the built-in provider. If you open up the Admin Tool located in the BuildMaster installation directory you can switch the directory provider to the LDAP one.

This can sometimes happen when the cookies are not cleared properly after an upgrade. Try flushing your browser cache and clearing your browser's cookies, then visit the BuildMaster site root, e.g. http://buildmasterinstall.corp/