Demand Technology Software
Frequently Asked Questions about NTSMF security
1. Can I run the NTSMF collection service under a User Account, instead of LocalSystem (or SYSTEM)?
Frequently Asked Questions about NTSMF security
1. Can I run the NTSMF collection service under a User Account, instead of LocalSystem (or SYSTEM)?
No, to function properly the NTSMF collection service should be set up to run under the LocalSystem (or SYSTEM) account. The LocalSystem (or SYSTEM) account is a built-in account used by many services with an extraordinary level of privileges for accessing local system resources. These include privileges that cannot be granted to any User Account, include members of the Administrators group. The NTSMF collection service requires these SYSTEM-level privileges for some data collection functions.
More specifically, the Module collection function requires the PROCESS_QUERY_INFORMATION process-specific access right, which can only be granted programmatically by a process running with System level privileges to begin with. Unfortunately, there is no User Right that you can grant a User Account that allows the Performance SeNTry collection service to execute the EnumProcessModules Win32 function call it makes to enumerate all the modules loaded in a process.
You can run the NTSMF collection service under a User Account by following the guidelines discussed below. All collection service functions will execute normally, once you grant the User Account the appropriate User Rights and Permissions. However, the Module collection function, introduced in version 2.4.4 will not run under a User Account. In order to collect Module identification data, you must run under the built-in LocalSystem (or SYSTEM) Account.
2. Can the NTSMF collection service impersonate a User Account to gain access to secured network resources?
Yes.
By design, the NTSMF collection service (dmperfss.exe) is installed to run under the built-in LocalSystem (or, XP or .Net Server, SYSTEM) account. This built-in account, which most services use, has the authority to perform almost any internal function on the local machine. However, the LocalSystem account has no built-in facilities to access secure network resources, such as shared network folders.
The NTSMF collection service performs two sets of functions where security considerations may apply:
-
Control the NTSMF data and log files in the \data\ Folder. You can normally tell that the NTSMF \data\ Folder is protected from uncontrolled access by the LocalSystem account if the service terminates prematurely at start-up and no <computername>.ntsmf.log file is generated in the NTSMF \data\ Folder.
-
Execute the Cycle End command or command script. The Cycle End command or command script runs in a separate process that inherits its Authority from the NTSMF service process that creates it. If the Cycle End command or command script fails to complete successfully, but works fine when you execute it under your Logon Account, your Logon Account probably has Folder Permissions that are not granted to the LocalSystem account.
There are two ways to authorize the collection service to perform these secure functions:
-
If you have implemented Active Directory, it is possible to grant the LocalSystem (or SYSTEM) Account the Folder Permissions required to access secured network resources. The LocalSystem Account corresponds to the named Computer in Active Directory. However, some installations prefer not to grant the LocalSystem (or SYSTEM) Account any Folder Permissions.
-
You may assign a User Account with access to the appropriate network resources that the collection service will impersonate whenever it performs one of the two secured functions discussed above.
Impersonation allows the collection service to adopt temporarily a different security identifier (SID) than the the one specified when the service is started. You assign the User Account and Password that the collection service will impersonate when you install the collection service. The User Account you assign will be used whenever the collection services performs any function that might need to done under a security context other than LocalSystem (or SYSTEM). If you assign a User Account and Password during installation of the collection service, the collection service will impersonate that User Account when it launches the Cycle End command. This allows the Cycle End command or script to execute under a User Account that is authorized to perform network file operations on a secure shared folder. In addition, if the NTSMF \data\ Folder is protected from uncontrolled access by the LocalSystem account, you may need to assign NTSMF a User Account to impersonate when it performs any function that accesses the \data\ Folder.
You assign the User Account to be impersonated during NTSMF collection service installation using the -account and -password options, as illustrated below:
dmperfss -install -f MyDCS.dcs -account DomainName\myAccount
-password xxxxxxx
For more details, see Chapter 2 of the User's Manual.
3. I don't care about resolving module information for container processes like the Jave Virtual Machiine or dllhost.exe. What User Rights and Permissions does the User Account that I will assign to the NTSMF collection service require?
OK, you asked for it. If you do not need to gather Module identification information, you can run the Performance SeNTry collection service under a User Account. You can only set the NTSMF collection service to run under a User Account manually using the Services Administrative Tool, which is illustrated below:
To function correctly, the User Account that the NTSMF collection service runs under requires the following User Rights:
 |
Logon as a service |
|
Increase scheduling priority |
with the following Registry Key Permissions (in Windows 2000 and above):
|
Read access to the Registry key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib |
|
Read access to the Registry key HKLM\\SYSTEM\CurrentControlSet\Services |
|
Control access to the Registry key HKLM\\SYSTEM\CurrentControlSet\Services\Dmperfss. Note that this Registry key is created by the system's Service Control Manager when the Performance SeNTry collection service (dmperfss.exe) is installed. |
A sample installation script that installs the the Performance SeNTry collection service under a User Account and grants these local Registry Key Permissions to the Account is shown below. The subinacl utility used here to grant Registry Key permissions is available in the Windows 2000 Resource Kit.
net stop "Performance SeNTry"
dmperfss -remove
dmperfss -install -fdevncci.dcs -accountdomain\username -passwordpassword
subinacl /verbose /keyreg "SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib" /grant=domain\username
subinacl /verbose /keyreg "SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib\009" /grant=domain\username
subinacl /verbose /keyreg "SYSTEM\CurrentControlSet\Services\DMPerfss" /grant=domain\username
subinacl /verbose /keyreg "SYSTEM\CurrentControlSet\Services\DMPerfss\Control" /grant=domain\username
subinacl /verbose /keyreg "SYSTEM\CurrentControlSet\Services\DMPerfss\Security" /grant=domain\username
net start "Performance SeNTry"
and with the following Folder Permissions:
|
Control access to the NTSMF \data\ Folder and subFolders where the .smf data file is written. |
|
Control access to any shared Network folders that the Cycle End Command or command script requires access to. |
In addition, some Performance Library DLLs that the Performance SeNTry collection service will attempt to load and run may reside in secure folders. You will need to grant the User Account the collection service runs under Read access to the folders. During the Discovery phase of each collection cycle, when the collection service attempts to load the Perflib DLL modules, the Load will fail. You will see a Warning message similar to the following in the Application Event log or the local <computername>.ntsmf.log message file:
In this example, in order for the Performance SeNTry collection service to load the SQLCTR80.dll Performance Library DLL that is responsible for gathering SQL Server 2000 performance Objects and Counters successfully, you must first grant Read Access to the C:\Program Files\Microsoft SQL Server\MSSQL\Binn Folder where SQLCTR80.dll resides to the NTSMF agent User Account.