SMS Remote Tools Security

  • Article

Remote Tools has three levels of security - collection security, the Permitted Viewers list, and asking the user's permission. Collection-level class and instance security facilitates the flexible enforcement of remote tools security so that you can tailor Remote Tools usage to your organization's needs. The Permitted Viewers list provides an authorization step at the client before a user can start a remote session. Asking the user's permission ensures that no one can remotely control the computer without permission from the user.

SMS 2003 includes the option to use Terminal Services, Remote Desktop Connection, and Remote Assistance in addition to Remote Tools if the console and client operating systems support those options. For more information about their security and auditing, see the documentation for those operating system features.

Bypassing collection security for Remote Tools is easy for knowledgeable or determined people. They could set up an SMS site that is not part of your SMS hierarchy and create resource records for clients they want to control. They could give themselves any rights they want on those resources. Or they could use the Remote.exe /SMS:nosql switch, as described in the "Remote.exe" section later in this chapter. You should think of collection security for Remote Tools as an organizational convenience and effective for staff that follow your policies and procedures.

Note:

  • Collection security is an effective form of security for other SMS features where the clients must report to authorized sites or the feature is entirely dependent on the site server. But with Remote Tools the clients are controlled directly from consoles, regardless of which site the client is assigned to or the console is using.
On This Page

Security Provided by the Permitted Viewers List
Security Provided by Asking for User Permission
Remote Tools Security Considerations
Using Remote Control Securely

Security Provided by the Permitted Viewers List

The Permitted Viewers list defines the users and user groups that have permission to remotely access clients running Windows NT 4.0, Windows 2000, Windows XP, or Windows Server 2003 family operating systems. In the Remote Tools Client Agent Properties dialog box, the Security tab contains the Permitted Viewers list. You can use the Permitted Viewers list to add and delete permitted viewers. By default, if the user account you are using to connect to a client is not a member of the Permitted Viewers list, SMS prompts you for an appropriate user name and password.

How the Permitted Viewers list works

Local administrator rights are not required for a user to be able to use Remote Tools. If the collection and Permitted Viewers list security is met, the Remote Tools user can use Remote Tools on the client.

When initiating a remote control session, if the client cannot authenticate the account that is attempting the remote control, either as an account or as a valid entry in the Permitted Viewers list, then the connection is rejected. For example, a client might not be able to authenticate the account when the remote control user is from a nontrusted domain. However, a dialog box is displayed, allowing the administrator to enter credentials, user name, password, domain, or the local computer name. If those credentials can be resolved as valid, then the administrator is allowed to remotely control the client.

The permitted viewers are resolved to security identifiers when the Remote Control Agent is started on the client. The names are resolved to local accounts, if appropriate, then domain accounts for the domain on which the client computer is installed, and finally for trusted domains of the client's domain. Groups are considered to be accounts, for this purpose, so they are resolved in the same way as user accounts. Members of global groups that are members of local groups listed in the Permitted Viewers list are not enumerated, and thus members of global groups are not permitted viewers unless they are otherwise permitted viewers. As an example, if a user is a member of the Domain Administrator's group, and the Domain Administrator's group is included in the local Administrator's group, the user cannot control the client unless the user's account or group is specifically included in the permitted user list. For this reason, if you want all domain administrators to have remote control of clients, be sure you specifically include the Domain Administrators group in the Permitted Viewers list, rather than rely on its inclusion in the local Administrator's group.

There is a two-minute time-out during which administrators who are attempting to use Remote Tools do not require permission from the end-user to perform additional Remote Tools tasks. If one administrator ends the sessions with the client, another administrator could start a session within this time-out and would not require permission from the user, even if the policy is set to ask permission from the user. However, the administrator must still pass the collection-level security and Permitted Viewer list security on the client computer.

Local and global groups in the Permitted Viewers list

For clients running Windows NT 4.0, Windows 2000, Windows XP, or Windows Server 2003 family operating systems, SMS Remote Tools relies on the operating system's security to validate users and groups against security objects. When you include a local group in the Permitted Viewers list, remember that the group is local to the domain in which it was created, regardless of trust relationships. Therefore, if a client is in a different domain that does not also include the same local group, the client is unable to authenticate users from this local group. When you attempt to establish a Remote Tools connection, if the client cannot authenticate your user account as a valid member in the Permitted Viewers list, then the connection is rejected. For example, a client might not be able to authenticate the user account when the Remote Tools user is from a nontrusted domain. In this case, the Credentials Required dialog box appears and prompts the administrator to enter username, domain (or local computer name), and password. If those credentials are accepted, the administrator can connect to the client.

When a global group is included in a local group that is listed in the Permitted Viewers list, members of that global group are not implicitly included as permitted users and are not resolved when attempting to establish a Remote Tools connection. Members of such global groups are not resolved as permitted viewers unless the global group is explicitly listed in the Permitted Viewers list. For example, if a user is a member the Domain Administrators global group, and the Domain Administrators global group is included in the local Administrators group, the user is unable to connect to the client unless the user's account or the Domain Administrators global group is explicitly listed in the Permitted Viewers list.

Using accounts in trusted domains environment

In a complex domain environment, your SMS site server might be in one domain, and the clients are in other domains, with trust relationships between the domains or another master domain. In this situation, the user accounts or user groups included in the Permitted Users list must be fully qualified, by using the following syntax:

domain\user account

The client domains also must have a trust relationship with the domain that contains the user account or user group, so that the client can authenticate the account.

Permitted Viewers list in a nondomain environment

For clients running Windows NT 4.0, Windows 2000, Windows XP, or Windows Server 2003 family operating systems, which are not authenticated through a domain or Active Directory, you must create a local user account on the client before you can establish a Remote Tools connection to the client.

Security Provided by Asking for User Permission

When you enable the Display a message to ask for permission option as a site-wide setting, the user logged on to the client must grant permission for you to perform any Remote Tools function. However, if you perform a Remote Tools function (for example, Remote Control) on a client and then discontinue performing that function, you can perform the same Remote Tools operation to the same client for a period of up to 10 seconds without regaining the user's permission. If you attempt to perform a different Remote Tools function, even within 10 seconds, the user must grant permission. After 10 seconds, an attempt to perform any Remote Tool function on the same client requires user permission.

Clients that are running Windows 98 can rely only on the security provided by asking for user permission for Remote Tools security. Clients that are running Windows 98 do not have Permitted Viewers lists, and collection security can be bypassed. If you do not want to have the possibility of unauthorized people remotely controlling your computers that are running Windows 98, you must enable the option to ask user's permission on at least one site that the clients running Windows 98 are assigned to. You can set this option so that user's permission is only required on computers running Windows 98, so that permission is not required on other clients.

Remote Tools Security Considerations

There are various security considerations you should take into account when using Remote Tools:

  • Remote tools sessions

  • Remote tools client agent security settings

  • Membership in the Permitted Viewers list

  • Remote.exe

  • Client programs that run with administrative privileges

Remote Tools sessions

To establish a Remote Tools connection to any client, you must have Use Remote Tools and Read rights for a collection that contains the client, and for clients running Windows NT 4.0, Windows 2000, Windows XP, or Windows Server 2003, you also must be included in the Permitted Viewers list, which is on the Security tab of the Remote Tools Client Agent Properties dialog box. If you set remote tools to require the user's permission, the user must permit you to establish a remote tools session.

Entries are written to the operating system event log on the client computer when a Remote Tools session is started and completed. Also, SMS status messages are written every time a Remote Tools session is initiated, unless the Remote.exe /sms:nosql command-line option is used. Predefined queries are available in the SMS Administrator console to display the remote tool status messages.

You can configure SMS to display an icon on the user desktop to indicate use of Remote Tools on the computer. There are several levels of prominence that can be given to this icon.

Remote Tools client agent security settings

You can control Remote Tool security settings on computers running Windows NT 4.0, Windows 2000, Windows XP, or Windows Server 2003 family operating systems by manipulating appropriate registry entries and stopping and restarting the SMS Remote Control Agent. For complete control of Remote Tools security, it is important to ensure that remote registry editing and remote service control are properly secured. Refer to operating system documentation for details on registry and services security.

Membership in the Permitted Viewers list

The Permitted Viewers list is intentionally ambiguous because a user is authenticated against the list at the client, and the SMS site server might not have access to the same domains as the client. Consequently, you can enter an account name in the Permitted Viewers list without specifying a domain for the account. However, the list must be clear at the client. Therefore, it is recommended that you enter an account name in the Permitted Viewers list by using the format domain\account to remove any ambiguity that might occur at the client.

Note:

  • The localized versions of the "Administrator" user name that appear by default in the Permitted Viewers list could give Remote Tools access to unintended users. If you do not use the localized versions of the "Administrator" user name in your organization, remove them from the permitted viewers list. Removing unnecessary accounts from the Permitted Viewers list also reduces the amount of time and the amount of network authentication traffic needed for the client to authenticate the user and establish the remote session.

Remote.exe

Remote Tools can be run from the command line, or another program, by using Remote.exe. For more information about Remote.exe, see Chapter 9, "Remote Tools," in the Microsoft Systems Management Server 2003 Operations Guide. Remote.exe enforces security in the same way that running Remote Tools from the SMS Administrator console does. However, Remote.exe includes a /SMS:nosql switch that does not enforce collection security. The /SMS:nosql switch allows you to use SMS Remote Tools even when the SMS site is unavailable.

When you use the command-line interface to run Remote Control, the computer you specify is always resolved to a resource ID in the SMS_R_System class. SMS object security is then scanned to determine if the administrator has the right to remotely control this resource. Any differences in the ability to remotely control a computer by using Remote.exe with different parameters depends on the ability of SMS to resolve the computer address that is supplied, rather than on differences in the application of security controls.

Client programs that run with administrative privileges

When you run programs on client computers using SMS Remote Tools, the programs run in the security context of the administrator remotely initiating the programs and not in the context of the user who is logged on at the time. The user can use that program with administrative privileges.

Users of the Remote Execute function should be careful not to run programs that the end user could use to perform functions that they should not be able to do. This is especially true for programs that do not terminate when the intended task is completed. For example, the Remote Tools user should not start a command prompt window on the client computer.

When in a remote control session on a client computer, the remote control user should avoid entering passwords for privileged accounts. The password is secure to the client computer, but the password is entered through the virtual keyboard. Software that observes keyboard input could capture the password. Or if the program being run on the client computer is the not the program that the remote control user assumes, the program might be capturing the password. When accounts and passwords are required, the end user should enter them.

Using Remote Control Securely

When you use remote control to fix a problem or make changes on a remote computer running Windows NT 4.0, Windows 2000, or Windows Server 2003 family operating systems, it is possible that a user is not logged on at the remote computer. This can be the case when you are working on remote servers. However, during the session it is possible that the network link can become congested or other problems might cause the session to fail. Often you can resume the session by reconnecting. If the session fails before you log out of the remote computer, the remote console remains logged on with your credentials, and potentially without any supervision. Consequently, anyone who can get physical access to that server has your security rights and permissions. This can represent a significant security risk.

There are several methods to make the remote computer secure again:

  • Restart the computer using a remote restart tool, such as Shutdown.exe or Shutgui.exe, from the Windows 2000 Resource Kit. If programs were open, it might be necessary to use the option to restart even if data from open programs will be lost. Also, be sure to specify that the computer restarts, instead of just shutting down. You can determine the success of this method by pinging the remote computer. The computer will go offline for several minutes and then come back online. You can use Srvinfo.exe (also from the Windows 2000 Resource Kit) to ensure that the computer has been booted only for a minute after it is back online, and that it did restart. You might have to use this method because a network reliability issue could cause the session failure, and it might not be clear whether an unsuccessful restart is the cause of the ping failures. When the computer restarts, it waits at the logon prompt, and thus no one without privileges can work on the server. Use this technique if the computer can be restarted at that time, and no other solution is available, or if the risk of someone using your session is sufficiently great.

  • Configure a secured screen saver to run when activity is idle for the user accounts that access the server remotely. Then only users with administrative privileges on the computer can unlock the screen saver after it runs. However, this allows the risk of someone using your session until the screen saver starts.

  • If any trusted staff are available at the remote location, you can ask them to log you off the computer.

For More Information

Did you find this information useful? Please send your suggestions and comments about the documentation to smsdocs@microsoft.com.