Forum Discussion
Potential Impact of Removing Domain Admin Privileges from a SharePoint Service Account
Hello,
We are currently reviewing the security configuration of our SharePoint infrastructure as part of an initiative to implement the principle of least privilege.
We have an Active Directory service account named spsqladmin, which is currently a member of the Domain Admins group.
This account is used to run several SharePoint and SQL Server services across our infrastructure.
Our infrastructure consists of:
- 2 SQL Servers: The account runs SQL Server and SharePoint-related services and is a member of the local Administrators group on both servers.
- 1 SharePoint Application Server: The account runs SharePoint services and is a member of the local Administrators group.
- 1 SharePoint Web Front-End Server: The account runs SharePoint services and is a member of the local Administrators group.
- 1 SharePoint Search Server: The account is not explicitly a member of the local Administrators group.
- 1 Office Online Server: The account is not explicitly a member of the local Administrators group.
Our objective:
For security reasons, we would like to remove the spsqladmin account from the Active Directory Domain Admins group while keeping the same account for the existing SharePoint and SQL Server services.
We want to ensure that this change does not affect the availability or functionality of our SharePoint environment.
Our questions:
Is there any potential impact on SharePoint or SQL Server services if we remove this account from the Domain Admins group?
Thank you in advance.
3 Replies
Yes, you can remove spsqladmin from Domain Admins, and this is generally recommended under the principle of least privilege. However, you should verify its actual permissions before making the change.
Potential impact
SQL Servers: SQL Server services generally do not require Domain Admin privileges. Local Administrator membership may still be excessive.
SharePoint servers: SharePoint services require specific permissions, including database permissions and service-specific privileges. Local Administrator membership alone may not be sufficient.
Search Server: Verify service account permissions and access to required databases and resources.
Office Online Server: Verify whether the account is actually used by any services or integrations.
Recommended approach
Identify all Windows services, scheduled tasks, and application pools running under spsqladmin.
Review SharePoint service account requirements for your installed SharePoint version.
Verify SQL Server permissions, database ownership, and required service permissions.
Check Group Policy and any permissions inherited through Domain Admins.
Remove Domain Admin membership in a test environment first.
Monitor SharePoint, SQL Server, and Windows event logs after the change.
Important recommendation
Do not remove Domain Admin privileges and assume that local Administrators membership will cover everything. Domain Admin membership may provide additional permissions through AD groups, ACLs, or policies.
My advice: Removing Domain Admin membership is the right security objective, but migrate to appropriately scoped service accounts and permissions rather than simply relying on local Administrator rights.
Also, consider using Group Managed Service Accounts (gMSA) where supported by your SharePoint and SQL Server versions.
Removing Domain Admins from that account is the right goal, and Microsoft's guidance for SharePoint is that none of the farm or SQL service accounts should be Domain Admins. There can be an impact, because accounts that have been Domain Admins for years often pick up dependencies nobody remembers. The ones I would check before you change anything:
- SPN registration and Kerberos. When a service account is a Domain Admin, SQL Server and the web applications can register their own SPNs. Without that right, registration quietly fails and clients fall back to NTLM or the double hop breaks. List what is registered with setspn -L spsqladmin, and create the SPNs manually (or give the account the validated write to SPN permission) before the change.
- Active Directory import. If the User Profile Service imports from AD, the import account needs the Replicate Directory Changes permission on the domain, which Domain Admins had implicitly. Give that to the account that does the import, and not to the farm account.
- Rights on the servers. The account needs Log on as a service, and for SQL the usual rights (Perform volume maintenance tasks, Lock pages in memory if you use it). Check them with secpol or the local policy on each server, since a group policy may have been depending on Domain Admins.
- Things outside the services. Look for scheduled tasks, SQL Agent jobs, backup jobs, file share access, linked servers, and Windows services that run as this account on any machine, because those quietly keep working only because of the broad rights.
- Local Administrators on the SQL and SharePoint servers is the next layer to remove, but do it as a second step after the Domain Admins change, so you can tell which change broke something.
A safe way to run it: use one account per role (SQL service, farm, app pools, search crawl, profile sync) as in the SharePoint plan for administrative and service accounts, test on a non-production copy first, make the change in a maintenance window with the rollback being to put the account back in the group, and afterwards restart the services and test a search crawl, a profile sync, a SQL backup and a Kerberos login while watching the ULS logs, the SQL error log and the event logs.
