Seeking Help with Windows Authentication Issue in PowerShell Universal

Seeking Help with Windows Authentication Issue in PowerShell Universal

Environment Configuration

Server Details:

•	Operating System: Windows Server 2019
•	PowerShell Universal Version: Latest
•	Database: SQL Server

Key Components:

•	PowerShell Universal (PSU) installed and configured.
•	HTTPS enabled using a certificate.
•	Windows Authentication enabled.
•	DNS A Record: powershelluniversal.example.com pointing to the IP address of the PSU server.

Configuration Details

appsettings.json:

{
“Kestrel”: {
“Endpoints”: {
“HTTPS”: {
“Url”: “https://*:443”,
“Certificate”: {
“Path”: “D:\Path\To\Cert\cert-powershelluniversal.example.com.pfx”,
“Password”: “YourPfxPassword”
}
}
},
“RedirectToHttps”: true
},
“Plugins”: [
“SQL”
],
“Data”: {
“RepositoryPath”: “D:\Path\To\Repository”,
“ConnectionString”: “Server=YourSQLServer;Database=PSU;Integrated Security=true;TrustServerCertificate=True”
},
“Authentication”: {
“Windows”: {
“Enabled”: true
}
}
}

SPN Registration:

setspn -S HTTP/powershelluniversal.example.com DOMAIN\ServiceAccount

Claims-Based Mapping:

•	Configured a claims-based map against a GroupSID for the Admins role.

Issue Description

Despite following the above configuration steps, I am encountering issues with Windows Authentication. Specifically, when accessing the PowerShell Universal web interface, a credential prompt appears, and users are not logged in automatically using their Windows credentials.

Observed Behavior:

•	Users are prompted for credentials instead of being authenticated automatically.
•	After entering credentials, access is sometimes denied with a 403 error.

Troubleshooting Steps Taken

1.	Verified SPN Registration:
•	Confirmed using setspn -Q HTTP/powershelluniversal.example.com.
2.	Checked Kerberos Tickets:
•	Cleared existing tickets using klist purge.
•	Verified new tickets using klist.
3.	Browser Configuration:
•	Ensured browsers are configured to pass Windows credentials automatically.
4.	Configuration Verification:
•	Ensured appsettings.json is correctly configured.
•	Verified HTTPS setup and SPN registration.
5.	Service Account Permissions:
•	Granted the service account “Allowed to authenticate” permissions in Active Directory.
•	Enabled Kerberos delegation in security settings.

Request for Assistance

I am seeking assistance from the Ironman Software community to resolve the Windows Authentication issue. Specifically, I am looking for guidance on:

1.	Additional Configuration Steps: Any missed configuration settings or best practices for setting up Windows Authentication with PSU.
2.	Debugging Tips: Effective methods to debug and trace authentication issues.
3.	Community Experiences: Insights or similar experiences from other users who have successfully implemented Windows Authentication in PSU.

Your expertise and suggestions would be greatly appreciated.

Thank you!

Product: PowerShell Universal
Version: 4.3

Any change this edge policy isnt set? (authserverallowlist)

No this policy is not set

Maybe thats the issue then.
We have our entire domain in there “*.Domain.org”

To help, did you turn on Kerberos logging to verify you are not seeing an issue with what SPN it is calling or random issues with encryption, TLS.
Enable Kerberos event logging - Windows Server | Microsoft Learn
That would help verify it was a Kerberos issue or rule it out completely to focus on other areas the problem might be coming from. Something like a fiddler trace might also help see into the transaction to locate the issue.

I’m running into the same issue with almost the same setup. Works fine on the server if I only use the server name and not the FQDN. Remotely, it gives me the login prompt box in chrome or edge. Once I try and authenticate I end up with a HTTP 500 error.

Connecting to the servername only and not the FQDN does sound like DNS or SPN problem. Is the service running as localhost or as a service account? What does the PSU logs tell you?

It is running as a service account and the SPN is set. The main thing we keep seeing is these errors.

2024-11-14 13:36:46.343 -06:00 [DBG] Could not find bind method for UniversalAutomation.IPublicSecretManagerService.
2024-11-14 13:36:46.350 -06:00 [INF] RPC services being provided by UniversalAutomation.IPublicSecretManagerService: 1
2024-11-14 13:36:46.361 -06:00 [DBG] Could not find bind method for PowerShellUniversal.IdentityClient.
2024-11-14 13:36:46.368 -06:00 [INF] RPC services being provided by PowerShellUniversal.IdentityClient: 6
2024-11-14 13:36:46.372 -06:00 [DBG] Could not find bind method for PowerShellUniversal.JobDataService.
2024-11-14 13:36:46.385 -06:00 [INF] RPC services being provided by PowerShellUniversal.JobDataService: 12
2024-11-14 13:36:46.388 -06:00 [DBG] Could not find bind method for PowerShellUniversal.CacheService.
2024-11-14 13:36:46.388 -06:00 [DBG] No gRPC methods discovered for PowerShellUniversal.CacheService.
2024-11-14 13:36:46.391 -06:00 [DBG] Could not find bind method for PowerShellUniversal.PublicClient.

I am not familiar with this error so maybe someone else can chime in. When I see RPC could not bind to me means an issue with security and something is preventing the account from connecting. Generally something like “Access this computer from the network” or something like that. Did you enable kerberos logging and can you see the account authenticating in the windows logs? I am guessing it is if the service is running so then it might not have access to connect to itself, you can try adding the account to the local administrator’s group which can sometimes bypass these security setting limitations.