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/[email protected]<mailto:host/[email protected]>
> for host\/[email protected], 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/[email protected]"
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\/[email protected]", 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 [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos
