• Joie Andrew - Saturday, September 30, 2017 2:31 AM

    While generally I think that is true I have found that if using PowerShell to run SharePoint admin functions you need to ensure that the SharePoint admins (or their group) needs db_owner rights in the SharePoint databases they will be working against, and possibly dbCreator and securityAdmin server rights if creating new service apps or content dbs. While going through Central Admin all these actions tend to get performed by the farm account on the database when going through PowerShell it is using the context of the user running the PowerShell prompt. That has been my experience, anyway.

    As I said, if they are not the SQL Server admin and responsible for the backups/restores, patching, on-call, etc. there is no reason to give a sharepoint admin elevated access.

    Creating new service apps or content databases is not a daily or regular activity and if creating apps and content databases is happening frequently, there seems to be a problem in defining how sharepoint should be setup,how it needs to be configured and how it's used. So even more of a reason to not allow elevated permissions. Permissions needed for installation or migration is different than day to day.
    Sharepoint admins doing regular activities via Powershell rather than Central Admin console would be a choice rather than a requirement.
    If nothing else and someone was forced to provide elevated permissions, I still wouldn't give a sharepoint admin elevated privileges as it's just not congruent with the principles of least privileges. I would create an account that is normally disabled and only temporarily enable it when absolutely needed during a maintenance or change window, especially if they are adding databases, making SQL Server security changes for something they do not support.

    Sue