Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

A modem is a baudy house.

devel / comp.protocols.kerberos / Re: honoring the TRUSTED_FOR_DELEGATION KDC MS-SFU Kerberos Protocol Extensions flag?

SubjectAuthor
o Re: honoring the TRUSTED_FOR_DELEGATION KDC MS-SFU Kerberos Protocol Extensions Simo Sorce

1
Re: honoring the TRUSTED_FOR_DELEGATION KDC MS-SFU Kerberos Protocol Extensions flag?

<mailman.89.1713289596.2322.kerberos@mit.edu>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=541&group=comp.protocols.kerberos#541

  copy link   Newsgroups: comp.protocols.kerberos
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!tncsrv06.tnetconsulting.net!.POSTED.mailman.mit.edu!not-for-mail
From: sim...@redhat.com (Simo Sorce)
Newsgroups: comp.protocols.kerberos
Subject: Re: honoring the TRUSTED_FOR_DELEGATION KDC MS-SFU Kerberos
Protocol Extensions flag?
Date: Tue, 16 Apr 2024 13:46:25 -0400
Organization: Red Hat
Lines: 154
Message-ID: <mailman.89.1713289596.2322.kerberos@mit.edu>
References: <CAEkxbZuz1h7Ef4N5nz3teb8vcTxTE6iBUZC+TYssUcayKHhXQQ@mail.gmail.com>
<202404152356.43FNu4Wj009470@hedwig.cmf.nrl.navy.mil>
<Zh3JEbB0IfDztgSQ@tamriel.snowman.net>
<CAEkxbZvn=3G3MVossM0aRC3pFd+JCX13ugUo6BwyKqaKtv--xg@mail.gmail.com>
<aa9da132addeca21c08a0b3c2b1dc0653a608443.camel@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Injection-Info: tncsrv06.tnetconsulting.net; posting-host="mailman.mit.edu:18.7.21.50";
logging-data="29899"; mail-complaints-to="newsmaster@tnetconsulting.net"
User-Agent: Evolution 3.48.4 (3.48.4-1.fc38)
To: James Ralston <ralston@pobox.com>, kerberos@mit.edu
DKIM-Filter: OpenDKIM Filter v2.11.0 unknown-host (unknown-jobid)
Authentication-Results: mailman.mit.edu;
dkim=pass (1024-bit key, unprotected) header.d=mitprod.onmicrosoft.com
header.i=@mitprod.onmicrosoft.com header.a=rsa-sha256
header.s=selector2-mitprod-onmicrosoft-com header.b=F6icIQ0s;
dkim=pass (1024-bit key,
unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256
header.s=mimecast20190719 header.b=Wkgazx8A
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
b=g9QiFk3YanQJVcUf+Rm8RxBTs4x2/rsCDzLIs/VWjKsPihrd2g8I/HPDk7KYA8rkeEuaJ0I28N1JLS6ZAGWR97FhT0VdSKnZSAbW5/DlFJFUhloNsyzqDcZ8gHFJT6VaqqyPqBThlWwOElkCZbS4WnRiRcBXqdprruGXAlotJtwbfpWtGL5II46uREYsbDNhGXo5uODlhXpdJBCSStyv/jmC6qY1GYEutnh2+8Ad10PBsWyezQVJDYmLbTIJ+zs0Y7ZZDKh0jsbSlc271O7KOAebwVe58yLivJq89Z3mA/lD50t+GBt9aXMPK2MH3BcY5dIrnfNZp3jwvfUnXV4aIg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector9901;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
bh=3PQieWV0LJlvVeQCv85fBpfS9TUloKbb2+JrmpQ9inw=;
b=VR6CymV7ODxMt8kqZDjcAxXf5pQirF3ZFQwfCu0fY286GQdfMNbCeLEDW22t9ltI3Ylrb2ShE1WSKDOMKhpvc5kOVlbP2E4wxIH3oLoitgXzNgckhiVnZVKp8iAdqae3xl4RAMXifxyYhAgBkpqYph8o78ZLxAsUNDrfhB2jkwpMiZtiPXyFpyiZ3GZlMHge1hcfzYFJXpW9GeT886tbLvtXgm60GcUHU6xXVyeVRitPKp/tPlp2WsnluM+38xMmOPfQA+DluR5Ya6bGpm3KPcwqkNS9lCaWhKmQhX/0O71PgbclccfAmXzLPQBKJoRS3kcbjg+/rk5BPvF9o8bA8A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
170.10.133.124) smtp.rcpttodomain=mit.edu smtp.mailfrom=redhat.com;
dmarc=pass (p=none sp=none pct=100) action=none header.from=redhat.com;
dkim=pass (signature was verified) header.d=redhat.com; arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=mitprod.onmicrosoft.com; s=selector2-mitprod-onmicrosoft-com;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=3PQieWV0LJlvVeQCv85fBpfS9TUloKbb2+JrmpQ9inw=;
b=F6icIQ0skZofePnSsEarMJ7JCySUCJNKLZQJWp49/g0g0XM/zO7zZcG2oXlfeQ2g8bwkPjovGg3S3d3CQxikbZIBDZ38SoL+MCYAl0GIoxV3HkGbV3u7rtPZybhiNeRtQ3fKNUpHKqhB/BUoQi/anjha4HMsJyswJpIH4qwrSl4=
Authentication-Results: spf=pass (sender IP is 170.10.133.124)
smtp.mailfrom=redhat.com; dkim=pass (signature was verified)
header.d=redhat.com;dmarc=pass action=none header.from=redhat.com;
Received-SPF: Pass (protection.outlook.com: domain of redhat.com designates
170.10.133.124 as permitted sender) receiver=protection.outlook.com;
client-ip=170.10.133.124; helo=us-smtp-delivery-124.mimecast.com; pr=C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
s=mimecast20190719; t=1713289588;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:mime-version:mime-version:content-type:content-type:
content-transfer-encoding:content-transfer-encoding:
in-reply-to:in-reply-to:references:references;
bh=3PQieWV0LJlvVeQCv85fBpfS9TUloKbb2+JrmpQ9inw=;
b=Wkgazx8AeaV+ggAZA6StF3P1jzUpuP5jKG2jkZa25Z4LJM0bu58FE5vOWtAnR0bUalicEM
d0hYddTSfTyHOFtftGP5RAAoVuZbvpS0+qFYpmiHWwvJ4V8WbyXOxLpCdXgGWfNWoZGUYe
CbVqX5favs5U2naN+pkOgjqGpKlDAa8=
X-MC-Unique: _3nJvlKXNlWl-9o9bUzdGA-1
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1713289586; x=1713894386;
h=mime-version:user-agent:content-transfer-encoding:organization
:references:in-reply-to:date:to:from:subject:message-id
:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
bh=3PQieWV0LJlvVeQCv85fBpfS9TUloKbb2+JrmpQ9inw=;
b=i8Z8zyucRuqAT5f/ShbQQSKnwBfowCJxn5LkmtYd7c02ri4U2mGnZpWKoxvv5rTp/3
SI6JV+oH1/vmcUjqBeI0Mw+xL2HgQLNw+C3EyGRytj36Pozf8KIwwxyvMrA6TzeZgvGQ
eKREesI6w0tQG1gU6l4zqgcRFZph2WicXrkK1MyX81U260ZIQKATW/R2CkkklFGopCoP
/piRMW+QYRE9wk8tyv6gcMQ0P4otJ4PYoqrav7D/pPPL80bM9KwwNOPj+47yStZoL3Bi
iVbitSaH8ewuCrOxdr8Htt2p2UJDrktxbqjdr0Ou88t9ZyVvzLd4KP1aniMZGkK4hSPz
qR7A==
X-Forwarded-Encrypted: i=1;
AJvYcCUjucHa+5CqeZbQ0YZc9LJNRySBqcd9KUf1HVSunSqtf24G5LUiM67yZPTleZTRYMH2sducHpXyjGQ7nrTzextI
X-Gm-Message-State: AOJu0Yw1QlWzuqyE/XaBzy0zxu6r858IWkW20+u00Xt/9BVoBrW4xUGn
EEw1OHj/EQo2AdtRrgTJcRIVmgKCkmLxaCGtvodJV535vyQA0ehS0z4rV0rbHaPpU/jyGG2D764
o9JhzLoy5uMb1hZKhrXXNm1LG9MkP1wb7uLg2enb7agwEFg==
X-Received: by 2002:a05:620a:1a18:b0:78d:73f4:d1b4 with SMTP id
bk24-20020a05620a1a1800b0078d73f4d1b4mr15915359qkb.39.1713289586478;
Tue, 16 Apr 2024 10:46:26 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IGJD4v0qzzPiNqi53h5u1C77VQeVpKRCUDBkzEUUv0z4t/jEzUvwEQjvXN/W6mI+lgyCeCGMQ==
X-Received: by 2002:a05:620a:1a18:b0:78d:73f4:d1b4 with SMTP id
bk24-20020a05620a1a1800b0078d73f4d1b4mr15915336qkb.39.1713289586013;
Tue, 16 Apr 2024 10:46:26 -0700 (PDT)
In-Reply-To: <CAEkxbZvn=3G3MVossM0aRC3pFd+JCX13ugUo6BwyKqaKtv--xg@mail.gmail.com>
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
X-EOPAttributedMessage: 0
X-EOPTenantAttributedMessage: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b:0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS3PEPF0000C380:EE_|CH3PR01MB8213:EE_
X-MS-Office365-Filtering-Correlation-Id: 219dc052-5776-4f8a-9b8e-08dc5e3d2538
X-LD-Processed: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b,ExtAddr
X-MS-Exchange-AtpMessageProperties: SA
X-MS-Exchange-SenderADCheck: 0
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: uBgnL+VOgZHs2bkHA6NgJ4EpJHf8kkGpf9ds+3gfSm0P4Fm50F0dnIWvBXchhHrMGUhcZ3Mwni3hzWPL1wdjaPVyren0i4g7Aj48gH1DV6R+StvVqfAjKK/gP8gN4sa+me4HZbHWAtdgMSVmdD3u5M/xjiJJu0a4qxZ5hdFrRzVqPBGtvzfBsojQhstCryx2F6AyW6AYj6Zh3JQwNqjRaZ+0nEdPdBUlzyjLCePQVIMbzOoPXhOL9Ny96Jn+MxhwuQ+LlRpxflrghfss7uWEevRghuiqDbEjRUivoi9fAnA33j/RbJgK5QdWLAEKME3Hc8+WvyPIivFiVSW/vYkrT4U8j4Q6/DCBC99D+siY4E9rySnJasg5hTM3OR5uTrp62h0MT076jeB823NkT3U19hxPB27iZfZg3GjaaSx6ZGmDDytySMFCrLEFI9h7jXJvUd7eh8IPcoh/IEu7FFoMtegtGlKm12AY/GcAszjWl7ObHwlfgOTnGUWq9+xBLbLPISB6V5du89+lyYGUGdbnRa2+mE8TFGKT+8mPs2uzamJ4YioUILhWXs8j3ALeIfvLVr4CiXC45/K+MHEUF+m3x187W455pYfxz7sBdoOwjkY/x4/gB5dBDxPCqMsdhwSYh8CT6uBO4OQqDevGP3CA8rgW53WHphz1wds7PIW2K3+SiAfdVwdBTxt6Z8xv0itk
X-Forefront-Antispam-Report: CIP:170.10.133.124; CTRY:US; LANG:en; SCL:1; SRV:;
IPV:NLI; SFV:NSPM; H:us-smtp-delivery-124.mimecast.com;
PTR:us-smtp-delivery-124.mimecast.com; CAT:NONE;
SFS:(13230031)(61400799018)(376005)(48200799009); DIR:OUT; SFP:1102;
X-ExternalRecipientOutboundConnectors: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b
X-Auto-Response-Suppress: DR, OOF, AutoReply
X-OriginatorOrg: mitprod.onmicrosoft.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Apr 2024 17:46:28.8688 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 219dc052-5776-4f8a-9b8e-08dc5e3d2538
X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b
X-MS-Exchange-CrossTenant-AuthSource: DS3PEPF0000C380.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: Internet
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR01MB8213
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.mit.edu id
43GHkXqT816221
X-BeenThere: kerberos@mit.edu
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: The Kerberos Authentication System Mailing List <kerberos.mit.edu>
List-Unsubscribe: <https://mailman.mit.edu/mailman/options/kerberos>,
<mailto:kerberos-request@mit.edu?subject=unsubscribe>
List-Archive: <http://mailman.mit.edu/pipermail/kerberos/>
List-Post: <mailto:kerberos@mit.edu>
List-Help: <mailto:kerberos-request@mit.edu?subject=help>
List-Subscribe: <https://mailman.mit.edu/mailman/listinfo/kerberos>,
<mailto:kerberos-request@mit.edu?subject=subscribe>
X-Mailman-Original-Message-ID: <aa9da132addeca21c08a0b3c2b1dc0653a608443.camel@redhat.com>
X-Mailman-Original-References: <CAEkxbZuz1h7Ef4N5nz3teb8vcTxTE6iBUZC+TYssUcayKHhXQQ@mail.gmail.com>
<202404152356.43FNu4Wj009470@hedwig.cmf.nrl.navy.mil>
<Zh3JEbB0IfDztgSQ@tamriel.snowman.net>
<CAEkxbZvn=3G3MVossM0aRC3pFd+JCX13ugUo6BwyKqaKtv--xg@mail.gmail.com>
 by: Simo Sorce - Tue, 16 Apr 2024 17:46 UTC

The correct action is for you to ask the Domain Administrators to mark
the target hosts as ok for delegation, it is unclear why MIT Kerberos
should make it easy to override Realm policies.

Delegating a whole TGT is generally a bad idea, and often clients are
misconfigured to broadly forward it everywhere. That is why Microsoft
took back control in the hands of administrators. It is not a bad
thing, and if your setup has been vetted such that TGT delegation is an
acceptable risk, then it should be easy to get it fixed the proper way,
by getting your domain admins to set the right flag on the permitted
target hosts.

Note that if ticket delegation is needed solely to allow jumping from
hosts to host, you should be able to achieve the same result via agent
forwarding, it would be a safer option.

But all that said I would like to note that it is certainly
inappropriate to call people names before fully understanding the scope
of a security measure, just because it is a little inconvenient.

If you wanted a knob like the one you ask for it should probably be
called:
dishonor_trusted_for_delegation_mr_auditor_please_be_lenient

As for users that type their passwords onto random hosts, that is a
user education problem in general, but that can be addressed simply by
forcing the use of 2FA authentication on the user's part, preferably
via a hardware token and pkinit, but an OTP solution would work as
well.

Cheers,
Simo.

On Tue, 2024-04-16 at 03:03 -0400, James Ralston wrote:
> On Mon, Apr 15, 2024 at 7:56 PM Ken Hornstein <kenh@cmf.nrl.navy.mil> wrote:
>
> > I'm a LITTLE confused as to what you're describing here. As I
> > understand you, the TRUSTED_FOR_DELEGATION flag doesn't appear on
> > the wire and only in the account properties.
>
> Yes. Apologies; I should have been more precise: when Microsoft AD is
> acting as the KDC, whether AD sets the the OK-AS-DELEGATE flag in the
> TGS-REP is determined by whether the userAccountControl attribute in
> Active Directory of the host for which a service ticket is being
> requested has the TRUSTED_FOR_DELEGATION flag set. If
> TRUSTED_FOR_DELEGATION is set, OK-AS-DELEGATE is set in the TGS-REP;
> otherwise, OK-AS-DELEGATE is not set in the TGS-REP.
>
> > the [MIT Kerberos] library already provides an option to ignore that
> > [the OK-AS-DELEGATE] flag and it seems that by default it DOES
> > ignore that flag)
>
> I think the enforce_ok_as_delegate is the option you’re referring to?
>
> The man page claims it is disabled by default (unless an application
> specifically requests it). That matches our experiences.
>
> Heimdal appears to implement the same option (enforce_ok_as_delegate),
> but although the upstream source claims the default is false (do not
> enforce), Macs seem to enforce it by default. So either Apple has
> changed that default in the code, or else they are overriding the
> default somewhere in the Kerberos configuration.
>
> In terms of Windows, Microsoft’s Kerberos implementation seems to
> enforce compliance with the OK-AS-DELEGATE flag. (PuTTY on Windows
> will not delegate a credential unless the target host has the
> TRUSTED_FOR_DELEGATION flag set in AD.) Perhaps there is a way to
> disable this behavior, but we have not yet found a way to do so.
>
> > the RFC provides what I would consider a cognizant explanation:
> >
> > https://datatracker.ietf.org/doc/html/rfc4120#section-2.8
>
> Microsoft provides a similar explanation, but it is still an
> unsatisfying one, because it does not speak to our issue: if denying
> the ability to delegate a credential (in order to protect it from
> exposure to a possibly-untrustworthy host) forces the user to instead
> acquire a credential directly from the possibly-untrustworthy host
> (thereby exposing the user’s actual password), then this is not a
> security improvement. And while I acknowledge that RFC4120 is 19 years
> old and a lot has changed since it was originally published, neither
> the RFC authors nor Microsoft seems to have considered/predicted this
> scenario.
>
> On Mon, Apr 15, 2024 at 8:40 PM Stephen Frost <sfrost@snowman.net> wrote:
>
> > I'd *strongly* encourage you to ignore what OSX comes with in terms
> > of Kerberos "support" and push to move everything away from what OSX
> > ships with and to instead use MIT Kerberos. In my experience, this
> > is far from the only issue you're going to run into with the hacked
> > up Kerberos from OSX and they don't seem to care to properly
> > maintain it.
>
> It has been our experience that ripping out a vendor-supplied
> library/package and replacing it with an in-house version almost
> always has a higher long-term cost than simply living with whatever
> warts the vendor-supplied library/package has. So we are reluctant to
> take this approach unless there is truly no other choice.
>
> But this segues back to my original question: how are other sites that
> use Microsoft AD as their KDCs handling this?
>
> Are other sites ensuring that the TRUSTED_FOR_DELEGATION flag is set for
> Linux hosts, so that all various Kerberos libraries (including ones
> that enforce OK-AS-DELEGATE by default) will correctly delegate
> credentials to Linux hosts?
>
> Are other sites configuring their Kerberos libraries (on a per-OS
> basis) to ignore the OK-AS-DELEGATE flag?
>
> Have few other sites that use Microsoft AD as their KDC even run into
> this, because they don’t have services (e.g. home directories mounted
> via NFSv4+RPCGSS) that require a Kerberos credential, and therefore
> don’t need to forward Kerberos credentials to the remote host when
> making an ssh connection to it?
>
> My read of the MIT Kerberos kdc.conf man page is that ok-as-delegate
> is not one of the flags in default_principal_flags that defaults to
> enabled. So heterogeneous sites that use MIT Kerberos as their KDCs
> (not AD) should also be seeing this issue.
>
> At least so far, we *think* the best course of action is to always set
> the TRUSTED_FOR_DELEGATION flag for Linux hosts in AD, so that
> credential delegation won’t depend on whether the Kerberos library
> that any specific host uses pays attention to the OK-AS-DELEGATE flag.
> And this does seem to be the intention of the TRUSTED_FOR_DELEGATION /
> OK-AS-DELEGATE flags: it’s advice to Kerberos clients that it’s OK to
> delegate credentials to the target host, which is exactly what we want
> to happen.
>
> The only thing we’re not completely sure about is whether setting the
> TRUSTED_FOR_DELEGATION flag in AD will have other security
> ramifications that aren’t clear from Microsoft’s documentation. Which
> is why I was hoping that others on this list have already been down
> this particular road and could offer advice.
>
> ________________________________________________
> Kerberos mailing list Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos

--
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc

1
server_pubkey.txt

rocksolid light 0.9.8
clearnet tor