Mantas Mikulėnas grawity at gmail.com
Tue Nov 6 07:36:25 AEST 2018

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

> 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

 * 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

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181105/a3c65819/attachment.html>

More information about the TUHS mailing list