Stateful session IDs contain a random 64-bit prefix that is generated from a SecureRandom and then encrypted with a hard-coded key: see com.iplanet.dpro.session.SessionIDConstructorHelper#generateEncryptedID for its current location. That code (when it lived in SessionID) used to have the following comment:
As I'm fairly certain that this backwards compatibility has long since stopped being a concern, AM should stop bothering to do this encryption. This is particularly important when AM is configured to use the AESWrapEncryption method, as this uses at least 10,000 rounds of PBKDF2 to derive the encryption key, which will introduce significant performance issues in this session code.
Rather than just replacing this code with some raw random bytes, an alternative would be to actually replace this with a MAC tag computed over the rest of the session ID using some new MAC key stored in the session service (HMAC-SHA256 truncated to 128 bits would be fine, or even something like SipHash if you destroy sessions for which the tag verification fails). This would further harden AM's session integrity protection. I would also recommend increasing the StorageKey to 128 bits at the same time.