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=0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,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 2ab18259 for ; Mon, 5 Nov 2018 22:31:34 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 4EDF8A242B; Tue, 6 Nov 2018 08:31:33 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 657F0A2426; Tue, 6 Nov 2018 08:31:11 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 2A9C5A2162; Tue, 6 Nov 2018 07:36:44 +1000 (AEST) Received: from mail-oi1-f171.google.com (mail-oi1-f171.google.com [209.85.167.171]) by minnie.tuhs.org (Postfix) with ESMTPS id 28DE1A1FBC for ; Tue, 6 Nov 2018 07:36:38 +1000 (AEST) Received: by mail-oi1-f171.google.com with SMTP id p144-v6so8860901oic.12 for ; Mon, 05 Nov 2018 13:36:38 -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=bEDXaaPOf673zBmnVwnIc5kr4ZtCUcWR0SB9PZhAr3k=; b=uWONEAJ2i+k4Or4pRHxz+w6AKPPcY5aF2fsAe8SgkBYwA8KfFmTieB2TY9bb/XL96r mrnRp0HCyskOVEhrrQeKiFnRVNr5N5eebhGeTwnKai5wSut402KxfieTQvr8bB+xzQwY xmOTtSffsdOnP1mhEzS6Aq46FlwwM3bRdM3cR2hbWXFOpNW8jh3YLqIi8/ZnweP56OYJ FYgmh3HKYRR/a8dxxkCefzzTB/y1E6Qs0x4BC5A9BPKVaGHMjbIpBBanrN6RqkoKUJq5 wW+Xan1y7IebO81N8wBon4LagssbRQRtpeBFZBOC53Pt+fmyzov8qTtznmT8Rqu9bC9O 3Mxw== 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=bEDXaaPOf673zBmnVwnIc5kr4ZtCUcWR0SB9PZhAr3k=; b=ho4iEEUArt8b3iJO9C23mwXbnrB3jcm0bmeg1k8oC/Rty6qfyF0DusSRPtulYxaPCj abkONid7+6Li0B07ALBHlalXTHZVMxhYIPovHd2mhbo/Eau4EURS/vN4cOZ2PQnSnA5A V9w/VK8zh9LchtiDTeEcGFGjw2n34HCZJl2G0Gv9yJ1enxbX0JtixeY2kxIBT2qNf0pC WtYE65N2h799BZ57opCgZkNhmCyTaPS6HfqcPfEx4G8V+YCTvAuWrK76i0wYYAi1gnwe I8ULPskitFspQ12wqjMPsA9W0AAcB+XzA+HFA3uWP6uozsYPD6uWrBaG7u5IsahGpPTo cPMA== X-Gm-Message-State: AGRZ1gIQnrR+i3ApInKXlRRHNDq1RyVMc383j2mxIhFG2d+wVwMcE3l4 aE26BMUyTDUIP+OEIffyxpR1xFPB7rWc01UiindGzQ== X-Google-Smtp-Source: AJdET5cIMYvHTP3ThivO3arc5Gj4wbpQB+nxFEqjE4COhCKAqBYHbaGFQQdCZDri2PmemQvD6E7Pwmc3u3kkQBMSV4A= X-Received: by 2002:aca:50ce:: with SMTP id e197-v6mr14602599oib.174.1541453797374; Mon, 05 Nov 2018 13:36:37 -0800 (PST) MIME-Version: 1.0 References: <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net> In-Reply-To: <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net> From: =?UTF-8?Q?Mantas_Mikul=C4=97nas?= Date: Mon, 5 Nov 2018 23:36:25 +0200 Message-ID: To: gtaylor@tnetconsulting.net Content-Type: multipart/alternative; boundary="00000000000007daf30579f1ae0b" 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 Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --00000000000007daf30579f1ae0b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 5, 2018 at 11:00 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 as part of > logging in, without already being logged in. > Sure, that's how the process of obtaining a TGT works in the first place. You send an AS-REQ packet with proof of password knowledge, you get an AS-REP with the TGT ticket back. 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 > Not sure what part of the 'login' process you're referring to. * Credential verification? That's part of obtaining a TGT. You don't need a ticket to obtain the TGT =E2=80=93 instead you submit proof that you know= the password. * Retrieval of directory information (uid, gid, homedir)? The login process either uses its own "machine" credentials to do so, or just retrieves the information anonymously, depending on sysadmin's preference. (Or in the case of AD it's already stapled to the TGT to speed everything up.) > 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. > Yes, that's exactly what happens. However, probably not for all of the same reasons as you imagine. --=20 Mantas Mikul=C4=97nas --00000000000007daf30579f1ae0b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Nov 5,= 2018 at 11:00 PM Grant Taylor via TUHS <tuhs@minnie.tuhs.org> 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 possibl= e
for a login process to communicate with the KDC and get a TGT as part of logging in, without already being logged in.

Sure, that's how the process of obtaining a TGT works in the firs= t place. You send an AS-REQ packet with proof of password knowledge, you ge= t an AS-REP with the TGT ticket back.

My ignorance is leaving me with a priming problem that seems like a
catch 22.=C2=A0 You can't login without shadow information or TGT.=C2= =A0 But

Not sure what part of the '= ;login' process you're referring to.

=C2= =A0* Credential verification? That's part of obtaining a TGT. You don&#= 39;t need a ticket to obtain the TGT =E2=80=93 instead you submit proof tha= t you know the password.

=C2=A0* Retrieval of dire= ctory information (uid, gid, homedir)? The login process either uses its ow= n "machine" credentials to do so, or just retrieves the informati= on anonymously, depending on sysadmin's preference. (Or in the case of = AD it's already stapled to the TGT to speed everything up.)
= =C2=A0
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.

Yes, that's exactly what happens. However, pro= bably not for all of the same reasons as you imagine.

<= /div>--
Mantas Mikul=C4=97nas
--00000000000007daf30579f1ae0b--