If you want the data to be absolutely inaccessible by administrators, then unencrypted data can never hit the servers they control. Additionally, the decryption key can't be on the server either, since if it was, a malicious administrator could grab both the encrypted data and the key, and decrypt it.
So, what options do you have?
Client side encryption. If the end user encrypts data using a key which is never sent to the server, and the encrypted data is sent to your server, there is no way for the administrator to decrypt it, but the user can download and decrypt, as long as they have the key. It would be better to encrypt with a key derived from a password than from the password itself, just from a key length perspective - this is nothing uncommon though.
The problem you have with this, if you're worried about administrators trying to access data, is that they can presumably modify the encryption code sent to the client, if you're using JS - they've got access to the server. It wouldn't be particularly hard to encrypt the data twice, once with the user key and once with a key known to the admins. You can prevent tampering in transit (that's why you've got SSL enabled), but the admin that can edit the site contents can probably edit any checksums used to preserve the integrity of the client side code too.
Require that the user encrypts before sending. If the end user uses a third party encryption application, your admins can't do anything about it, other than brute force, which should be difficult. However, it does reduce your service to a file store, which might not be acceptable.
Spread the risk. Have a server which serves the encryption routines to the client, which is managed by company A. Have a server which receives encrypted data and stores it, which is managed by company B. Have the rest of the web application on a server managed by company C. End user receives encryption code from server A, which is presumably unmodified, since the admins of that server never see the encrypted data, and can't modify the code without breaking checksums which are served from server C. Their computer encrypts with the client side key (which is never sent anywhere), and sends the data to server B.
The admins from A can't tamper with the encryption, or where the data is sent unless they collaborate with the admins from C. The admins from C can modify where the data is sent, or send incorrect encryption routines, but B can report if they're not getting any data. The admins from B would have to get either admins from C to pass them the key, or the admins from A to modify encryption routines to gain access.
Now, this seems like a very complicated scenario, but that just shows how much power the server admins have - by definition, they've got access to read and modify pretty much anything.
You basically get into a trade off between ease of maintenance and security - option 1 is easy to maintain, since you have full control of the server from a single point. Option 3 is difficult, since you have to co-ordinate any changes between multiple administrators, but makes it really difficult for any individual one to get hold of the data. Whether it's worth that effort depends on the data being stored.
