In this article we invite Michael Tan, one of our senior program mangers, to introduce a new feature in the recently updated Sysinternals tool called AccessChk. His two part article looks at how the new AccessChk feature works and the benefits of using this Sysinternals tool. The second part takes a look at the using the tool with Configuration Manager’s DCM feature, and how the Security Compliance Management toolkit benefits from the efforts.
Microsoft released the Security Compliance Management toolkit on June 5, 2008, on TechNet and as a free download on the Microsoft Download Center. The toolkit enables organizations to monitor the security compliance state of their IT environments for computers running Windows operating systems by using the Desired Configuration Management (DCM) feature in Microsoft System Center Configuration Manager 2007 as mentioned in recent posts. Now let’s look at a known issue for the toolkit using Resultant Set of Policy (RSOP) Windows Management Instrumentation (WMI) providers for data discovery. Solving this shortcoming of the toolkit can be accomplished by using the newly updated AccessChk.exe, with some custom DCM scripts to obtain the latest user rights assignment data from the Windows Local Security Authority (LSA) store. To make this simple, we include a working sample that customers can use to collect this data directly from the LSA store.
The Security Compliance Management toolkit provides more than 300 security settings, including user rights assignment settings, such as Access this computer from the network, backup files and directories, and so on. The Release Notes in the toolkit include a list of settings. The data collected in the WMI repository from these settings may not synchronize with the data in the LSA store. This is because the data discovery process for the toolkit uses RSOP WMI providers to collect the setting data, and the data is queried from the WMI repository (CIMOM database) that represents existing policies or planned policies. For this reason, the data for these settings may not be consistent with user rights assignment data in the LSA store that is consumed directly by Windows components.
If customers want to obtain the actual security state of the user rights assignments on a target host machine, they must query the LSA store directly instead of using RSOP.
Only native application programming interfaces (APIs) or Win32 APIs are provided for LSA data queries, and these are not supported by the DCM feature in Configuration Manager 2007. To obtain this data, you can use the newly updated Sysinteranls tool, AccessChk.exe (version 4.2), with the DCM feature’s scripting capability to get user rights assignment data directly from the LSA store.
AccessChk.exe provides you with access to the files, registry keys or Windows services for the user or group that you specify. AccessChk.exe now supports a new option -a to query user rights assignment data directly from the LSA store.
First download AccessChk.exe 4.2 from SysInternals.
On a command prompt type AccessChk.exe /?
-a Name is a Windows account right. Specify ‘*’ as the name to show all rights assigned to a user
Here is a partial list of all the user rights assignment that you can access directly from the LSA store:
User Right name in –a option list
Logon as a batch job
Required for an account to log on using the batch logon type.
Deny logon as a batch job
Explicitly denies an account the right to log on using the batch logon type.
Deny Logon locally
Explicitly denies an account the right to log on using the interactive logon type.
Deny access to this computer from the network
Explicitly denies an account the right to log on using the network logon type.
Deny Logon through Terminal Services
Explicitly denies an account the right to log on remotely using the interactive logon type.
Deny logon as a service
Explicitly denies an account the right to log on using the service logon type.
Allow Logon locally
Required for an account to log on using the interactive logon type.
Access this computer from the network
Required for an account to log on using the network logon type.
Allow Logon through Terminal Services
Required for an account to log on remotely using the interactive logon type.
Logon as a service
Required for an account to log on using the service logon type.
Replace a process level token
Required to assign the primary token of a process.
Stay tuned to the second part of this article.