1

Our database is running on SQL Server 2008 hosted on a Windows 2008 Server. We have found that the security policy “impersonate a Client after authentication” is enabled for the SQL Server service account. Will removing “impersonate a Client after authentication” cause any issues? is this URA required for SQL to function correctly. The database hosted on this instance is a client-server application.

2
  • If you have installed optional components such as ASP.NET or IIS, you may need to assign the Impersonate a client after authentication user right to additional accounts that are required by those components. – Md Haidar Ali Khan Sep 1 '15 at 10:03
  • Thanks for the reply Mr. Haider. We have nothing else installed on the SQL server. However the application that connects to it is an .net based application that uses SPNs. – Orion Sep 1 '15 at 10:06
2

The documented Windows Privileges and Rights for the database engine service account are:

  • Log on as a service (SeServiceLogonRight)
  • Replace a process-level token (SeAssignPrimaryTokenPrivilege)
  • Bypass traverse checking (SeChangeNotifyPrivilege)
  • Adjust memory quotas for a process (SeIncreaseQuotaPrivilege)
  • Permission to start SQL Writer
  • Permission to read the Event Log service
  • Permission to read the Remote Procedure Call service

The SeImpersonatePrivilege is only documented as required for the SSIS service.

That being said, I will say that the SeImpersonatePrivilege privilege is required for the database engine. Windows Authenticated client connections impersonate the client when accessing OS resources like SSPI linked servers and network shares (think db attach, backups etc).

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.