RE: Question about Windows S4U support
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
Sent: Friday, November 10, 2023 6:44 AM
To: JianJun Li ; kerberos@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@mylab.com" exists. By
> Wireshark I can see Windows sends "host/win11client.mylab@mylab.com" as
> sname, KDC converts the sname to host\/win11client.mylab@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@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.
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Question about Windows S4U support
On 11/8/23 09:23, JianJun Li wrote:
In fact, principle "host/win11client.mylab@mylab.com" exists. By Wireshark I can
see Windows sends "host/win11client.mylab@mylab.com" as sname, KDC converts the
sname to host\/win11client.mylab@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@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.
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
RE: Question about Windows S4U support
Thank you Ken for the valuable feedback.
I'm using latest version V1.21 with its default backend DB. After the test, if
all works, I will try the combination MIT KDC + OpenLDAP then.
There are not so much available materials I can refer to like my case.
Sometimes I really doubt Windows S4U API may be not completely compatible with
MIT KDC, but based on current investigation, I still can't draw any
conclusions. That's why I post comments here.
Regards
Jianjun Li
-Original Message-
From: Ken Hornstein
Sent: Thursday, November 9, 2023 3:17 AM
To: JianJun Li
Cc: kerberos@mit.edu
Subject: Re: Question about Windows S4U support
EXTERNAL EMAIL
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@mylab.com<mailto:host/win11client.mylab.com@
>MYLAB.COM> for host\/win11client.mylab@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/win11cli...@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\/win11cli...@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
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.
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Question about Windows S4U support
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@mylab.com
> for host\/win11client.mylab@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/win11cli...@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\/win11cli...@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
Question about Windows S4U support
Hi everyone,
We have an application with Windows client + AD domain, for S4USelf, it works
well.
In our application, it calls LSALogonUser() to impersonate a user which will
use S4USelf by setting up Windows structure KERB_S4U_LOGON.
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.
Problem 1:
When LSALogonUser() is called, it has following error:
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@mylab.com
for host\/win11client.mylab@mylab.com, Server not found in Kerberos
database
In fact, principle
"host/win11client.mylab@mylab.com"
exists. By Wireshark I can see Windows sends
"host/win11client.mylab@mylab.com"
as sname, KDC converts the sname to host\/win11client.mylab@mylab.com.
I have a look at the code but find no parameters or setting can change this
behavior.
Problem 2:
Sometimes, AS-REQ and TGS-REQ are all ok in MIT KDC but on Windows, it reports
this error in Windows Event Viewer after call LSALogonUser():
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 also test "kvno -U user" on the same windows machine, and it works.
>From MIT Kerberos document, I can see S4U can be supported. My question is
>that for S4U, does MIT KDC have interoperability with Windows API? Any
>feedback will be greatly appreciated.
I'm a newbie in Kerberos, thanks for your help!
Regards
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.
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
