@rhessinger Thank you Rich - will install it once released and confirm it is fixed.

I'm seeing an error in Proget 2025.22 as shown below when attempting to set an expiry date on a vulnerability assessment override. I have tried with my user time zone set to both UTC and local time zone (UTC+8) but that doesn't seem to make a difference. Note that we're using an external Postgres 17 database in its own container. Have we missed a configuration step or is this a bug?

An error occurred in the web application: Cannot write DateTime with Kind=Unspecified to PostgreSQL type 'timestamp with time zone', only UTC is supported. Note that it's not possible to mix DateTimes with different Kinds in an array, range, or multirange. (Parameter 'value')

URL: http://blobstore.rct-global.com/vulnerabilities/assess-pgvd?pgvdVulnerabilityId=388100&assessmentId=3768
Referrer: https://blobstore.rct-global.com/vulnerabilities/assess-pgvd?pgvdVulnerabilityId=388100&assessmentId=3768
User: Phil.Sutherland@xxxx
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:148.0) Gecko/20100101 Firefox/148.0
IP Address: 10.61.100.160
Stack trace:    at Npgsql.Internal.Converters.DateTimeConverterResolver`1.Get(DateTime value, Nullable`1 expectedPgTypeId, Boolean validateOnly)
   at Npgsql.Internal.PgResolverTypeInfo.GetResolutionAsObject(Object value, Nullable`1 expectedPgTypeId)
   at Npgsql.Internal.PgTypeInfo.GetObjectResolution(Object value)
   at Npgsql.NpgsqlParameterCollection.ProcessParameters(PgSerializerOptions options, Boolean validateValues, CommandType commandType)
   at Npgsql.NpgsqlCommand.ExecuteReader(Boolean async, CommandBehavior behavior, CancellationToken cancellationToken)
   at Npgsql.NpgsqlCommand.ExecuteReader(Boolean async, CommandBehavior behavior, CancellationToken cancellationToken)
   at Inedo.ProGet.Data.PostgresDatabaseContext.PostgresCommand.ExecuteReader() in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E641388\Src\src\ProGet\Data\PostgresDatabaseContext.cs:line 372
   at Inedo.Data.DatabaseContext.ExecuteInternal(String storedProcName, GenericDbParameter[] parameters, DatabaseCommandReturnType returnType)
   at Inedo.Data.DatabaseContext.ExecuteNonQuery(String storedProcName, GenericDbParameter[] parameters)
   at Inedo.Data.DatabaseContext.ExecuteScalar[TResult](String storedProcName, GenericDbParameter[] parameters, Int32 outParameterIndex)
   at Inedo.ProGet.Data.DB.Context.PgvdVulnerabilities_CreateAssessment(Nullable`1 Pgvd_Id, Nullable`1 AssessmentType_Id, Nullable`1 Assessment_Date, Nullable`1 Expiry_Date, String AssessedBy_User_Name, Nullable`1 Policy_Id, Nullable`1 Project_Id, Nullable`1 PgvdAssessment_Id) in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E641388\Src\src\ProGet\obj\Release\net8.0\linux-x64\InedoLib.Analyzers\InedoLib.Analyzers.DatabaseContextGenerator\DB.g.cs:line 3785
   at Inedo.ProGet.Data.DB.PgvdVulnerabilities_CreateAssessment(Nullable`1 Pgvd_Id, Nullable`1 AssessmentType_Id, Nullable`1 Assessment_Date, Nullable`1 Expiry_Date, String AssessedBy_User_Name, Nullable`1 Policy_Id, Nullable`1 Project_Id, Nullable`1 PgvdAssessment_Id) in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E641388\Src\src\ProGet\obj\Release\net8.0\linux-x64\InedoLib.Analyzers\InedoLib.Analyzers.DatabaseContextGenerator\DB.g.cs:line 1471
   at Inedo.ProGet.WebApplication.Pages.Vulnerabilities.AssessmentVulnerabilityPage.<>c__DisplayClass17_0.<CreateChildControls>b__5() in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E641388\Src\src\ProGet\WebApplication\Pages\Vulnerabilities\AssessmentVulnerabilityPage.cs:line 128
   at Inedo.Web.Controls.ButtonLinks.PostBackButtonLink.Inedo.Web.Controls.ISimpleEventProcessor.ProcessEventAsync(String eventName, String eventArgument)
   at Inedo.Web.PageFree.SimplePageBase.ExecutePageLifeCycleAsync()
   at Inedo.Web.PageFree.SimplePageBase.ProcessRequestAsync(AhHttpContext context)
   at Inedo.Web.AhWebMiddleware.InvokeAsync(HttpContext context)

::Web Error on 03/10/2026 17:11:15::

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,
Yes, we do have Active Directory at the back end.

Alas the LDAP filters you've specified haven't helped. I'm still seeing the same behavior - everything working except for the Load User by User Name test - user is found but group membership fails. I've run the queries by hand through ldapsearch at the shell, and confirmed by eye that they seem to be returning the correct data. I also tried removing the nested group property modifiers - the results appeared identical but the queries returned a little faster .

Unless you've other instant ideas then I think at this point I can wait until we've got a purchased license (grinding through the corporate works now) and then I'll open a support ticket. That way I can share some LDAP queries and results with you directly. We can update the thread here after that.
Cheers
phil

Thanks Rich,
I think I'd gotten my directories muddled up - not sure how else I managed to start off with a v4 connection. Once I went through the setup process again using the OpenLDAP/GenericLDAP directory format, and got all of the queries correct, then it went from broken to mostly working.

The remaining issue I have seems to be very much like that in the other current LDAP thread. I'll post some details over there.
Cheers
phil

@phil-sutherland_3118 I should add that I've configured the above as a v4/Generic LDAP connection, and we're running 2025.19 as a container on a Linux host.

I'm currently getting LDAP authentication going for our trial Proget instance. We're accessing a corporate AD server, and normally our users are identified via userPrincipalName which is a full "email address" - ie user.name@company.group. The suffix of these names is not always the same as the AD domain - as several companies have been joined together at various times.

I cannot seem to make this work with Proget. I can configure it OK, but trial logins fail. What appears to be happening from the Test User Directories log is that the entered login name is having the @company.group suffix stripped prior to creating the LDAP query. Is this expected behavior?

I've got LDAPS working successfully if I change the "User Name Property Value" field to sAMAccountName instead of userPrincipalName, so we're not stuck, but our most of our users don't remember this constructed field value so it's a bit of a nuisance to have to use it for login.

Thanks for the comprehensive response - which was very helpful.
Closing the loop, we've elected for the short term to run up a parallel aptly server to manage our existing apt snapshots, but in the longer term we'll revisit how we use snapshots at all and very likely will switch our process to use upstream provided snapshots.

We are currently evaluating Proget to possibly replace our existing Sonatype blobstore, and one of the features we currently make of is apt snapshots. The Debian feed documentation in Proget states that apt snapshots are explicitly not supported. Is this functionality on a future roadmap, or is there another way to do this within Proget that we've missed?