Unable to create a PSCredential secret in platform variables

Hello jameshennessy,

Thank you for the detailed report. I understand that the PSCredential validation started failing after a server restart, that this is affecting Portal Apps using the Run As account, and that recreating the secret with different accounts and username formats has not resolved the issue.

To help determine whether the failure is occurring during Windows authentication or within PSU's credential validation process, could you please provide the following?

* The exact PSU version and build currently shown by the instance.
* How PSU is hosted: Windows Service/MSI, IIS, ZIP/Kestrel, or another method.
* The Windows Server version and database type.
* The identity currently running the PSU service or IIS Application Pool, for example LocalSystem, domain service account, or gMSA.
* Whether the PSU service identity changed recently or around the server restart.
* Whether this is a production environment and how many Apps are currently affected.

Could you also perform one PSCredential validation attempt and then check both the PSU System Log and Windows Event Viewer at the corresponding timestamp? If Windows records a failed authentication event, please share the sanitized Event ID, Logon Type, Status, SubStatus, and Failure Reason. A sanitized PSU log excerpt covering the same attempt would also be helpful.

Because this is a public forum, please sanitize all evidence before posting. Remove credentials, tokens, license keys, cookies, private keys, full connection strings, email addresses, usernames, customer data, tenant or account identifiers, internal domains, hostnames, IP addresses, and private URLs. Please do not upload unredacted HAR files, memory dumps, database backups, or complete configuration files to this public thread.

Best regards,
Ruben Tapia

Ruben you are a genius!
I have added the permission of logon as a service to the affected credential with no change in behaviour.

I then added logon as a batch job which now allows me to authenticate and add the credential in the PSUSecretStore

Exact version is 2026.2.5
Hosted on Windows Service/MSI
Windows Server version: 2025 Standard 24H2
DB Type is SQL Lite
Domain Service account is running the service
Identity has not changed since install
Production environment with 5 apps, 3 currently affected

Please see the windows event log for the failed logon,
it appears the service account tries to authenticate the credential and fails,

An account failed to log on.

Subject:
Security ID: Correct Domain\SA_PSU_Service
Account Name: SA_PSU_Service
Account Domain: Correct Domain
Logon ID: 0x20CFBBC

Logon Type: 4

Account For Which Logon Failed:
Security ID: NULL SID
Account Name: Username
Account Domain: Correct Domain

Failure Information:
Failure Reason: The user has not been granted the requested logon type at this machine.
Status: 0xC000015B
Sub Status: 0x0

Process Information:
Caller Process ID: 0x2d74
Caller Process Name: C:\Program Files (x86)\Universal\Universal.Server.exe

Network Information:
Workstation Name: ServerName
Source Network Address: -
Source Port: -

Detailed Authentication Information:
Logon Process: Advapi
Authentication Package: Negotiate
Transited Services: -
Package Name (NTLM only): -
Key Length: 0

This event is generated when a logon request fails. It is generated on the computer where access was attempted.

The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).

The Process Information fields indicate which account and process on the system requested the logon.

The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

The authentication information fields provide detailed information about this specific logon request.
- Transited services indicate which intermediate services have participated in this logon request.
- Package name indicates which sub-protocol was used among the NTLM protocols.
- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.

Hello @jameshennessy ,

Thank you for the update and for checking the Windows Security event. That result is very helpful.

The key details are the failed `Logon Type: 4` together with:

`Failure Reason: The user has not been granted the requested logon type at this machine.`
`Status: 0xC000015B`

This is consistent with Windows rejecting a batch logon for the credential being validated. It also explains why adding `Log on as a service` did not change the behavior, while granting `Log on as a batch job` allowed the credential to authenticate and be added back to the PSU SecretStore.

Based on the evidence so far, the immediate failure appears to be caused by the Windows User Rights Assignment rather than an invalid credential or a SecretStore failure.

Thank you as well for clarifying the environment. I have noted PSU 2026.2.5, Windows Service hosting, Windows Server 2025 Standard 24H2, SQLite, and that 3 of 5 production Apps were affected.

Could you please confirm whether those three Apps are now starting normally after recreating the credential?

Also, was `Log on as a batch job` granted through Local Security Policy or through a domain GPO? Since the behavior appeared after a restart, that distinction may help us understand why the effective permission changed.

Best regards,
Ruben Tapia

Hi Ruben,
it does appear to be a windows based issue and not PSU related.

the three apps are back up and running, after creating the credential and re-adding it to the affect environment, it took a few minutes and I could then restart affected apps.

the permissions was granted through domain GPO.
the permissions were not there previously, but I do believe the credential was originally added when I was testing after first install and the same account was used to run the overall service.
there was an issue with logon to the server earlier in the day, where it seems the account half logged onto the server and I was just presented with a blank screen when trying after, so I forced a restart and the actual issue presented.

main take away is,

logon rights as a batch job seems to be needed for saved credential secrets.