June 12, 2017 at 2:55 pm
Does anyone have any guidelines or best practices regarding SharePoint admins access level to the SQL Server? I looking at more individual admin not SharePoint service accounts.
June 13, 2017 at 12:29 pm
Ryan D. - Monday, June 12, 2017 2:55 PMDoes anyone have any guidelines or best practices regarding SharePoint admins access level to the SQL Server? I looking at more individual admin not SharePoint service accounts.
Is the Sharepoint admin going to be the DBA? Are they taking responsibility for the server and instance including patches, upgrades, on-call duties, backups/restores, all maintenance, etc?
If not, they don't need any special or elevated access to the database end as they can do what they need through Central Administration in Sharepoint.
Sue
September 30, 2017 at 2:31 am
Sue_H - Tuesday, June 13, 2017 12:29 PMRyan D. - Monday, June 12, 2017 2:55 PMDoes anyone have any guidelines or best practices regarding SharePoint admins access level to the SQL Server? I looking at more individual admin not SharePoint service accounts.Is the Sharepoint admin going to be the DBA? Are they taking responsibility for the server and instance including patches, upgrades, on-call duties, backups/restores, all maintenance, etc?
If not, they don't need any special or elevated access to the database end as they can do what they need through Central Administration in Sharepoint.Sue
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.
Joie Andrew
"Since 1982"
October 2, 2017 at 7:59 am
Joie Andrew - Saturday, September 30, 2017 2:31 AMWhile 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
August 2, 2018 at 7:40 pm
This was removed by the editor as SPAM
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply