6 Nov
2018
6 Nov
'18
3:36 a.m.
On Mon, Nov 5, 2018 at 11:00 PM Grant Taylor via TUHS <tuhs(a)minnie.tuhs.org>
wrote:
On 11/05/2018 12:24 AM, Mantas Mikulėnas wrote:
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
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.
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