To follow up, we ended up being able to get everything working using userPrincipalName for user identity by switching to the OpenLDAP/GenericLDAP connector. The remaining issue I was seeing - unexpected failed group lookup in the "Test User Directories/Load user by user name" test - appears to have been caused by a quirk in the connector. In this particular test for this particular connector, group names are case sensitive. In the other tests for this connector, and in all the tests in the AD connector, group name case is ignored. This does not seem to have any repercussions in actual use, but it led us a merry dance for a while.

Hi Rich, thanks for the additional pointers. We will look into it some more and report back next week earliest due to some other priorities this week. Best regards, Sirko

Hi Andrey You should read carefully this Proget support LDAP auth, but not for the free edition Cdt Philippe

Thanks for the suggestion, I've filed this to be done here: https://github.com/Inedo/inedox-inedocore/issues/112

It's possible it may work (I can't verify) if you specify the port in the domain controller host value under advanced settings (i.e. enter your-dc-server:636 as the value). See the LDAP Advanced Settings documentation for info on how to find that page to configure that value. If that doesn't work, I suspect a code change is needed - it is not clear via the Microsoft documentation what the default AuthenticationType is for this call: https://github.com/Inedo/inedox-inedocore/blob/master/InedoCore/InedoExtension/UserDirectories/ADUserDirectory.cs#L268

We've narrowed down the issue. It seems that the service user that ProGet is running with cannot see all the members of the LDAP groups. This can be fixed by changing the user to one that can see all members of the LDAP groups through this process: https://inedo.com/support/kb/1077/configuring-your-inedo-product-to-run-as-a-windows-domain-account

I'm also getting the same error from ProGet 5.0.10 but reinstalling IIS is not an option. Restarting the service does not make a difference. No web.config customisations have taken place. Server: Windows Server 2016 (14393.1794) IIS: 10.0.14393.0 Authentication: Windows Authentication Windows Authentication Providers: Negotiate, NTLM [SerializationException: Type 'System.Web.HttpContext' in assembly 'System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' is not marked as serializable.] System.Web.Hosting.ApplicationManager.HostingEnvironmentShutdownInitiated(String appId, HostingEnvironment env) +0 System.Web.Hosting.HostingEnvironment.RemoveThisAppDomainFromAppManagerTableOnce() +156 System.Web.Hosting.HostingEnvironment.InitiateShutdownInternal() +266 System.Web.Hosting.HostingEnvironment.InitiateShutdown() +64 Inedo.ProGet.WebApplication.Pages.Administration.Security.UserDirectories.<>c__DisplayClass8_0.<CreateChildControls>b__2() +597 Inedo.Web.Controls.ButtonLinks.PostBackButtonLink.Inedo.Web.Controls.ISimpleAsyncPostControl.ProcessValidPostAsync() +66 Inedo.Web.PageFree.<ProcessPostAsync>d__61.MoveNext() +400 System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() +31 System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) +60 Inedo.Web.PageFree.<ProcessPostAsync>d__61.MoveNext() +839 System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() +31 System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) +60 Inedo.Web.PageFree.<ProcessRequestAsync>d__46.MoveNext() +574 System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() +31 System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) +60 System.Web.TaskAsyncHelper.EndTask(IAsyncResult ar) +64 Inedo.Web.Handlers.AsyncHandlerWrapper.EndProcessRequest(IAsyncResult result) +33 System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +393 System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step) +195 System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +128

While you are able to specify multiple domains and credentials to those domains, you would have to try it and see. It all really depends on your configuration. Fortunately you are able to create your own user directory, and you could probably just simply use code from the Active Directory (new) and modify it to suit your needs.

In order to create a feed-scoped permission, the task must be feed-scopable. Go to Tasks > Customize Tasks, and remove any attributes that aren't marked "F" for feed scopable. Then you can apply to to feeds.

Hi Travis, thank you for the additional update. I was very confused by this as well... the problem is the documentation that says if "LDAP" is enabled... it should say "if Integrated Authentication is enabled then the API key is ignored". When those docs were written, those 2 were 1 in the same. I guess the whole point of this is to never use a feed "NuGet API key" since it duplicates what the "ProGet API keys" already do in terms of authentication.

This is currently slated for ProGet 4.8-beta, which we expect to release in the next two weeks.

Ah, I see it. I use Caddy as my reverse proxy which doesn't support this feature.

There is a "multi-domain / forest" AD provider. As long as the domains have a trust to eachother, then the users from the other domain will be enumerated and it should "just work". We are considering building a new active directory provider that allows you to explicitly list the domains to query (instead of doing a trust search), but that ended up getting really complex fast, so it's on hold just for a bit...

Verified - the problem is resolved after upgrade to 4.6.1. Thanks!

You can fairly easily switch directory providers, so you could just try that and see if it works. A lot of organizations will have a dedicated ProGet test instance (note this requires a separate server license) to test upgrades and major configuration changes. For most organizations, both LDAP and the Multi-domain configuration "just work". So long as service account running the ProGet web application has the appropriate permissions to query, and the domains are set for proper trust, then users will be retreived as expected. But for some, it doesn't, and the only way to find out why is to do a detailed analysis using our code. 90% of the time it's a domain configuration problem. But there's no easy way to identify it because the AD libraries do not tell us why certain users or their groups are not returned in a query.

Yes, although this is currently extensible by extending the UserDirectory class.

Hi Christian, the information you posted had mentioned internal packages (Aeon Framework, etc), so I removed it That said, it wasn't an error message, but a JSON document that contained metadata information about packages. This is an expected response if you visit an API URL directly in your browser, and when the npm client relies on the JSON data. If you are receiving an error from the npm client, please make sure to share: the precise error message that npm client is using the precise URL that the npm client is requesting; you can get this by running Fiddler, and seeing the requests that the client makes Note that you will need to disable Windows Integrated Authentication at the IIS level, not just within ProGet.

That is just a "regular" COM+ that happens every now and then when doing anything with LDAP, so you an usually restart IIS, restart the server to fix it. Will send the code ASAP!

Hello; I believe the error is due to a bug in the LdapDirectory code, which is not properly escaping that group name that has a parenthesis in it. So, we will need to fix the bug; I've logged this as PG-602, and we can get it in the next maintence release (which is targeted for next week). Best, Steve

The privileges are cached; if you "invalidate cache" on the privileges page or restart the web application, that should fix it.