RFE: Kerberos5: log failing client principal, not server

[jmuf]

recently came across many errors of the form

230308 17:28:44 5766 XrootdXeq: User authentication failed; Seckrb5: Unable to extract client name;; No translation available for requested principal (p=xrootd/eosproject-i02.cern.ch@CERN.CH).

This message is misleading - the thing that fails translating to a local account name is not the server principal (which is logged here) but rather the one supplied by the client (which is not). Would it be possible to instead log the failing client principal in this case ?
https://github.com/xrootd/xrootd/blob/master/src/XrdSeckrb5/XrdSecProtocolkrb5.cc#L503 has the failing condition but https://github.com/xrootd/xrootd/blob/master/src/XrdSeckrb5/XrdSecProtocolkrb5.cc#L530 then always logs (server) Principal.

(underlying issue in our case was "accidentally" re-using a Kerberos credential cache, in the default location..)

[xrootd-dev]

It certainly would. Now, would you consider creating a pull request that fixes the problem? That way you get complete credit for not only identifying the problem but fixing it as well :-)

…

On Thu, 9 Mar 2023, Jan Iven wrote: recently came across many errors of the form ``` 230308 17:28:44 5766 XrootdXeq: User authentication failed; Seckrb5: Unable to extract client name;; No translation available for requested principal ***@***.***). ``` This message is misleading - the thing that fails translating to a local account name is not the server principal (which is logged here) but rather the one supplied by the client (which is not). Would it be possible to instead log the failing client principal in this case ? https://github.com/xrootd/xrootd/blob/master/src/XrdSeckrb5/XrdSecProtocolkrb5.cc#L503 has the failing condition but https://github.com/xrootd/xrootd/blob/master/src/XrdSeckrb5/XrdSecProtocolkrb5.cc#L530 then always logs (server) `Principal`. (underlying issue in our case was "accidentally" re-using a Kerberos credential cache, in the default location..) -- Reply to this email directly or view it on GitHub: #1948 You are receiving this because you are subscribed to this thread. Message ID: ***@***.***> ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-DEV list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1

[jmuf]

It certainly would. Now, would you consider creating a pull request that fixes the problem? That way you get complete credit for not only identifying the problem but fixing it as well :-)

Looks simple, but have not done this, since the data to be printed (from deep inside the Kerberos service ticket) will be cleaned up before we hit that particular Fatal() log line - so would need to have two 'Fatal()' (then do the cleanup in two places), or copy to some temporary string (and clean that up). There probably is some project-wide "how to do this best"-approach here..

[abh3]

The following krb5 function can convert the principal structure to a printable name:

https://web.mit.edu/kerberos/www/krb5-latest/doc/appdev/refs/api/krb5_unparse_name.html

This is a generalization of another more complicated method:

https://web.mit.edu/kerberos/www/krb5-latest/doc/appdev/refs/api/krb5_unparse_name_ext.html