[TUHS] YP / NIS / NIS+ / LDAP
ben at cogs.com
Tue Nov 6 23:21:14 AEST 2018
> On Nov 6, 2018, at 1:53 AM, Mantas Mikulėnas <grawity at gmail.com> wrote:
> On Tue, Nov 6, 2018, 01:32 Ben Greenfield via TUHS <tuhs at minnie.tuhs.org <mailto:tuhs at minnie.tuhs.org>> wrote:
> > On Nov 5, 2018, at 2:36 PM, Grant Taylor via TUHS <tuhs at minnie.tuhs.org <mailto:tuhs at 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.
> > 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.
> I could be wrong but I think SASL seems to be way connect services on Linux with LDAP that are served kerberized.
> SASL is involved somewhat, in that it does help with implementing Kerberos – services and clients can call libsasl instead of talking Kerberos directly, abstract away the complexity – but that's all it is, an abstraction layer. (A quite useful one, though.)
> But it's not the only method, strictly speaking (e.g. SSH and HTTP use GSSAPI, and various older software use Kerberos directly). And as far as I could understand the previous paragraph – it doesn't have anything specific about "kerberization during boot up”.
My memory could be wrong but I thought to establish the trust relationship between the kerberized server and the client happened during boot/when the config files were read ticket granting tickets were given and received.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the TUHS