In securing a SQL Server to DoD STIG one process includes restricting permissions on the service account(s). Part of that inclues removing the service account from Administrators group locally on the server.
I did this on a SharePoint server at work that is Window Server 2003, WSS 3.0, and SQL Server 2008 SP1. However the only way I could get the service account to function with SQL as a non-Administrator was to add it to SQLServerMSSQLUser$hostname$MSSQLSERVER group.
Now my question is how would you go about finding out what special permission that group had in order to make the server start. I went through the security template and found the account (not group, but actual username for the service) was configured with the appropriate OS permissions (start as service, etc) that went along with MS docs.
I know I can use this to find the file level permissions (http://support.microsoft.com/kb/825751), is there something similar that I can use for a user account's OS permissions?
- Edited by ShawnMelton Friday, June 18, 2010 2:29 PM
The SQL Server Configuration Manage is smart enough to give the login that starts SQL Server the required permissions. The easiest way for you to set the permissions, is to use SQL Server Configuration Manager to change the login from X to Y, and then (if you want) change it back to X. Then Configuration Manager should set all the required permissions for X.
Rick Byham, Microsoft, SQL Server Books Online, Implies no warranty
True, however in this particular instance I'm not able to access these services from Configuration Manager. The only service showing is Intergration.
On the other side of that though the Windows DoD STIG can effect WMI which in turn can prevent the configuration manager from applying all permissions correctly. Either way, I have verified through the BOL that show the permissions needed by the SQL Service, SQL Agent Service account to function. Those are set for the service account, but unless that acocunt is a member of the SQLServerMSSQLUser group the service will not start.
I have a customer that I would like to move to SQL Server 2008, but I don't see a SQL Server 2008 STIG. Is your customer allowing you to apply the SQL Server 2005 STIG or do you have specific guidance for SQL Server 2008?
I don't see SQL Server 2008 listed in the database STIGs:
And I don't see a draft listed:
I don't think my customer will move without specific guidance being available.
You should use AccessChk tool to find what permissions a windows login account has on the machine in question.
It will answer on what kind of accesses specific users or groups have to resources including files, directories, Registry keys, global objects and Windows services.
Sivaprasad S http://sivasql.blogspot.com Please click the Mark as Answer button if a post solves your problem!
DoD has not released a STIG for SQL Server 2008, I have heard they are working on it. I doubt it will come out until the STIG comes out for Window Server 2008, I don't know for sure.
My customer is military so we apply the SQL 2005 STIG to SQL Server 2008, it's the only thing we have. Most of the findings in the STIG for 2005 can be applied to SQL 2008. There may be a few things that just can't be applied simply because the feature set or configuration changed just a little. Things that this are rare so far with what I have done. I have not tried STIG'n SSIS or SSAS though.
I don't suppose you know where one could find the SQL Query's for SQL Server 2008 that coorolate with the Vulnerability Key's. I'm not a SQL developer at all, but I do have some experience with SQL queries. However, as you've already said, the DoD still has not come out with a STIG for SQL 2008. So, in order to STIG a SQL database, one must cypher the scripts from 2005 and convert them to something SQL 2008 will understand.
Has anyone written a script that covers the queries in the 2005 STIG?
Thanks in advance,
While performing your SQL 2005 STIGs for SQL 2008, did you review http://support.microsoft.com/kb/841057 and did you encounter any issues regarding voiding support? Even just checking for compliance (SELECT statements) could potentially void support until reverted.
One issue is the KB itslef tlaks about what is/is not supported, then add the fact that this is not even an SQL 2008 STIG.
Added question: Maybe wrong place, but for IIS STIGs similarly, is there a KB article listing what and what not to touch/configure?
If you are checking for compliance you are not making any changes, so how would that void support?
The IASE STIG checklist are prepared by DISA and Microsoft. Microsoft is the one that helps DISA write these checklist. It all comes down to understanding what changes you are making, why, and what affect they have. If you work for a company that is required to be compliant with DoD STIGs, Microsoft is well aware of these standards and requirements. You should have no problem getting support issues resolved.
Majority of what a STIG requires will not break SharePoint or most other Microsoft products that utilize SQL Server.
For example, a check asks you to run a SELECT statement for EACH database.
A fix for a finding asks you to ALTER PROCEDURE [...]
Wont there be issues with <http: 841057="" kb="" support.microsoft.com=""></http:>with regards to changing existing stored procedures and also in the read addendum section? Microsoft preparing these with DISA does denote that they would be able to support. Do we know any documentation, kb article or what not that specifies this?