1. -[ Remote administration with MSRPC (Win32 legacy management APIs) ]-
The traditional method to administer remote Windows systems is to use Win32 legacy management APIs.
These APIs can be easily identified because they take a server name as one oftheir parameters:
- when the server name is empty (NULL), the API operates on the local server
- when a server name is specified, the API operates on the specified remote server
For instance, all APIs with names starting with Net such as NetShareEnum() belong to this class of APIs.
When used to administer a remote server, these APIs use the MSRPC protocol (Microsoft implementation of the DCE RPC standard) with the SMB transport.
SMB is the core protocol of Windows networks and operates on both port 139/tcp and 445/tcp. When used as a transport for MSRPC, named pipes inside the IPC$ share are used as RPC services endpoints.
1.2 Windows administation tools using Win32 legacy management APIs
Well-known Windows administration tools use these APIs and, as a consequence, can operate either on a local or remote system. Examples of these tools include:
- Registry Editor: regedit.exe
- Computer Management MMC snapin (and included MMC snapins)
- Local Users and Groups MMC snapin
- Event Viewer MMC snapin
- Services MMC snapin
- Shared Folders MMC snapin
- Device Manager MMC snapin
- Certificates MMC snapin
- netsh command (-r option, Routing and Remote Access service must be
running on remote server)
MSRPC interfaces used by these APIs are detailed in the "RPC services listening on named pipes" section of our Windows network services internals paper:
Note: the winreg interface (access to Windows registry) is used by most Windows administration tools. Thus, the Remote Registry service must be started on systems that are administered with these tools.
Well-known third-party tools also rely on these APIs, such as tools included in SysInternals's pstools package (http://www.sysinternals.com/ ):
- psfile.exe (remote enumeration of opened files)
- pslist.exe (remote processes enumeration)
- psloggedon.exe (remote logon session enumeration)
- psloglist.exe (remote eventlog management)
- pspasswd.exe (remote user password management)
- psservice.exe (remote service management)
On Unix systems, the rpcclient tool (Samba-TNG and Samba projects) implements a subset of MSRPC interfaces used by these APIs.
1.3 SMB session management
Because these APIs use the SMB transport for MSRPC, the authentication is only implemented at the SMB level. Thus, an SMB session to the remote system is first established, usually with administrator credentials, before using remote administration tools.
When the remote system is in the same Windows domain as the local machine, the SMB session can be transparently established, for instance if the user is connected to the local system with domain administrator credentials (by the way, a bad habit and not recommended).
However, if you are connected with a local account or with an unprivileged domain account, it will be necessary to establish an SMB session to the remote system with alternate credentials.
For instance, to establish a remote SMB session with the local administrator on the remote system, the following command can be used:
C:\>net use \\server_name\IPC$ /u:administrator *
Then, the exact name specified in the previous command (\\server_name, where server_name can be the NetBIOS, DNS or IP address server name) must be specified as remote server name in administration tools.
It is possible to establish multiple SMB session to the same remote system with different credentials by using different server names in each case (the IP address in the first case, the NetBIOS name in the second case and the DNS name in the third case, if three concurrent sessions are needed).
The established SMB session will automatically be used and remote administration will be possible with the local administrator credentials of the remote system.
2. -[ Remote administration using WMI (Windows Management Instrumentation) ]-
WMI (Windows Management Instrumentation) is the management framework available in recent Windows systems. WMI is built on the COM (Component Object Model) infrastructure and can thus operate remotely, using DCOM (Distributed COM).
WMI is frequently used by Windows administrators with VBS scripts. Many sample scripts are available at Microsoft Technet's Script Center:
In addition, several WMI-based administration tools are available by default on Windows systems to administer remote systems using WMI.
2.2 WMI-based administration tools
2.2.1 WMI Control MMC snapin
The WMI Control MMC snapin (wmimgmt.msc) is used to configure the WMI framework.
WMI settings can be configured on either a local or remote system, choosing Properties after clicking on the WMI Control icon.
In Windows 2000 and Windows XP, the WMI Control MMC snapin supports alternate credentials in the Change manager computer dialog box.
For Windows Server 2003, it is possible to use runas with the /netonly option to specify alternate credentials for mmc.exe (the WMI Control MMC snapin must then be added manually and the remote system name specified in the Another computer field):
C:\>runas /netonly /user:administrator mmc.exe
2.2.2 WMI tester (wbemtest.exe)
WMI tester (wbemtest.exe) is a tool available in all WMI implementations (Windows 2000, Windows XP and Windows Server 2003).
WMI tester is originally a WMI testing tool but it also makes an interesting WMI-based administration tool.
When started, wbemtest.exe displays a main window, with a Connect button at the top right.
The Connect window allows the specification of a WMI namespace. To connect to a remote system, the namespace must be prefixed with a UNC name, for instance:
Alternate credentials can be specified in the Credentials fields (User, Password and Authority fields).
Once connected to a namespace, it is possible to:
- enumerate all WMI classes of the namespace, using the "Enum Classes" button with the Recursive option.
- enumerate instances of a given WMI class, using the "Enum Instances" button.
- execute a WQL query using the "Query" button, such as:
SELECT * FROM Win32_Process where name="lsass.exe"
- execute a method of a given instance, using the "Execute Method" button. The object path of the instance must be specified, such as:
2.2.3 WMIC (WMI command-line tool)
WMIC (wmic.exe) is installed by default on Windows XP and Windows Server 2003.
WMIC does not run on Windows 2000.
WMIC is typically used in interactive mode. The remote system name is specified with the /NODE option.
Alternate credentials can be used with the /USER and /PASSWORD options.
For instance, to connect to a remote system with IPv4 address 184.108.40.206 with the local Administrator account, the following commands can be used:
Enter the password :********
BootDevice BuildNumber BuildType Caption
\Device\Harddisk0\Partition1 2195 Uniprocessor Free Microsoft Windows
Many different commands are supported by WMIC.
For more information, consult the presentation "WMIC: A New Approach to Managing Windows Infrastructure from a Command Line" available at
In recent Windows systems, winmsd.exe has been replaced by the the msinfo32.exe program. However, winmsd.exe is in the system path whereas msinfo32.exe is not so it is easier to use winmsd.exe. winmsd.exe is a stub executable that starts msinfo32.exe.
winmsd.exe supports a "/computer" option, used to specify a remote system name.
When this option is used, the system configuration of the remote system is obtained using WMI and displayed by the program.
winmsd does not support alternate credentials and can not apparently be used with the /netonly option of runas.
2.3 Ports used by WMI
Because WMI relies on DCOM when used to connect to a remote server, access to TCP port 135 is required (IRemoteSCMActivator ORPC interface, also known as ISystemActivator). Then, a dynamic TCP port opened by the WMI service is used for WMI requests.
If a specific ports range for RPC services was configured on the remote server, ports dynamically allocated to DCOM servers are included in the range, including for the WMI service.
To configure a port range for RPC services, the rpccfg tool can be used, as documented in http://www.hsc.fr/tips/min_srv_res_win.en.html and http://www.hsc.fr/tips/min_w2k3_net_srv.html .
3. -[ Remote administration with GUI-oriented tools ]-
Many Windows system administrators tend to use graphical remote administration tools that allow access to Windows GUI.
3.1 Terminal Services
Recent Windows systems (Windows 2000, Windows XP, Windows Server 2003) natively support Terminal Services, the feature of Windows NT that allow multiple concurrent interactive logon sessions. The network protocol used by Terminal Services is RDP (Remote Desktop Protocol) and operates by default on TCP port 3389.
Terminal Services relies on Windows authentication to authenticate users establishing remote sessions.
In addition, applicative permissions are supported by Terminal Services to restrict the category of users allowed to establish Terminal Services sessions (Permissions tab in the Properties of the RDP-Tcp transport in Terminal Services Configuration MMC snapin).
Windows XP and Windows Server 2003 also explictly support two new logon rights to either allow or deny Terminal Services sessions for different categories of users:
- Allow log on through Terminal Services
- Deny log on through Terminal Services
When used in Remote Administration mode in Windows 2000 and Windows Server 2003 (now called Remote Desktop for Administration), Terminal Services allows up to two concurrent sessions.
Windows XP and Windows Server 2003 include by default the Microsoft RDP client (mstsc.exe). It can be also be installed on Windows 2000 systems.
On Unix systems, the rdesktop program can be used (http://www.rdesktop.org/ ).
3.2 VNC, pcAnywhere, Dameware Mini Remote Control, ...
Remote administration tools such as VNC, pcAnywhere or Dameware Mini Remote Control are remote administration tools different from Terminal Services because these tools do not create logon sessions.
Instead, these tools remotely display the display of a remote system's console.
pcAnywhere and Dameware Mini Remote Control can use Windows authentication to authenticate remote users whereas VNC only supports password-based authentication.
These tools are typically used on systems that do not support Terminal Services (Windows NT 4.0 servers, Windows workstations).
On systems that support Terminal Services, it is recommended to use Terminal Services instead.
3.3 Dameware Mini Remote Control features
Dameware Mini Remote Control (DMRC) is frequently used because this tool has a remote installation feature that do not require prior installation on the remote system.
If not already installed, the Windows service used by DMRC is copied to the remote system using administrative shares and then installed and started, using MSRPC.
The different installation options must be considered carefully:
- Stop Service on Disconnect
- Remove Service on Disconnect
- Set Service Startup type to 'Manual' (default is 'Automatic')
By default, the service is installed on the remote system and set to startup automatically. Thus, once installed, it will remain available until manually removed by the system administrator.
To install the service the first time, local administrators credentials are required, as well as access to either TCP 445 or 139 (for SMB session establishment).
When started, the DMRC service opens TCP port 6129, used to establish the graphical remote session.
The DMRC client then connects to port 6129 and authenticates using Windows credentials (using either the Windows NT challenge/response mode or the Encrypted Windows logon mode).
If the account used to authenticate has local administrator credentials, access to the GUI of the remote system is allowed. For a non-administrator user, the "Permission required for these account types" access option (enabled by default)
requires a confirmation from the local user (if someone is logged on the remote console).
If nobody is logged on the remote console, the "Disconnect if at the Logon Desktop" access option (enabled by default) will not allow session establishment for a non-administrator user.
Thus, by default, a non-administrator user can not establish a remote session without approval of the locally logged-on user. If nobody is logged on, access is denied to prevent access to winlogon.
The DWRCS.INI (under %systemroot%\System32) file contains all options related to the DMRC service, including three options related to access control for non-administrators users:
- Permission Required for non Admin = yes
- Permission Required for non Admin Disconnect If At Logon Desktop = yes
- Permission Required for non Admin Force View Only = no
It is recommended to allow only administrators to connect by setting the "Allow Only Administrators To Connect" access option (NOT enabled by default).
Another interesting option for security is the "Only allow connection when at Logon Desktop" access option. When enabled, it is only possible to establish a remote session if either the system console is locked or nobody is logged on.
DMRC supports application-level IP filtering, to restrict hosts allowed to connect If possible, it is recommended to use this feature and restrict allowed IP addresses to management hosts only.
Finally, the DWMRCS service supports logging in Windows's Application eventlog (source DWMRCS, with event identifiers around 100).
Several vulnerabilities have affected DMRC in the past (http://www.dameware.com/support/security/ ), including a pre-authentication buffer overflow published in december 2003. Just like any software, it is thus important to maintain DMRC up to date.
4. -[ Remote administration with CLI-oriented tools ]-
CLI (Command Line) remote administration tools are sometimes needed, for instance to execute non-interactively system administration scripts.
The PsExec utility, part of Sysinternal's PsTools (http://www.sysinternals.com/ntw2k/freeware/pstools.shtml ) is a tool frequently used to execute processes remotely.
PsExec is a convenient tool for Windows systems administrators because it allows to execute processes on a remote system, provided the server service is available (TCP ports 445 or 139) and that you have local administrator credentials on the remote system.
PsExec supports several options, described in the following webpage:
PsExec first copies its executable (psexesvc.exe, contained in the psexec.exe binary) using SMB (under %systemroot%\System32\), installs the service and starts it. These steps require administrator credentials.
If you're logged on with local credentials that also correspond to local administrator credentials (i.e., with a domain administrator account or with an account with username and password identical to a local administrator account on the remote system), additional credentials are not needed.
However, if alternate credentials are needed, it is necessary to establish a SMB session with "net use":
C:\>net use \\remote_server\IPC$ /u:administrator *
Then, the exact remote server name (such as \\remote_server) must be passed as first parameter to psexec.exe.
Warning: PsExec supports two options (-u and -p), used to specify a username and password. When used, the specified username and password are transmitted in CLEARTEXT over the network. These options are NOT needed in most cases (only if you need to overcome the limit of impersonation related to access to network resources). Instead, manually establish a session with "net use" with alternate credentials before using PsExec.
When started, the PsExeSvc opens a named pipe named \pipe\psexecsvc. This named pipe is used by the psexec.exe client to communicate with the PsExeSvc service, using an SMB session to the IPC$ share.
When a program is run, three named pipes instances are created, for stdin, stdout and stderr of the remote process. For more details, see http://www.ntkernel.com/w&p.php?id=15 .
The output of the "net files" command on a remote server running PsExeSvc shows the 4 named pipes (the main psexecsvc named pipe and the three named pipes used to run the remote process)
ID Path User name # Locks
4089 \PIPE\psexecsvc ADMINISTRATOR 0
4090 \PIPE\psexecsvc-SERVEUR-2164-stdin ADMINISTRATOR 0
4091 \PIPE\psexecsvc-SERVEUR-2164-stdout ADMINISTRATOR 0
4092 \PIPE\psexecsvc-SERVEUR-2164-stderr ADMINISTRATOR 0
The command completed successfully.
The "net session" output shows that local administrator credentials were used to run PsExec:
Computer User name Client Type Opens Idle time
\\220.127.116.11 ADMINISTRATOR Windows Server 20 4 00:00:00
The command completed successfully.
By default, the remote process runs with the credentials specified to psexec.exe (local administrator credentials). Because the PsExeSvc service is running under the LOCALSYSTEM logon session, it is possible, if needed, to use the -s option to run the process as LOCALSYSTEM.
To summarize, with PsExec, it is possible to execute remote process on a system, provided you have local administrator credentials and access to either TCP ports 445 or 139.
4.2 Rcmd (Remote Command service)
Rcmd is an Windows NT 4.0 Resource Kit tool composed of a Windows service and a command-line client that supports remote process execution.
The Rcmd service opens a named pipe, \pipe\rcmdsvc. The Rcmd client establishes an SMB session to the IPC$ share, authenticated with an account that needs to have the InteractiveLogonRight logon right ("Allow log on locally").
If Rcmd is installed on a server, it is important to realize that any user with the "Allow log on locally" logon right can remotely execute processes on theserver, under its own identity (impersonation mechanism).
5. -[ Windows remote administration tools summary ]-
Remote administration tools using SMB (139/tcp, 445/tcp):
- Windows administration tools relying on legacy Win32 management APIs
- third-party administration tools relying on legacy Win32 management APIs
- Dameware Mini Remote Control (at installation only)
WMI-based administration tools (135/tcp, dynamic TCP port(s))
GUI administration tools (dedicated ports)
- Terminal Services (3389/tcp)
- pcAnywhere (5631/tcp)
- VNC (5900/tcp)
- Dameware Mini Remote Control (6129/tcp)
6. -[ Conclusion ]-
While choosing a Windows remote administration tool, the following characteristics have to be considered:
- TCP ports required to use the remote administration feature
- supported authentication mechanisms (system authentication implemented by Windows, application-level authentication only, ...)
It is particularly important to realize that with a tool such as PsExec, one TCP port (445 or 139) is enough to administer remote Windows systems, provided you have local administrator credentials.
$Id: win_remote_admin_tools.tip,v 1.7 2005/06/15 14:56:15 marchand Exp $