From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: tuhs-bounces@minnie.tuhs.org X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: * X-Spam-Status: No, score=1.2 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE,SUBJ_ALL_CAPS autolearn=no autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id b5af8dfa for ; Tue, 6 Nov 2018 15:32:03 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 2D064A22F1; Wed, 7 Nov 2018 01:32:02 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 95521A22EF; Wed, 7 Nov 2018 01:31:17 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id E9BA4A215C; Tue, 6 Nov 2018 23:45:05 +1000 (AEST) Received: from mail-oi1-f179.google.com (mail-oi1-f179.google.com [209.85.167.179]) by minnie.tuhs.org (Postfix) with ESMTPS id 58078A215A for ; Tue, 6 Nov 2018 23:45:00 +1000 (AEST) Received: by mail-oi1-f179.google.com with SMTP id j202-v6so10700554oih.10 for ; Tue, 06 Nov 2018 05:45:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kjqw8VGlqhAnLhxORRMQmG/pVtmEjBuyJa31VP0GJ90=; b=vWXMRN9KRQrdmMI35+WqfIJiplJQssqBQTfBOmHZo0zJlr8rI+JuWKLcQ+4QjjhOnC 1SmOwsIogjv6LhfU7nGWfLgSjwMyFQYDkoOESmn6BGsGQyD5WMtESyNxlPWDPadw0Cm5 ZcwT04X/tmvaavqRaRQnefs8MavQc3pWmq8apDV8ACdM6Lq9mLauPIliVIOthSNH2D/2 w1+ty9cI1fTCI/VSv8Um452WoIxPLQXk6dpx7cGgQqve7U4xmYlocySgnJtGM+A6XMeP TbkfNR6/0bfFsvISG3M3lgjClhQCTMhii/ZKT+r+UQNJ8P85BCfGjQU6lzqY8S2CpYUS mk5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kjqw8VGlqhAnLhxORRMQmG/pVtmEjBuyJa31VP0GJ90=; b=rcmKcPqCAZ7m+UFYTm6cLqSTjNXSdd5V/nDbfPeTd4033ImuOy440ZLnzhm4xNrPxk j5QVtnW9xilQivHZBSE8WjJYo4tm6LYWjQiDb5r47a2LX8cFTDoCPd2mML7duuBJaSkQ zKAPTsNV6NAFZuiymT/6UpYVUyKgeIpWNGG8ZL3GVu5KlTcum9wbvjyF2B4M3aagx1IW tib+d0TuCChL4s4v47hICsJLyTE9EiQKec6Ua7GW1emq/GPxZ8RpGXIoh1T7m7Sda/m+ 3Cq6nP/e5LIP5ApaF9KJLL1g16EgcqbjEP9R3jzZvzF4C0tYT+FUoQks9Mxr3s0n4LLE /rdg== X-Gm-Message-State: AGRZ1gI4SvalYUtI+iskcEANONiAYM/xY2KCAPoa1vYXopcRHnDIel1Q QKh8LstlMkXFDNzhQDtBwvytFszWR86m9ujDBPQ3uVl2 X-Google-Smtp-Source: AJdET5dYZ7btKmZkqfcQw+BjgGXKpGWiGVLKUgFpqTuRJJuCwL5V8pnW/7q3koDzVXN7+yjRoddCtfLIQCsl7HtoRJE= X-Received: by 2002:aca:853:: with SMTP id 80-v6mr14678231oii.333.1541511899525; Tue, 06 Nov 2018 05:44:59 -0800 (PST) MIME-Version: 1.0 References: <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net> In-Reply-To: From: =?UTF-8?Q?Mantas_Mikul=C4=97nas?= Date: Tue, 6 Nov 2018 15:44:47 +0200 Message-ID: To: ben@cogs.com Content-Type: multipart/alternative; boundary="0000000000003038a50579ff3537" Subject: Re: [TUHS] YP / NIS / NIS+ / LDAP X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: tuhs@minnie.tuhs.org, gtaylor@tnetconsulting.net Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --0000000000003038a50579ff3537 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Nov 6, 2018 at 3:21 PM Ben Greenfield wrote: > > > On Nov 6, 2018, at 1:53 AM, Mantas Mikul=C4=97nas wro= te: > > 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=C4=97nas 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 a= s >> 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=E2=80=A6 > > > > I=E2=80=99m sorry it was about 8 years ago and is from memory but. I beli= eve > 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 Kerbero= s > =E2=80=93 services and clients can call libsasl instead of talking Kerber= os > directly, abstract away the complexity =E2=80=93 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 =E2=80=93 it doesn't have anythin= g specific > about "kerberization during boot up=E2=80=9D. > > > My memory could be wrong but I thought to establish the trust relationshi= p > between the kerberized server and the client happened during boot/when th= e > config files were read ticket granting tickets were given and received. > No, kerberized servers don't obtain own tickets =E2=80=93 unless they thems= elves 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 =E2=80=93 if I reme= mber 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 =E2= =80=93 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.) --=20 Mantas Mikul=C4=97nas --0000000000003038a50579ff3537 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Nov 6, 2018 at 3:21 PM Ben Greenfield <ben@cogs.com> wrote:

On Nov 6, 2018, at 1:53 AM, Mantas Mikul= =C4=97nas <grawit= y@gmail.com> wrote:

On Tue, Nov 6, 2018, 01:32 Ben Greenfield vi= a TUHS <tuhs@m= innie.tuhs.org> wrote:


> On Nov 5, 2018, at 2:36 PM, Grant Taylor via TUH= S <tuhs@minnie= .tuhs.org> wrote:
>=C2=A0
> On 11/05/2018 12:24 AM, Mantas = Mikul=C4=97nas wrote:
>> Let the client handle authentication via = Kerberos
>=C2=A0
> I don't know enough about Kerberos (yet) to= know if it would be possible for a login process to communicate with the K= DC and get a TGT as part of logging in, without already being logged in.>=C2= =A0
> My ignorance is leaving me with a priming problem that s= eems like a catch 22.=C2=A0 You can't login without shadow information = or TGT.=C2=A0 But traditional (simpler) kinit is run after being logged in.= =C2=A0 So ... how do you detangle that?=C2=A0 The only thing that I can com= e up with is that the login process does the kinit functionality on the use= rs behalf.

I found that I had to do all of this using SASL.=C2=A0

I remember it as SASL would handle the kerberization during boot up g= etting tickets for each LDAP entry that you wanted mapped to a service on t= hat client.

Sorry but I cannot pa= rse that sentence at all=E2=80=A6


I=E2=80=99m sorry it was about 8 years ago and is f= rom 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 ass= ociated a service and the config file for the service =C2=A0would point to = the ticket.


I could be wrong but I think SASL seems to be wa= y connect services on Linux with LDAP that are served kerberized.
=C2=A0
SASL is involved somewhat, in that it do= es help with implementing Kerberos =E2=80=93 services and clients can call = libsasl instead of talking Kerberos directly, abstract away the complexity = =E2=80=93 but that's all it is, an abstraction layer. (A quite useful o= ne, though.)

But it's not the only method, str= ictly speaking (e.g. SSH and HTTP use GSSAPI, and various older software us= e Kerberos directly). And as far as I could understand the previous paragra= ph =E2=80=93 it doesn't have anything specific about "kerberizatio= n during boot up=E2=80=9D.

My memory could be wrong but I thought to establish the trust relat= ionship between the kerberized server and the client happened during boot/w= hen the config files were read ticket granting tickets were given and recei= ved.=C2=A0

No, kerberized serve= rs don't obtain own tickets =E2=80=93 unless they themselves act as *cl= ients* to another kerberized service.

Trust relati= onships 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 cl= ients that's the password, for server's that's usually the raw = key in /etc/krb5.keytab.

As for the trust relation= ship between client and server =E2=80=93 if I remember the protocol correct= ly, 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) with= out any KDC involvement. On success, it knows that it's a legitimate ti= cket because only the KDC could have encrypted it =E2=80=93 whereas the cli= ent knows that only the real server will be able to decrypt it.
=

The main reason a server might obtain tickets on boot i= s because it *also* acts as client to another kerberized service. (For exam= ple, a web server might be a client of a fileserver. An SSH shell server mi= ght be a client of an LDAP directory server.)

--
Mantas Mikul=C4= =97nas
--0000000000003038a50579ff3537--