On Nov 6, 2018, at 8:44 AM, Mantas Mikulėnas
<grawity(a)gmail.com> wrote:
On Tue, Nov 6, 2018 at 3:21 PM Ben Greenfield <ben(a)cogs.com
<mailto:ben@cogs.com>> wrote:
On Nov 6, 2018, at 1:53 AM, Mantas Mikulėnas
<grawity(a)gmail.com <mailto:grawity@gmail.com>> wrote:
On Tue, Nov 6, 2018, 01:32 Ben Greenfield via TUHS <tuhs(a)minnie.tuhs.org
<mailto:tuhs@minnie.tuhs.org>> wrote:
On Nov 5, 2018, at 2:36 PM, Grant Taylor via TUHS
<tuhs(a)minnie.tuhs.org <mailto: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.
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.
No, kerberized servers don't obtain own tickets – unless they themselves act as
*clients* to another kerberized service.
Trust relationships between the server and KDC (as well as between the client and KDC)
are just based on it knowing the same shared secret as the KDC does. For clients
that's the password, for server's that's usually the raw key in
/etc/krb5.keytab.
As for the trust relationship between client and server – if I remember the protocol
correctly, at this point it becomes asymmetric. When a client sends its ticket to the
server, the server will just decrypt it using its own key (keytab) without any KDC
involvement. On success, it knows that it's a legitimate ticket because only the KDC
could have encrypted it – whereas the client knows that only the real server will be able
to decrypt it.
The main reason a server might obtain tickets on boot is because it *also* acts as client
to another kerberized service. (For example, a web server might be a client of a
fileserver. An SSH shell server might be a client of an LDAP directory server.)
--
Mantas Mikulėnas