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 b6cc789b for ; Tue, 6 Nov 2018 15:34:17 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 89F72A242E; Wed, 7 Nov 2018 01:34:16 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 435D3A22EC; Wed, 7 Nov 2018 01:34:00 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 8751EA215C; Wed, 7 Nov 2018 00:00:14 +1000 (AEST) Received: from post.cogs.com (post.cogs.com [72.43.6.86]) by minnie.tuhs.org (Postfix) with ESMTPS id BAFB7A215A for ; Wed, 7 Nov 2018 00:00:13 +1000 (AEST) Received: from localhost (localhost [127.0.0.1]) by post.cogs.com (Postfix) with ESMTP id 9DB3B1018047A3; Tue, 6 Nov 2018 09:00:12 -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 laKjPZ4Ca3yi; Tue, 6 Nov 2018 09:00:10 -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 9BD87101804792; Tue, 6 Nov 2018 09:00:10 -0500 (EST) Message-Id: <2B38E200-697F-4A26-9013-26C07B54351B@cogs.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_753A1593-49F6-45A0-AF5B-D998C6218458" Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.100.43\)) Date: Tue, 6 Nov 2018 09:00:09 -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=_753A1593-49F6-45A0-AF5B-D998C6218458 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 6, 2018, at 8:44 AM, Mantas Mikul=C4=97nas = wrote: >=20 > On Tue, Nov 6, 2018 at 3:21 PM Ben Greenfield > wrote: >=20 >=20 >> 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 >=20 >=20 > 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 >>=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. >=20 >=20 > 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 >=20 > No, kerberized servers don't obtain own tickets =E2=80=93 unless they = themselves act as *clients* to another kerberized service. Which might be what I=E2=80=99m trying to describe. >=20 > 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. >=20 > As for the trust relationship between client and server =E2=80=93 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 =E2=80=93 whereas the client knows that only the = real server will be able to decrypt it. >=20 > 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 > --=20 > Mantas Mikul=C4=97nas --Apple-Mail=_753A1593-49F6-45A0-AF5B-D998C6218458 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Nov 6, 2018, at 8:44 AM, Mantas Mikul=C4=97nas <grawity@gmail.com> = wrote:

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 <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. 

No, kerberized servers don't obtain own = tickets =E2=80=93 unless they themselves act as *clients* to another = kerberized service.

Which might be what I=E2=80=99m trying to = describe.



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 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 =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.)

--
Mantas Mikul=C4=97nas

= --Apple-Mail=_753A1593-49F6-45A0-AF5B-D998C6218458--