[39302] in Kerberos

home help back first fref pref prev next nref lref last post

Re: Question about Windows S4U support

daemon@ATHENA.MIT.EDU (Ken Hornstein via Kerberos)
Wed Nov 8 14:18:45 2023

Message-ID: <202311081916.3A8JGiOG013874@hedwig.cmf.nrl.navy.mil>
To: JianJun Li <jjli@rocketsoftware.com>
cc: "kerberos@mit.edu" <kerberos@mit.edu>
In-Reply-To: <DM6PR07MB4651D6917435E9AF74528364BBA8A@DM6PR07MB4651.namprd07.prod.outlook.com>
MIME-Version: 1.0
Date: Wed, 08 Nov 2023 14:16:43 -0500
From: Ken Hornstein via Kerberos <kerberos@mit.edu>
Reply-To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu

I am DEFINITELY not an expert in S4U* nor Windows APIs, but I have
looked into this a BIT and I can give you some thoughts.

>Now we wants to switch from Windows AD to MIT KDC. Currently windows
>can be authenticated by MIT KDC without any problem but Windows API
>LSALogonUser() in our application fails.

It should be noted that up front that there are some caveats to MIT
Kerberos S4U support.  The specific one that I am aware of is that
you cannot use the db2 database (the default) as the KDC backend;
you need to use the LDAP KDB module and configure a special attribute
called "krbAllowedToDelegateTo" to configure a service principal to
permit S4U2Self.  I am not sure this is relevant to this discussion
though.

>Nov 03 14:01:40 niuniu krb5kdc[13724](info): TGS_REQ (5 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), DEPRECATED:arcfour-hmac(23), DEPRECATED:arcfour-hmac-exp(24), UNSUPPORTED:(-135)}) 192.168.0.5: LOOKING_UP_SERVER: authtime 0,  host/win11client.mylab.com@MYLAB.COM<mailto:host/win11client.mylab.com@MYLAB.COM> for host\/win11client.mylab.com@MYLAB.COM, Server not found in Kerberos database

It's important to understand that INTERALLY Kerberos principals are
represented as a sequence of one or more strings and a realm.  So while
you may see a principal in the form of "host/win11client@MYLAB.COM"
that's just the user representation.  Really that's encoded on the wire
as the strings "host" and "win11client", and the realm MYLAB.COM.  If
MIT Kerberos is displaying that as "host\/win11client@MYLAB.COM", then that
means it's getting ONE string for that principal that contains
"host/win11client" (the '/' is the traditional separator for strings
in a Kerberos principal).  I have no idea why that is happening, but
that suggests to me that there is some problem on the client side.

--Ken

________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

home help back first fref pref prev next nref lref last post