Had a very unusual issue recently on a hardened SharePoint environment (read: set up according to Microsoft Best Practices).
I was trying to install a feature, and I was getting a response back… Access Denied. Nothing really unusual in that… I must have forgotten to set myself up as a farm admin again… except in this case I was already a farm administrator. So… what could be causing that problem?
It turns out that Microsoft decided that in order to install a feature, being a Farm Administrator is simply not enough – you have to be a SysAdmin on the SQL Database as well. Huh? Where’d the "Least Privilege, best-practice" thinking go when they set up that trap?
So I log into the SQL database and add myself in as a SysAdmin, and tada! I’m able to successfully deploy the feature. I honestly would have thought that the application would have verified your credentials, then once confirming you are a farm administrator, run the feature installation under the SharePoint admin account (which has all the required DB Access). But Nooooooo, not this time!
If anyone knows why this might be the case, I’m interested to hear from you. To me, it makes no sense and works against least privilege configuration.