To:
kerberos@mit.edu (
kerberos@mit.edu)
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").
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)