|
|
|
|
|
|
by bodeadly
199 days ago
|
|
|
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. |
|
|
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.