Yesterday I was at a site where they decided to change the service account for the SQL Server services on a set of systems. After changing the service accounts, SQL Server restarted just fine on all machines except one.
I had used the SQL Server Configuration Manager to make the changes (important to not just use the Services applet in Administrative Tools) but I got the typical error telling me that the service wouldn’t start in a timely fashion. The server was running SQL Server 2008 R2 SP2.
Looking in the system event log produced the following errors:
The SQL Server (MSSQLSERVER) service terminated with service-specific error %%-2146885628.
A fatal error occurred when attempting to access the SSL server credential private key. The error code returned from the cryptographic module is 0x8009030d. The internal error state is 10001.
I spent a while looking for info on the last error and found a site where they discussed that it was generated when the service account could not read the machine keys that were stored in the C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys folder. The article then discussed how to add read permissions for the keys one by one.
It suddenly dawned on me that it was probably a problem with the permissions on the folder instead. Checking the permissions on that folder made me realize that the local Administrators account should have the ability to read it. The service account was meant to be a member of the local Administrators account but had not been added to that group on this machine.
Adding the service account to the local Administrators group on the machine (note: not the domain administrators account) fixed the issue and the service started again, until I could get the correct account permissions set in the morning when other staff came back. (In the comments I've added a list of what's actually required).
Hope this helps someone else. (And helps me the next time I see this and have forgotten what it was J)
but what was the actual root cause, we can fix lots with local admin, but dare say break a lot of policies in the process
Too true Dan. This was a case of getting back functioning (no-one else around) until I could get the account updated in the morning. The minimum required for a SQL Server service account is:
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 Server Active Directory Helper
Permission to start SQL Writer
Permission to read the Event Log service
Permission to read the Remote Procedure Call service
Helped me on Saturday after MS security updates were installed. After reboot SQL would not start.
Thanks Mate!
Thank you. Solved it by adding NetworkService to local administrator group.
Thanks
Thank you very much, it worked for me.
Thanks !!! It worked for me just by adding NetworkService to the local administrator GROUP.
That will get you working Varun but note the list above of which permissions you should actually be assigning.
We're in a situation where we have to remove all accounts from Local Admins except what is absolutely required. SQL Server can live without, but it takes work. In my experience with this very scenario, I ran ProcMon on the server where SQL would not start and found exactly which cert file it wanted to access. I then granted our SQL service domain account Full Control to that file only. SQL then started successfully.
Best option is to use the SQL Server Configuration Manager to set the required permissions.
There is a list of what's actually required here: https://msdn.microsoft.com/en-AU/library/ms143504.aspx
Yes, I know that you should use SSCM when you are CHANGING to a different account or the password because it will set all of the appropriate permissions for SQL to run properly. However, if you read through that KB, it does not cover the SSL certs that SQL may use. And we were not changing our accounts or our passwords; we were removing the existing SQL Server service domain account from Local Administrators. That requires re-permissions all down the line. So just as an FYI for anyone else who may find themselves in a similar situation…
How can I give SQL Servicedomai accoutn foolowing permission ?
Permission to start SQL Writer
Permission to read the Event Log service
Permission to read the Remote Procedure Call service
I have heard during setu sql will grant but it has not happend since after installed SQl I checke the policy for og on as a service (SeServiceLogonRight)
Replace a process-level token (SeAssignPrimaryTokenPrivilege)
Bypass traverse checking (SeChangeNotifyPrivilege)
Adjust memory quotas for a process (SeIncreaseQuotaPrivilege) and the user wasnt there
Perfect! Thanks, It is working here
The next time you are in Vegas, I'll get you a beer. This was my issue as well. After the service started, I removed the service account from the local admin group and instead, gave the service account Full Control over the certificate instead.
I was getting the same error message trying to start the service and attempted all of the steps mentioned above and more 🙂 Nothing worked. What worked was very simple. It was these steps:
For SQL Server 2005 and later versions, to enable encryption at the server, open the SQL Server Configuration Manager and do the following:
In SQL Server Configuration Manager, expand SQL Server Network Configuration, right-click Protocols for <server instance>, and then select Properties.
On the Certificate tab, select the desired certificate from the Certificate drop-down menu, and then click OK.
On the Flags tab, select Yes in the ForceEncryption box, and then click OK to close the dialog box.
Restart the SQL Server service.
You can find more information here: https://support.microsoft.com/en-us/help/316898/how-to-enable-ssl-encryption-for-an-instance-of-sql-server-by-using-mi
Now back to the root cause. I believe my issue was caused by renewing SLL cert and when the old cert dropped and the new one was installed, SQL did not pickup the changes automatically and it was still looking for the old cert.
Hope that helps someone else to solve their issue. 🙂
Thanks Andy this works perfectly
This just saved my day!