Not sure if it is helpful for debugging (other than you get caller stacktraces and a logfile) but for audit purpose a single consolidated event which allows to see which real, which kdc, which ciphers and Idendity might be a thing useable even in production. Especially if also SSPI/native cache is involved.
It’s a similar usecase to the TLS handshake events which you can use to check if a cipher you want to remove is still used. Horváth Péter Gergely wrote on 15. Mar 2024 23:25 (GMT +01:00): > Hi Sean, > > This is a tough question. I guess maybe the same granularity as the log > messages: that is, > emitting a JFR event for every step where now a log message is logged, > with similar parameters > would probably make sense? > > At the same time, would anyone use JFR events to debug a Kerberos issue? I > am unsure about that. > What do you think? > > Best, > Peter > > > > > > > > > > > Seán Coffey <sean.cof...@oracle.com> ezt írta (időpont: 2024. márc. > 13., > Sze, 10:53): > >> >> On 13/03/2024 01:40, Wei-Jun Wang wrote: >> >> Thinking about this raises the question: wouldn't it be possible to have >> these components emit Flight Recorder events as well? >> I understand this is a dubious topic, as some arguments contain secrets, >> but it would be interesting to know. >> Maybe restricting FR events when security debug logging is enabled >> anyways would be an option? >> >> Seán is our expert on JFR events. He has already created some >> security-related events, like provider loading and security properties >> access. You can tell him what else you are interested in. >> >> Using JFR events is certainly worthy of discussion. What would those JFR >> events looks like ? Would you propose one for each log action currently >> in >> the krb5 code ? It becomes unmaintainable IMO. >> >> The suggestion has also been made for the TLS logging code in the past. >> It's not trivial to convert every log entry to a JFR event. A typical >> client/server handshake in TLS can generate 1000's of lines of log output >> with -Djavax.net.debug=all enabled. It doesn't translate easily to JFR >> events. Reading text is probably easier also. >> >> On a related note, I think the current TLS logging is too verbose at the >> moment. Over 3,500 lines of output are generated before a ClientHello >> gets >> created in a typical TLS debug capture. It's too much. Most of it is >> iterating over certs found in the truststore (cacerts by default). Need >> to >> log a bug on that. >> >> regards, >> Sean. >> > Gruß Bernd — https://bernd.eckenfels.net
