On 7/19/21 10:32 AM, Tobias Kritten (EXT) wrote:
> [libdefaults]
> default_realm = WORKSTATION.OFFICE
> [realms]
[...]
> WORKSTATION.OFFICE= {
[...]
> }
> CORPORATE.LOCAL = {
[...]
> auth_to_local = RULE:[1:$1@$0](.*@CORPORATE\.LOCAL)s/@.*//
> }
auth_to_local is always looked up in the default realm, not in the realm
of the principal being authorized. This is why the rule has to do the
annoying dance of explicitly including the realm in the [] part,
matching it in the () part, and removing it in the s// part. Fixing
this historical botch isn't trivial since the obvious fixes would be
likely to break existing deployments. (The same problem applies to
auth_to_local_names, which is even worse since there's no workaround
aside from not doing any cross-realm.)
> [Tue Jul 06 12:08:41.148773 2021] [auth_gssapi:error] [pid 30765:tid
> 140024582170368] [client 192.168.212.52:0] GSS ERROR gss_localname() failed:
> [The operation or option is not available or unsupported (No such file or
> directory)]
The error message is obscured due to a fallback in the mechglue with
insufficient attention to error prioritization. Better prioritization
would yield GSS_S_FAILURE with a minor code of KRB5_NO_LOCALNAME ("No
local name found for principal name").
________________________________________________
Kerberos mailing list [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos
