On Tue, Nov 6, 2018 at 3:21 PM Ben Greenfield wrote: > > > On Nov 6, 2018, at 1:53 AM, Mantas Mikulėnas wrote: > > On Tue, Nov 6, 2018, 01:32 Ben Greenfield via TUHS > wrote: > >> >> >> > On Nov 5, 2018, at 2:36 PM, Grant Taylor via TUHS >> 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. >> > >> > 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 >> 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. >> >> I found that I had to do all of this using SASL. >> >> >> I remember it as SASL would handle the kerberization during boot up >> getting tickets for each LDAP entry that you wanted mapped to a service on >> that client. >> > > Sorry but I cannot parse that sentence at all… > > > > I’m sorry it was about 8 years ago and is from memory but. I believe > during the startup of the system the SASL config files contained tickets > that established a trust relationship between that system and our Open > Directory server. My memory is that each ticket was associated a service > and the config file for the service would point to the ticket. > Upon rereading this, you're probably thinking of keytabs (which hold static pre-provisioned keys) rather than tickets (which hold session keys). -- Mantas Mikulėnas