6 Nov
2018
6 Nov
'18
2:44 p.m.
On Tue, Nov 6, 2018 at 3:21 PM Ben Greenfield <ben(a)cogs.com> wrote:
On Nov 6, 2018, at 1:53 AM, Mantas Mikulėnas <grawity(a)gmail.com> wrote:
On Tue, Nov 6, 2018, 01:32 Ben Greenfield via TUHS <tuhs(a)minnie.tuhs.org>
wrote:
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.
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
On Nov 5, 2018, at 2:36 PM, Grant Taylor via TUHS
<tuhs(a)minnie.tuhs.org>
wrote:
On 11/05/2018 12:24 AM, Mantas Mikulėnas wrote:
possible for
a login process to communicate with the KDC and get a TGT as
part of logging in, without already being logged in.
Let the client handle authentication via Kerberos
I don't know enough about Kerberos (yet) to know if it would be
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.
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.