When you un/re-install ProGet, it will not delete the database unless you explicitly say to. If you run the service interactively (just run the ProGet.Service.exe), there is an option to reset the admin account permissions.

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

ProGet is designed for enterprise/organizational package management, and this is simply not a requirement or desired at all in those environments. So, it's highly unlikely we will add first-class support for this. Some organizations have created custom user directories for this purpose, which is possible with the SDK. Note: if you are a component company, you may want to contact us to see about partnering. We work with a handful of component vendors who use ProGet as a "back/middle-end" and then have a very simple customer-facing front-end on top of ProGet that integrates with their CRM, authentication, etc.

Ah ha, ok got it! I've identified the bug, and we will fix this in [BM-2003], shipping ASAP!

This isn't specific to ProGet at all, but HTTPS/SSL in general. It's not possible to bypass or address this from the server software (ProGet) side at all. You'll need to either trust the self-signed certificate on the client (Jenkins), install a certificate from a trusted root (server), or bypass that warning in the client (Jenkins).

It looks like the underlying error is, DirectoryServicesCOMException: A local error has occurred. It's obviously not helpful at all, but in searching for that exact text, there are so many things that it seems to be, or could be. I would suggest to search for that error and see what is relavent, and what isn't. There are so many suggestions on how to fix it, from improperly configured AD permissions to obscure 2008R2-only settings.

I would suggest to reset your admin password using the ProGet.Service.Exe, there is an option in there. And then try to set-up LDAP again.

You can either: not grant Anonymous any privileges (Anonymous does not belong to any groups so it doesn't have any by default) specifically add a Restriction to the Administrator role for Anonymous (this actually means Anonymous is restricted from performing any tasks that an Administrator could do, which is all of them)

You really shouldn't use API keys with ProGet, actually. From the docs: An API Key is used by NuGet client tools (such as nuget.exe and NuGet Package Explorer) as an authentication mechanism for publishing packages. It makes a lot of sense for the NuGet Gallery, as it's a community-run site where anyone can publish packages they own. In enterprise environments, the notion of individual package ownership doesn't quite translate, nor does the usage of API Keys. With ProGet, a principal (user or group) either has privileges to publish a package to a feed, or does not. This allows ProGet administrators to more easily control access and usage through LDAP and Groups instead of through community mechanisms like API Keys. So, if they can authenticate to the feed (using basic auth or windows integrated auth... or even an api key in the form of user:pass), and they are authorized, then the can push a package.

Only per feed, and that requires the Enterprise edition. The free edition only allows system-level privileges.

If that were to happen, then you'd need to follow the instructions here to restore it. Resetting the Default Admin Account If, due to a configuration issue, you find yourself locked out of ProGet, you can reset the built in Admin account to its default password and reset ProGet to use the built in directory by running ProGet.Service.exe and selecting the ResetAdminPassword option.

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.

You can disable the View privileges from Anonymous user, otherwise you'll have to upgrade to the Enterprise edition (a free trial is available) for more specific, feed-level privileges,

Because Chocolatey uses nuget.exe behind the scenes, you can just specify your authentication in the same manner., in the configuration file.

Admin_ManageFeeds was really intended to be more of an administrative task - not scoped to an individual feed. However, this doesn't necessarily make sense and there's no reason it needs to work this way. Apparently there was even some confusion here as that particular page does allow it to be scoped to a specific feed as you discovered. We'll change this task to be scopeable in the next maintenance release (3.4.3) and make sure the admin page is accessible.

It is supported with Active Directory, so you can use your domain credentials with npm, but since as far as I know the npm client does not send Windows authentication information when it makes requests, there is no way to have this happen automatically. It may be possible to fork npm and add this - say using ldapjs, but I'm not aware of any current projects like that.

Hi, I don't see any EventOccurrenceDetails in my database, and I am trying to troubleshoot why a package did not upload. I spied using Fiddler the HTTP request, and it seems I get back an Invalid API Key error. Has the schema changed? Are log files surfaced in the UI now?

Please note that granular, feed-based security is only available in the paid Enterprise edition. In the Express edition, privileges may only be applied to the whole system. If you would like to trial these features, you can request a trial key at https://my.inedo.com

Sounds like you basically just made that check list :) There is no "max password attempts" option as the built-in invalid credentials delay mechanism is sufficient to protect against brute-force/guess attacks. Otherwise, SSL and no anonymous is sufficient.

That sounds great, thanks a lot!