In the current SSPR version, loginDisabled must be set to FALSE before the User Activation or as a PRE Activation Action in the User Activation, to allow the user activation process to complete.
Otherwise it fails with: SSPR 5065 (Account is disabled).
However, it would be very benefitial to not have this requirement hard coded into SSPR.
For us, there there is another process (controlled by IDM) that will actually control the final loginDisabled value. Having SSPR influence this causes process issues, as there is no way of having other steps AFTER the User activation step, before loginDisabled is set to FALSE.
Also, flipping loginDisabled to FALSE, then TRUE as part of the User Activation, would not work either, as there is a set of actions that follows the change of loginDisabled and flipping it back and forth causes all kinds of issues.
Tor Harald Lothe