Question about Windows S4U support

[JianJun Li]

Thanks for the reply.  One strange thing is that when Windows is using AD domain, sname doesn't have this  format: host/win11client.mylab.com but win11client$.  I have no idea what makes Windows have this difference.

For PAC validation error, I also can't get more detailed information from Windows logging what causes the validation failure.

-----Original Message-----
From: Greg Hudson <ghudson at mit.edu>
Sent: Friday, November 10, 2023 6:44 AM
To: JianJun Li <jjli at rocketsoftware.com>; kerberos at mit.edu
Subject: Re: Question about Windows S4U support

EXTERNAL EMAIL





On 11/8/23 09:23, JianJun Li wrote:
> In fact,   principle "host/win11client.mylab.com at MYLAB.COM" exists.  By Wireshark I can see Windows sends "host/win11client.mylab.com at MYLAB.COM"  as sname, KDC converts the sname to host\/win11client.mylab.com at 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 at 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.

================================
Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy
================================

This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you.