Where do I find money to fund my rewrite of Kerberos 5 in Rust, removing the dumb options and Kerberos 4 compatibility and eventually create Kerberos 6 + AD that will solve a metric buttload of issues in Linux and knock a major peg of MS off?
That doesn't seem right to me, assuming you still want the paradigm of one-time principal-to-domain authentication with just-in-time principal-to-resource authentication. While I think you could probably use x509 certs to streamline and modernize the ticket-granting-and-session-key dance, you'd still be doing a lot of the same high-level things.
Depending on the use-case, Kerberos (/this imagined x509 Kerberos) or Oauth2 still seems suitable for single-authenticator/multiple-services paradigm.
Ultimately Kerberos is used to authenticated basically everything in a Windows on-prem environment and in a way that is largely transparent to the user. Silent SSO is a very nice feature.
Even if you're doing OIDC or SAML, those protocols do not define what is actually performing authentication at the IdP which, again, ultimately ends up being Kerberos if you're people are on-prem.
So whatever your feelings are about Kerberos as a protocol, it doesn't matter if that's what Windows uses.
And again, it cannot be obsoleted by other protocols.
Even if you're using a newer fido thing like passkeys or client certs or whatever, ultimately the device has to be authenticated to get that passkey or cert or whatever it is installed into the authenticator app of the device. So Kerberos is king on prem.
MIT Kerberos on Linux is not really compatible with Windows Kerberos in ways that cause problems that are not solved by re-writing Kerberos in another language. More important issues have to do with sharing credentials and getting trust info and other such things.
> Ultimately Kerberos is used to authenticated basically everything in a Windows on-prem environment and in a way that is largely transparent to the user. Silent SSO is a very nice feature.
When it works. And when it doesn't work (which is most of the time if you're outside of corporate LAN) you simply can't debug what's happening.
> MIT Kerberos on Linux is not really compatible with Windows Kerberos
It actually is! Long, long time ago I managed to join Windows into a pure Kerberos domain. Everything worked, including things like GSSAPI authentication in Putty or MySQL. It involved some `ksetup.exe` incantations, I think this guide might be still relevant: https://docs.oracle.com/cd/E19316-01/820-3746/gisqf/index.ht...
Of course, there was no group synchronization (because no AD).
That was about 20 years ago. Back then, I was working on helping companies migrate to Linux, and I toyed with an idea of having a background service to periodically sync groups from the Linux SMB server with the local users.
simplify gssapi, for one. single authentication and authorization: submit on slurm? ask kerberos + ldap. can i upload to this service? as kerberos + ldap. Policies applied on this computer? ask kerberos + ldap
i may be naive a bit, i'll accept that, but I really like how AD works (which is essentially kerberos + ldap)
I tried to set up network file sharing with NFS the other day and it was like pulling teeth. You need Kerberos if you want to map user names instead of user ids and still have some security.
Ultimately I gave up and used samba instead, but it does seem like there's a big gap in linux offerings for "home/small business network file sharing" with shared auth
