Ultrasound Security

The following sections describe Ultrasound security.

Controller security

In Windows Server 2003 and Windows XP, the controller runs as a service under the Network Service account. In Windows 2000 Server, the controller runs as a service under the Local System account. The computer account where the controller is installed must be able to authenticate with any of the provider computers; that is, the controller must either be a member of the same domain as the provider computers, or be a member of a fully trusted domain. Communication with the provider and the database requires authentication of the computer account where the controller is installed. ACLs that allow the controller account access are configured during Ultrasound setup and provider deployment.

For security purposes, we recommend against installing the controller on critical servers, such as domain controllers. See the next section on database security for more information.

Database security

Although the controller is given access the database during Ultrasound setup, the database administrator must grant individual users or groups access to the database by running the USDBAccess.vbs script. This script, available in the Program Files\FRS Monitoring directory after you perform a complete installation or a console-only installation, gives read-only access or read-write access to the database. Those users can then install the console on their local computers and access the database on a remote server. For information about running this script, see Granting Database Access to Multiple Administrators.


If you install the controller and database on the same server running Windows 2000, be aware that whoever has read-write access to the database is implicitly given administrative access to the server on which the controller is installed. This access occurs because any user with read-write access to the database can modify a SQL command that is executed by the controller, a process known an SQL injection. A malicious user could append harmful code to SQL commands, and because the controller is running as the Local System account on Windows 2000, the user could gain administrative access to the server.


The following table describes the credentials used by the controller in various installation scenarios.

Credentials Used in Different Controller and Database Installation Scenarios

Operating system where controller is installed Controller and database on the same server? Credentials used
Windows 2000 Yes Local System
Windows 2000 No Controller computer account
Windows Server 2003 Yes Network Service
Windows Server 2003 No Controller computer account

To reduce the risk of SQL injection in situations where the controller and database are installed on the same server running Windows 2000 Server, limit read-write database access to trusted users. To reduce security risks on critical servers, avoid installing the controller or database on a critical server, such as a domain controller.

Provider security

Because the provider can run on domain controllers, provider security is of utmost importance. The communication channel between the provider and controller is authenticated and encrypted to make sure both parties are members of a trusted domain. In addition, the WMI namespace for the FRS provider has permissions that limit access to only the controller(s). When a provider is deployed to a server, the setup package configures the FRS WMI namespace to allow access to the controller’s machine account. Because a provider can support multiple controllers, if the WMI namespace already exists, the setup package only adds the new controller’s computer account and does not configure the other settings.


WMI uses DCOM for remote communication. For DCOM to go through a firewall, you must open a set of ports. For more information, see http://go.microsoft.com/fwlink/?LinkId=16723.