So I was fiddling with my replacement TL server at home and I wanted to play a bit more with the Kerberos part of it.
So up until now I’ve been using Kerberos to sign in on my TL server (yes, I know, I’m a nerd I run Kerberos at home). Which works absolutely fine, but when logging in on the session itself, it’s ticketless, which then causes login errors on other services that normally authenticate fine when using a password.
So I tried the workaround Karl wrote (see below) in 2018 which works fine. NOTE, I opted to only set this up for a single host instead of all hosts I log in on.
On the client: Add the following to ~/.thinlinc/config: Host myhost GSSAPIDelegateCredentials yes*
On the server, remove /opt/thinlinc/etc/xstartup.d/01-tl-kinit.sh
Log in, and forwarded ticket available and I can immediately start using it
So with regards to the caveats posted in that ticket:
Delay between session and connection without a ticket: I didn’t observe this, but I’ve been using a single-node TL server in this test.
My system runs with KCM enabled, which means that all Kerberos sessions are handled by SSSD. So all sessions will re-use the same cache, regardless of means of entering the system/session (TL, SSH, sudo, console, etc.). And every time a new login is made (or password prompt is filled in) this ticket will be refreshed.
Disconnecting destroys the ticket: not true, I logged in on my system with Kerberos and disconnected the session. I then logged in with a different user and sudo-ed to my own session. The forwarded ticket sticks around and will be until it’s renewal period expires (in my case, that’s 7 days)
So I think this can be used in a stable manner, and given the correct server setup, I think it would be better to add a checkbox in the client that will ‘Enable Kerberos Credential Forwarding’ instead of having to tinker with the config file
Major kudos for running Kerberos at home I thought I was nerdy for running a mail server from my lounge. Sounds like I might have to up my game.
Anyway, thanks for testing. This does seem like it should work, it probably just hasn’t been considered enough of a priority to make it into ThinLinc yet.
I’ve made note of your comments though. Is this a requirement you’re seeing “in the wild”, i.e. in production environments? Or just a rainy day experiment at home?
Delay between session and connection without a ticket: I didn’t observe this, but I’ve been using a single-node TL server in this test.
IIRC, the delay discussed only becomes a problem when trying to do things that depend on the Kerberos ticket very early during session startup. The prime example here is a home directory that’s an NFS mount with Kerberos authentication. In that scenario, the ThinLinc session will begin starting up without a Kerberos ticket (and therefore no home directory).
Anyway, thank you for taking the time to share your results! It’s highly appreciated.
Mostly rainy day experimenting, most scenarios where we use Thinlinc there’s no domain connection for the system running the client. But it might be useful in scenario’s where users are provided a company laptop and VPN and need to log in to the office to work on e.g. location-restricted licensed software (Yes, those exist… That was fun during COVID )
The scenario where I can see this being an issue would probably be where there’s a master server that doesn’t host session, but a bunch of agents that do.
However, as the user is forwarding their current ticket for authenticating, I don’t think it will matter as much. The desktop also needs to load and, well, GNOME isn’t that fast
I run Kerberos at home). Which works absolutely fine, but when logging in on the session itself, it’s ticketless, which then causes login errors on other services that normally authenticate fine when using a password.
forwarded ticket available and I can immediately start using it
I thought I was nerdy for running a mail server from my lounge. Sounds like I might have to up my game.
)