Category Archives: DISA

PKI certificate autoenrollment fails on Windows 7

Today is a blogging double-feature!  If your network has any type of security hardening (e.g. FDCC, DISA STIG, etc.) you may end up in a situation where your Windows 7 and 2008 R2 machines are not autoenrolling for PKI certificates from your internal enterprise CA.  We found that the following two settings must be enabled in policy:

1. NETWORK SERVICE must be given the “Access this computer from network” user right.  This allows the machine to enroll certificates.
2. The “Task Scheduler” service on the target machine must not be disabled.  The Certificate Services Client uses this service to autoenroll PKI certs.


SQL Server 2008 installs in a DISA-compliant environment

If you’re running a SQL Server 2008 install on a server that is compliant with the DISA STIG, you should be aware the certain default administrator permissions are removed.  These permissions are expected by the installer and installation will fail with a cryptic ‘ACCESS DENIED’ error.  You must ensure the administrator account you are using to run the installer has the following permissions:

Local Policy Object Display Name User Right
Backup files and directories SeBackupPrivilege
Debug Programs SeDebugPrivilege
Manage auditing and security log SeSecurityPrivilege

More than likely, these are managed by Group Policy, so you’ll have to get your domain management guys involved to fix the issue.


SCOM 2007 R2 Agent Reporting Issues with DISA/FDCC

We are in the middle of developing a new XP SP3 image for SCCM deployment to newly added workstations.  One of the applications we install with the deployment sequence is the SCOM 2007 R2 Agent.  Recently, I discovered that our test machines with the new image were not reporting to the Operations Manager Server.  Inspecting the log, I noticed a number of 21405 errors:

The process stated at <time> failed to create System.Discovery.Data, no errors detected in the output. The process exited with 1 Command executed: “C:WINDOWSsystem32cscript.exe” /nologo “DiscoverWindowsComputerProperties.js”…

Well, it turns out that the DISA Desktop Application STIG (pages 4 and 5) requires systems to have the default actions for JS and VBS files altered.

To fix this issue, both filetypes must be reassociated to run using either cscript or wscript.  There are a number of resouces on the Interweb to do this type of task.  In our case, I created a WSF script and put it into an SCCM software package to deploy to the affected computers.  I will post the script files if there is interest in them.

Special thanks to Graham’s blog post in aiding our troubleshooting of the issue.