I have PSU installed on a linux centos 7 server ( and not without difficulties … )
I can access the web interface with Firefox on another linux centos 7 computer, with a linux user.
The administrator of the server said PSU web interface is running behind an apache frontend web server where Single Sign On is allowed and linux user authentified.
He says the client’s username should be sent to PSU in the http request.
How can I configure PSU in this context to permits the authentication and access of the web interface without giving a login and password on the login page.
Is it possible ?
At this time I put in a log file the content of the $headers variable in the authentication.ps1 script, but it is always null.
NB : In desperation, I have modified the windows authentication parameter to true in the appsettings.linux.json file but PSU returns a blank page and don’t runs the authentication.ps1 script.
This configuration is a little out of my wheelhouse (linux + apache etc) but it should work. We are using negotiate authentication when windows authentication is enabled.
Here’s some information about it.
It does mention this about proxies:
Credentials can be persisted across requests on a connection. Negotiate authentication must not be used with proxies unless the proxy maintains a 1:1 connection affinity (a persistent connection) with Kestrel.
Can you share a network trace (browser web tools is fine) when trying to login to PSU?
When windows authentication is set to true in PSU settings, Apache is running as a web proxy for PSU, and trying to connect to a PSU page, or the admin PSU interface, we have a 500 internal error and a blank webpage.
We have found that the problem is linked to the service account running PSU and the kerberos keytab file that kestrel is trying to use.
When PSU is launched by the root user directly, the SSO is running perfectly.
Is there a way to have more information about what Kestrel is trying to do ?
We have activated the Trace loglevel in the PSU settings but we didn’t find anything about the authentication error except the GSSAPI exception I said.
Now that SSO is running, we have a problem with the role based access. But I create another topic.
The problem was Kestrel trying to read the wrong keytab file.
On our centos machine, we have several keytab files.
One was created for the installation of the kerberos library (krb5) with the root user and the HOST principal.
One was created for apache to authenticate users in a different location of the first one and for the HTTP principal.
The apache side was working.
But Kestrel did’nt.
We assumed it will use the keytab file used by apache because of the redirection but we were wrong.
Kestrel was trying to find the principal for HTTP in the default location (krb5 keytab file that only have an entry for HOST).
We configured the service (systemctl) that runs PSU with an environment variable (KRB5_KTNAME) that indicates the good location of the keytab file, and now it works well.
)