This was reported to me from a co-worker who managed to trigger it in our internal Siptrack, so I have yet to test it fully but I'm pretty sure of the following.
When I implemented encrypted attributes I did not consider that there is a feature to change the password key of a password.
So most likely that feature is only updating the encrypted password and not the encrypted attributes of that password.
So when the update is made that node in Siptrack will crash with an exception that it cannot decode the encrypted attribute content.
For now, don't change password key on passwords with encrypted attributes.
I've been forced to delete the encrypted attribute directly from the DB to get rid of the error because getOID can't even fetch the object to run delete() on.
This was reported to me from a co-worker who managed to trigger it in our internal Siptrack, so I have yet to test it fully but I'm pretty sure of the following.
When I implemented encrypted attributes I did not consider that there is a feature to change the password key of a password.
So most likely that feature is only updating the encrypted password and not the encrypted attributes of that password.
So when the update is made that node in Siptrack will crash with an exception that it cannot decode the encrypted attribute content.
For now, don't change password key on passwords with encrypted attributes.
I've been forced to delete the encrypted attribute directly from the DB to get rid of the error because getOID can't even fetch the object to run delete() on.