novaBBS - comp.protocols.kerberos - Re: Question about Windows S4U support

Re: Question about Windows S4U support

<mailman.49.1699569849.2263420.kerberos@mit.edu>

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

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: ghud...@mit.edu (Greg Hudson)
Newsgroups: comp.protocols.kerberos
Subject: Re: Question about Windows S4U support
Date: Thu, 9 Nov 2023 17:43:50 -0500
Organization: TNet Consulting
Lines: 48
Message-ID: <mailman.49.1699569849.2263420.kerberos@mit.edu>
References: <DM6PR07MB4651D6917435E9AF74528364BBA8A@DM6PR07MB4651.namprd07.prod.outlook.com>
<5dc6e95e-a862-4cbb-82ef-3d7b9f2af17a@mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: tncsrv06.tnetconsulting.net; posting-host="mailman.mit.edu:18.7.21.50";
logging-data="6924"; mail-complaints-to="newsmaster@tnetconsulting.net"
User-Agent: Mozilla Thunderbird
To: JianJun Li <jjli@rocketsoftware.com>, "kerberos@mit.edu" <kerberos@mit.edu>
DKIM-Filter: OpenDKIM Filter v2.11.0 unknown-host (unknown-jobid)
Authentication-Results: mailman.mit.edu; dkim=pass (2048-bit key,
unprotected) header.d=mit.edu header.i=@mit.edu header.a=rsa-sha256
header.s=outgoing header.b=gQwlDDht
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing;
t=1699569848; bh=d/5E6lC6hzPfcZJqeiFNtTA1bbgW/Krl++w+2JeepO0=;
h=Message-ID:Date:MIME-Version:Subject:From:Content-Type;
b=gQwlDDhtjKTp1i7GkSFlnA2FciEycob+ZOt1o22c0GBVW3veeXV3rXt/LZaC97Zqt
cemfUKBZQsmAh+SzSmOyreKgrtfG3Jv+fkUCZtdoUx0uTAhfJ3hsU7o74AHyHkQRqr
8co+Kc+e7g4ixUQImP0N8tyud4wbJ42BbVLTK4QCZWswQlfP6UnayYldsEA0yAeSee
H3j68k2iTX8eel6x++AQvjwHfsC48F4FPvK/m0L04w827Zwm74fdYFKYBP95JA9BKr
1SyMMpg49c8qPpHCNHN47xpdt/hCeQ5KGalLIeWiiIz9HMRhfMV8goQWlxHJSWw9Pm
2DSBektTGG2JA==
Authentication-Results: spf=pass (sender IP is 18.9.28.11)
smtp.mailfrom=mit.edu; dkim=pass (signature was verified)
header.d=mit.edu;dmarc=pass action=none header.from=mit.edu;
Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates
18.9.28.11 as permitted sender) receiver=protection.outlook.com;
client-ip=18.9.28.11; helo=outgoing.mit.edu; pr=C
Content-Language: en-US
In-Reply-To: <DM6PR07MB4651D6917435E9AF74528364BBA8A@DM6PR07MB4651.namprd07.prod.outlook.com>
X-EOPAttributedMessage: 0
X-EOPTenantAttributedMessage: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b:0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CO1PEPF000042AC:EE_|PH0PR01MB7412:EE_
X-MS-Office365-Filtering-Correlation-Id: c3c909ee-d84a-413e-9a4b-08dbe1755fac
X-LD-Processed: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b,ExtAddr
X-MS-Exchange-AtpMessageProperties: SA
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: C5KIVSwrYqCsHpWneBFKp2A/pip1Q3QxmHLIRmSKVzo1lDDPFAhYi8PCVG7qhtZkWmx2ySlcCN7qeEeMXC0Dg3KurbKqDJsGTxIzxYNED7vWchzCxqx7YmreLlDqkt4TYKLzyRJEK/QbF5Bddjq+yB0JIM/14hpn3j5Se/ORo1God8eL8PNKFQvPJQYdpX+wJ6rvkV0la7h/IDe9Z6A9A3kZ5H+m6pupbjj+VI7rWjm3qM3HeAcoO3pPLrQH5b2399X/UOjMbi53xMDtzEMp9dnKugGUSUXAHNewvCp0YZiti2Y+WDif5yHO71KdOOyHJMfCcdH0Vcj0R8LQuSVth295hTuQwSbQacbBj8ixxF2kkeo30eIdNCxN5zaux1sBRpUV7C5fT+1+hQowfIj0L5Og46vSUUAPKKE8wMJLr0HXyj4jNCm9eNqpU5m8ETBri1Wjvn1ak+pgD+9Qv9GTZozCr4pZwLjU7PllQCkTAIZmvfItFRqcHSKQ2QQnli23hvf7HiREOnAavK9oAKCab88EvMnvX1v+xg7rOlcZtc4hBJikL8PovWqIiVYIDRINYmH3grTJYKlEnsW50mjtuEHkrM2S2kUMXbFJhzjZ2UuJWMRGIQX/iZA79sk0tauSxjgx+Ql0QRczPjXU2gp2HnWO6Q2nr26WSMUMq/06YdAu6S63leu2SroCZVHaxUpMumrNX1nyc0P25u8v26LOI2n0/6bof3oSuWJaOTtpXsyfxCm3Zyr7VoS103l+oeFDZdcuEB3qGvrr2rM8w+M6pg==
X-Forefront-Antispam-Report: CIP:18.9.28.11; CTRY:US; LANG:en; SCL:1; SRV:;
IPV:CAL; SFV:NSPM; H:outgoing.mit.edu; PTR:outgoing-auth-1.mit.edu; CAT:NONE;
SFS:(13230031)(4636009)(346002)(376002)(136003)(39860400002)(396003)(64100799003)(451199024)(1800799009)(8676002)(6636002)(786003)(70586007)(316002)(68406010)(75432002)(110136005)(2906002)(86362001)(31696002)(5660300002)(83380400001)(336012)(426003)(356005)(2616005)(956004)(26005)(31686004)(36756003)(45080400002)(7696005)(478600001)(53546011)(6666004)(43740500002);
DIR:OUT; SFP:1102;
X-Auto-Response-Suppress: DR, OOF, AutoReply
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Nov 2023 22:44:03.1565 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c3c909ee-d84a-413e-9a4b-08dbe1755fac
X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b
X-MS-Exchange-CrossTenant-AuthSource: CO1PEPF000042AC.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: Internet
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR01MB7412
X-OriginatorOrg: mit.edu
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: <5dc6e95e-a862-4cbb-82ef-3d7b9f2af17a@mit.edu>
X-Mailman-Original-References: <DM6PR07MB4651D6917435E9AF74528364BBA8A@DM6PR07MB4651.namprd07.prod.outlook.com>

by: Greg Hudson - Thu, 9 Nov 2023 22:43 UTC

On 11/8/23 09:23, JianJun Li wrote:
> In fact, principle "host/win11client.mylab.com@MYLAB.COM" exists. By Wireshark I can see Windows sends "host/win11client.mylab.com@MYLAB.COM" as sname, KDC converts the sname to host\/win11client.mylab.com@MYLAB.COM.
> I have a look at the code but find no parameters or setting can change this behavior.

I can give a detailed but ultimately not very helpful answer:

As Ken explained in part, the wire representation of principals in
Kerberos is the ASN.1 DER encoding of a name-type and a sequence of
strings. Microsoft created a name type NT-ENTERPRISE which puts an
email-address-like string in the first string element. When you see
"host\/..." in your log, that is the MIT krb5 library's string
representation of an NT-ENTERPRISE principal.

RFC 6806 section 5 describes this name type as conveying alias names, to
be used in the client field of an AS-REQ to a KDC with a directory
service that can map email addresses to canonical principal names.
However, Microsoft's implementation now also uses this type in server
names during under some circumstances, including some S4U operations.
[MS-KILE] 3.3.5.1.1 defines semantics for server name lookup of
NT-ENTERPRISE principals (in terms of underlying facilities specific to
Active Directory); [MS-SFU] unfortunately does not seem to say precisely
when they are used. I had thought they were only used for cross-realm
S4U2Self operations where it is necessary to communicate the requesting
service's realm to the client realm, but based on your log it sounds
like they are also used for same-realm S4U2Self requests made by Windows
clients.

Although MIT krb5 has S4U2Self and S4U2Proxy logic in the KDC code, it
does not implement NT-ENTERPRISE lookup. The translation from
NT-ENTERPRISE {"host/win11client.mylab.com@MYLAB.COM"} to NT-PRINCIPAL
{"host", "win11client.mylab.com"} currently has to be done within the
KDB layer, either by using an encompassing piece of software with a KDB
module (such as Samba), or by setting up an explicit alias in the LDAP
KDB module (the BDB and LMDB modules do not support aliases). I believe
the situation could be improved by performing this translation within
the KDC for TGS service lookups, but that improvement, although simple
in concept, would require careful testing.

> The digitally signed Privilege Attribute Certificate (PAC) that contains the authorization information for client user in realm MYLAB.COM could not be validated.
> This error is usually caused by domain trust failures; Contact your system administrator.

I don't know exactly what is causing this error on the Windows side,
especially if it only happens some of the time. I will note that when
used with any of the built-in KDB modules (BDB, LMDB, or LDAP), MIT
krb5's KDC includes a minimal PAC with no SID or group information.
Encompassing software such as Samba is required to supply a complete PAC
within issued tickets. This limitation may be unrelated to the error
given that the error does not always occur.

She won' go Warp 7, Cap'n! The batteries are dead!

devel / comp.protocols.kerberos / Re: Question about Windows S4U support

Subject	Author
Re: Question about Windows S4U support	Greg Hudson