There are a few exceptions in the user APIs for call backs to the CUA even if redistribution and local SCUM is not set. There are also two passive CUA tolerances for CREATE1 and DELETE which redistribute based on authorizations and not CUA settings.
I think we are getting warmer here...
My explanation -> the user was deleted but still had address data and PPOME assignments. PFUD was / is not running. Then the user ID was recreated (intended for a different person?) and saving in SU01 runs PFUD in their release for indirect assignments as well. The user ID is still mapped in Infotype 0105 and reconnects to the HR-OM role which the "person" still has.
The best way to avoid this is by never deleting user IDs (hard to avoid in CUA) and ensuring unique names and authorizing the redistribution user centrally to only do text comparisons.
In the special case of SMSY the user names follow a naming convention, so if CUA is not on the SOLMAN logical system then I authorize the SOLMAN callback user (only) as if it is a client to send the user to the SOLMAN to than the system can be connected. The roles can then either be added manually or via PPOME (which is perhaps what was attempted here).
Cheers,
Julius