To put what Polynomial is saying another way, if you are trying to make it so that encryption works for user data so that only the user and administrators can get to it, the critical piece is to not store the ability to get the information on the server. For users, this is done via their password, for administrators, it is done through their private key (which can also be tied to a password.)
For each user account, you make a new symmetric key. You store that key encrypted based on the users' password so that only the user can get at that version. You then also store the same key but encrypt it using the public key of the administrator, this ensures that the second copy of the user key can only be accessed by the holder of the administrator private key. If the user's password needs to be administratively changed, the administrator can then decrypt the user key with their private key and re-encrypt it based on the user's new password.
Ultimately, the primary limitation is that the administrative user still has to provide the private key to do anything, so I'm not sure if this fits your use case or not. If you need the system to be able to reset a user's password automatically, then you have to have a way to get at the encryption key to re-encrypt it with the new user password.
While you are correct that it doesn't add much security, I would say that your best bet for defense in depth via multiple storage locations (if you don't have any better option) is to use multiple nested encryptions with different keys. ie, store a full, different symmetric key at every location, and require each key to be used in sequence for the data key decryption and rotate them regularly. I must emphasize that this adds a minimal amount of protection, but it does at least make the best of a bad situation if you must have the ability to automatically access the protected data.