Currently, the "create session" audit record contains the original (unauthenticated) session id. This makes it harder to correlate this audit record with other ones for a given session.
create session: 9021703545DFB2689ED2957010DFA75E (incorrect)
add object (request): E5B3FFFD660B9E2699F43DE8A1877727
add object (execution): E5B3FFFD660B9E2699F43DE8A1877727
terminate session: E5B3FFFD660B9E2699F43DE8A1877727
This is by design, as described e.g. in Spring Security FAQ, point "46.2.9 Why does the session Id change when I authenticate through Spring Security?"
With the default configuration, Spring Security changes the session ID when the user authenticates. If you’re using a Servlet 3.1 or newer container, the session ID is simply changed. If you’re using an older container, Spring Security invalidates the existing session, creates a new session, and transfers the session data to the new session. Changing the session identifier in this manner prevents"session-fixation" attacks. You can find more about this online and in the reference manual.
The fix would consist of finding the new session id and using that for the audit record. It is not clear if it is possible at the moment of logging-in.