On Mon, Nov 5, 2018 at 11:00 PM Grant Taylor via TUHS <tuhs@minnie.tuhs.org>
wrote:

> 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.

-- 
Mantas Mikulėnas