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 fd9d7dec for ; Tue, 6 Nov 2018 15:33:06 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id C7691A22EC; Wed, 7 Nov 2018 01:33:04 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 2FF5CA217F; Wed, 7 Nov 2018 01:32:34 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id BBB34A215E; Tue, 6 Nov 2018 23:46:52 +1000 (AEST) Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com [209.85.210.41]) by minnie.tuhs.org (Postfix) with ESMTPS id 62DF9A215A for ; Tue, 6 Nov 2018 23:46:47 +1000 (AEST) Received: by mail-ot1-f41.google.com with SMTP id k98so1210321otk.3 for ; Tue, 06 Nov 2018 05:46:47 -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=wBSEPJsKM9YBOULuqbiVpswpDkHOo5MNQZLPgMZ+0mE=; b=h+8yK8WrAYqRTTvlk5V0UCdJQcX9xKOSfAHRetWkIoskZhWHCqJsCE9MFYY7TRbW42 5vjzypTs8KEk+0sUSUTYa5A9wNA7USOBJ1N2FVfvQCScWgB9kkeXfDrvSU+HDq8Epa7a A9Dl/sKgN2EY+fWFc37b2iyo8+VKjw6oVS535yO6Ddmv4v8R77feplHmP+2yXM56iKRK AOZNFueUcHycsRKVoT/6T2PoyqQJ6hYwu1x7LsdkVauzHfdIdpNppTDAVRg0FbUBFzZ6 bUKrWDgny9Kbi3JsVTuL1f4dvGD1Iowo5DYyk52gOTCwyODMBiZHY90Azar/PJ9gYsLk of6A== 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=wBSEPJsKM9YBOULuqbiVpswpDkHOo5MNQZLPgMZ+0mE=; b=FZuvtVCUVqCOSDbpi5v8vkcGrxkrz7KYPdrJavShRL0YQa9w5669AhQDZOtY+pNgH0 BKAdXEfunW6FP3edeFwrLUcy4qVS/oF2TbaMV38S5rJxUdKY6K2XjxHVzFIaXDJt4v4Z VpXPk/eGAemnUQ6DNnZW5muQPPvf/by4IBUxpGyONXQtDA9J/wSZyOUNZRz6gBiSAz/s 5QSlFRCDN64ANZoIMwnlcTxtn9N2Cuz1/GoFpEBHVP8KENAiCo07/A+A04/lAonquf+w Up5xUPWgO4ufW1Ar1mwlp7ecAiLWBO/bf5v1/VjpVT32H+QT3S2B15/LJaXEVl8uochD 0/NA== X-Gm-Message-State: AGRZ1gLaaHISqMl9OjLXLE92iVro6/L3qVPY18PZkw4u9T0v8YzXjvk0 qKygjIqjl+5Bo5GEqgv//bE9TBeqBP9wffiaycc= X-Google-Smtp-Source: AJdET5e+JoOIBWvGHFCwNZJdMYL6G1o5KPXFXleS3DqcrNfX6xiKtIcJdWP8TYaPcbzR/NYaNPCFkgMIy0C6s2tP/9o= X-Received: by 2002:a9d:38ca:: with SMTP id k10mr17037887ote.72.1541512006532; Tue, 06 Nov 2018 05:46:46 -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:46:34 +0200 Message-ID: To: ben@cogs.com Content-Type: multipart/alternative; boundary="0000000000009102ea0579ff3b9d" 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" --0000000000009102ea0579ff3b9d 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. > Upon rereading this, you're probably thinking of keytabs (which hold static pre-provisioned keys) rather than tickets (which hold session keys). --=20 Mantas Mikul=C4=97nas --0000000000009102ea0579ff3b9d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Nov 6,= 2018 at 3:21 PM Ben Greenfield <ben@cog= s.com> wrote:


On Nov 6, 2018, at 1:53 AM, Mantas Mikul=C4=97nas <<= a href=3D"mailto:grawity@gmail.com" target=3D"_blank">grawity@gmail.com= > wrote:

On Tue, Nov 6, 2018, 01:32 Ben Greenfield via TUHS <tuhs@minnie.tuhs.org>= ; wrote:


> On Nov 5, 2018, at 2:36 PM,= Grant Taylor via TUHS <tuhs@minnie.tuhs.org> wrote:
>=C2=A0
> On 11/05/2018 = 12:24 AM, Mantas Mikul=C4=97nas wrote:
>> Let the client handle au= thentication via Kerberos
>=C2=A0
> I don't know enough about Kerber= os (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 lo= gged in.
>= =C2=A0
> My ignorance is leaving me with a priming problem tha= t seems like a catch 22.=C2=A0 You can't login without shadow informati= on 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 = 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.=C2=A0

<= br>I remember it as SASL would handle the kerberization during boot up gett= ing 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 believe during the startup of the system the SASL config fil= es contained tickets that established a trust relationship between that sys= tem and our Open Directory server. My memory is that each ticket was associ= ated a service and the config file for the service =C2=A0would point to the= ticket.

Upon rereading t= his, you're probably thinking of keytabs (which hold static pre-provisi= oned keys) rather than tickets (which hold session keys).
<= br>
--
Mantas Mikul=C4=97nas
--0000000000009102ea0579ff3b9d--