Hi @gravufo,

Great! Glad to hear it! Please post back if you find anything else.

I also recommend that you switch to the Inedo Hub in the future. We are in the process of deprecating our traditional installer. The Inedo Hub has the ability to update an installation previously installed with the traditional installer and the Inedo Hub now supports offline installations as well, if you need that functionality.

Thanks,
Rich

Hi @gravufo,

Would you be able to rerun the database scripts on your database? You will just need to run the Run inedosql to update the database step of our manual install guide. Can you see if this fixes your issue?

Thanks,
Rich

Hi @nuno-guerreiro-rosa_9280,

We have finally been able to recreate this issue in our sandbox. We are currently looking into a fix, but we expect to have one in the next version of ProGet, 5.3.10. This looks to be an issue with the mono framework. We use mono runtime in our Docker images for ProGet. We are also going to be releasing a .Net Core based technical preview of ProGet Docker in version 5.3.10. This will be in addition to our standard mono based version. Our internal testing is going very well and it looks to have removed a lot of the gotchas that mono has.

Thanks,
Rich

Hi @mcascone ,

We have fixed the issue and the published date will now update when the package is overwritten. This will be released in ProGet 5.3.9 which is due out this Friday Augst 14, 2020.

Thanks,
Rich

Hi @viceice,

Thanks for the clarification on your environment! I see what is going on now. I have created a ticket, PG-1809, to track the fix for this. We expect this to be released in ProGet 5.3.11 which we are expecting to be released in September 11, 2020. Basically in that instance, we are not respecting the values within the X-Forwarded-* headers. I'll let you know if anything changes on the timeline.

Thanks,
Rich

Hi @markus4830,

I'm definitely sorry about this. The change was made to help to aide in improvements to other areas of the system related to NuGet. Unfortunately, it looks like it affected the NuGet API. Expect a more permanent solution in the near future.

Thanks,
Rich

Hi @viceice,

That error is safe to ignore. It is currently a known bug and we are looking to fix that in an upcoming version of ProGet. The ticket tracking the fix for the log message is PG-1841.

Long story short, the ProGet service correctly detected that the product wasn't activated, and then logged that message. But it was doing it every time it accessed license information, which is on every connector health check, replication run, etc.
Activation happens automatically as soon as someone visits the Web application, and re-activation is required after upgrading certain versions.

Thanks,
Rich

Hi @harald-somnes-hanssen_2204,

The fix is scheduled for release in ProGet 5.3.16 which is due out on Friday. I'll reply back if anything changes.

Thanks,
Rich

Hi @tkolb_7784,

If you are hosting on a windows machine, the easiest solution right now is to migrate your server to use IIS and then add an SSL binding to your site. If you do not want to purchase a new certificate and the self-signed certificate is too much work, you can use Let's Encrypt and configure it via winacme.

If you do not want to use IIS, then you will need to use a reverse proxy to handle SSL connections. Any reverse proxy can be used and a pretty simple one to configure is stunnel. Most reverse proxies can also be used with Let's Encrypt.

If you are hosting via Linux (Docker), then you will need to use a reverse proxy to handle SSL connections. We have a documentation page for different Linux-based reverse proxies including an example for setting up NGINX. These reverse proxies also support Let's Encrypt also.

Please let me know if you have any questions.

Thanks,
Rich

Hi @barnaby-williams_8489,

Please see our documentation for cloud storage. There is a subsection for migrating a feed to cloud storage.

Thanks,
Rich

Hi @michal-roszak_0767,

I took a look at the code and the only line that could throw that error during the configuration is when it goes to download the federation metadata. Typically that error message indicates the ProGet server was shutting down will it was attempting to create a new HttpClient. I would try to reboot your ProGet server and see if it happens again.

Thanks,
Rich

Hi @Nils-Nilsson,

Glad to hear it's working for you! Also, thanks for the feedback on adding that to our docs, I'll work on getting that added soon.

Thanks,
Rich

Hi @udi-moshe_0021,

If you could please share all of the output, that would be helpful.

Thanks,
Rich

Hi @Nils-Nilsson,

At this point, I would suggest using our debug endpoint to see what the SAML response sent to us is and how we interpret it. You can do that by change the callback URL in your SAML provider to https://«PROGET_HOST»/saml-acs-callback-debug then attempt to login to ProGet using your SAML provider. You will then be redirected to a debug page that shows you the SAML details. That should be able to help you identify what is missing. If you need help, you can email us the contents of that page to support@inedo.com with a subject of [QA-2681] SAML and then reply to this letting us know you sent it.

Thanks,
Rich

Hi @udi-moshe_0021,

Thanks for the information and I appreciate the background. Did you try the method of referencing the certificate by it's thumbprint while using the Windows Store? The only logs we have is if you run the IWS in a console instead of as a Windows service. This will allow you to see the console output from .NET when we register the certificate. You can do that with the following command:

"C:\Program Files\ProGet\Service\ProGet.Service.exe" run webonly

Based on the error you originally provided though, that error almost always means that the Service Account doesn't have access to the certificate and it's private keys. Can you tell me a little more about your setup?

1. Are you binding only the port (Urls="http://*:80;https://*:443" in the config file ) or did you configure it for port sharing?
2. Is there a proxy in front of your site?
3. What account are you running your IWS service as, Network Service, local domain account, etc....?

Thanks,
Rich

Hi @udi-moshe_0021,

Certificate configurations can be a bit tricky to resolve due to the many different types of certificates that can be generated. To start, are you using the integrated web server or IIS on your installation?

The first thing to check is that your certificate with either IWS or IIS is making sure that your certificate contains the private keys. That is required for any certificate problems. If you are on Windows, the easiest way to use the certificate is using the Windows Certificate Store. Once you have imported it into your certificate store, check that your have permissions to manage private keys.

If you are still haveing issues getting teh certificate to load, then you may want to switch to referencing your certificate using it's thumbprint.

If you are trying to link directly to the certificate instead of using the windows certificate store, you will still need to make sure the certificate has the private keys included, but you may need to convert your certificate to a ".pfx" or a ".pem" file. Although we have had success using a .crt and a .key file, we find it can be a bit finicky in comparison. Although I don't have the exact command to run, you should be able to easily find openssl commands to convert the certificate. Similar to this command:

openssl pkcs12 -export -out output.pfx -inkey private_key.key -in certificate.crt

It's hard to give an exact command since I don't know all the details on your certificate and key files. We also have some notes on how to convert PKI generated certificates to a ".pem" file in our in our HTTPS Binding to a Port (Advanced) docs. Just scroll down to the Update Configuration file and look at the commands we have there to convert the certificate.

This should be a pretty good starting point for this, but please let me know what works and what doesn't and then we can go from there.

Thanks,
Rich

Hi @Nils-Nilsson,

In order to use SAML with Active Directory, you will need to make sure your SAML claims are returning a Subject's NameID that matches the samAccountName in Active Directory excluding the domain suffix. Then if it finds that username in Active Directory, it will use it's permissions. If it does not find it, it will then create a user in the Built-In User Directory.

The Subject's NameID is a bit confusing because it looks like each service uses a different term for this. For example, EntraID's (Azure AD) SAML claims name it nameidentifier. Really it is whatever claim value is set in the SAML envelope under saml2p:Response/saml2:Assertion/saml2:Subject/saml2:NameID.

As for the callback URL; it is specified in the configuration wizard when setting up EntraID (Azure AD) and PingID, but not for other SAML providers. It also looks like this got removed from our documentation page, which I'll add back now. The callback URL should be https://«PROGET_HOST»/saml-acs-callback .

@dan-brown_0128,

The best way to handle this is to use the expiration feature on API keys or using a separate script (PowerShell, Shell, etc...) in a Scheduled Task or CRON Job to check your SAML or AD provider for access and then use our API to disable API keys. Although I have never set this up, I know many SAML providers offer Webhook subscriptions for when access is removed. That could be another option for disabling API keys in ProGet.

Thanks,
Rich

Hi @pooyan-zamanian_1706,

Sure thing! ProGet 2024.33 is scheduled to release on April 18th. If you need something earlier, we can create a pre-release build as soon as the fix is ready (it's currently going through testing at the moment).

Thanks,
Rich

Hi @pooyan-zamanian_1706,

I was able to recreate this issue and have created a new ticket, PG-2946, to track the fix. This should be released in the next maintenance release of ProGet 2024.33. If any thing changes, I will let you know.

Thanks,
Rich

Hi @pooyan-zamanian_1706,

Thanks for the additional information. This will take me a bit of time to work through. I should have an update for you tomorrow.

Thanks,
Rich