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.6 required=5.0 tests=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 721b478f for ; Tue, 6 Nov 2018 15:30:37 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 4B6D7A242E; Wed, 7 Nov 2018 01:30:36 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 50010A215C; Wed, 7 Nov 2018 01:30:08 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 90CDDA215E; Tue, 6 Nov 2018 23:21:19 +1000 (AEST) Received: from post.cogs.com (post.cogs.com [72.43.6.86]) by minnie.tuhs.org (Postfix) with ESMTPS id 0433EA215A for ; Tue, 6 Nov 2018 23:21:18 +1000 (AEST) Received: from localhost (localhost [127.0.0.1]) by post.cogs.com (Postfix) with ESMTP id 91A691018042A4; Tue, 6 Nov 2018 08:21:16 -0500 (EST) X-Virus-Scanned: amavisd-new at cogs.com Received: from post.cogs.com ([127.0.0.1]) by localhost (post.cogs.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id wHL_S-GytObl; Tue, 6 Nov 2018 08:21:15 -0500 (EST) Received: from rrcs-108-176-86-106.nys.biz.rr.com (rrcs-108-176-86-106.nys.biz.rr.com [108.176.86.106]) by post.cogs.com (Postfix) with ESMTPSA id 9F160101804293; Tue, 6 Nov 2018 08:21:15 -0500 (EST) Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_812AE028-AE0F-45C3-8DA1-004FECA5FA4E" Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.100.43\)) Date: Tue, 6 Nov 2018 08:21:14 -0500 In-Reply-To: To: =?utf-8?Q?Mantas_Mikul=C4=97nas?= References: <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net> X-Mailer: Apple Mail (2.3445.100.43) 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: , From: Ben Greenfield via TUHS Reply-To: Ben Greenfield Cc: tuhs@minnie.tuhs.org, gtaylor@tnetconsulting.net Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --Apple-Mail=_812AE028-AE0F-45C3-8DA1-004FECA5FA4E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 6, 2018, at 1:53 AM, Mantas Mikul=C4=97nas = wrote: >=20 > On Tue, Nov 6, 2018, 01:32 Ben Greenfield via TUHS = > wrote: >=20 >=20 > > On Nov 5, 2018, at 2:36 PM, Grant Taylor via TUHS = > wrote: > >=20 > > On 11/05/2018 12:24 AM, Mantas Mikul=C4=97nas wrote: > >> Let the client handle authentication via Kerberos > >=20 > > 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. > >=20 > > 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. >=20 > I found that I had to do all of this using SASL.=20 >=20 >=20 > 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. >=20 > 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 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. >=20 > I could be wrong but I think SASL seems to be way connect services on = Linux with LDAP that are served kerberized. > =20 > SASL is involved somewhat, in that it does 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 one, though.) >=20 > 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 = anything specific about "kerberization during boot up=E2=80=9D. 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.=20 --Apple-Mail=_812AE028-AE0F-45C3-8DA1-004FECA5FA4E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Nov 6, 2018, at 1:53 AM, Mantas Mikul=C4=97nas <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:
> 
> 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.
> 
> 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 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 =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 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 anything specific about = "kerberization during boot = up=E2=80=9D.

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. 



= --Apple-Mail=_812AE028-AE0F-45C3-8DA1-004FECA5FA4E--