Changing the owner of a read-only database which is configured with Log Shipping
When you say "without re setting up LS", are you able to have an outage to fix this?

If so, then look at using tail-log backups and recovering the secondary database to make this change. The high-level process would be:


Stop LSBackup, LSCopy and LSRestore (after ensuring there are no pending copies or restores)
Perform a tail-log backup. The primary DB will now be in recovery and inaccessible
Restore the tail-log backup on the secondary and recover the database. It will now be online.
Change the database owner as required.
Perform a tail-log backup on the secondary. It will now be in recovery and unavailable.
Restore the tail-log to the primary and recover it.
Re-enable your log shipping jobs and manually execute LSBackup, LSCopy and LSRestore


After this, your primary should be back online and your secondary back in a read-only state. As stated, this will cause an outage on your primary but this may be preferable to reinitialising log shipping on a large DB. Also, make sure you test this process in a non-Production environment first, and have the entire process scripted. SQLCMD mode is a great way to run this as you can script the whole process and run from a single script using the CONNECT option to change between your primary and secondary machine.

Tail-Log Backups

SSMS in SQLCMD Mode