On 11/05/2018 12:24 AM, Mantas Mikulėnas wrote:
> Let the client handle authentication via Kerberos
I don't know enough about Kerberos (yet) to know if it would be possible
for a login process to communicate with the KDC and get a TGT as part of
logging in, without already being logged in.
Sure, that's how the process of obtaining a TGT works in the first place. You send an AS-REQ packet with proof of password knowledge, you get an AS-REP with the TGT ticket back.
My ignorance is leaving me with a priming problem that seems like a
catch 22. You can't login without shadow information or TGT. But
Not sure what part of the 'login' process you're referring to.
* Credential verification? That's part of obtaining a TGT. You don't need a ticket to obtain the TGT – instead you submit proof that you know the password.
* Retrieval of directory information (uid, gid, homedir)? The login process either uses its own "machine" credentials to do so, or just retrieves the information anonymously, depending on sysadmin's preference. (Or in the case of AD it's already stapled to the TGT to speed everything up.)
traditional (simpler) kinit is run after being logged in. So ... how do
you detangle that? The only thing that I can come up with is that the
login process does the kinit functionality on the users behalf.
Yes, that's exactly what happens. However, probably not for all of the same reasons as you imagine.