|Windows remote administration tools overview |
par Jean-Baptiste Marchand (10/06/2005)
--[ Windows remote administration tools overview ]--
0. -[ Introduction ]-
The purpose of this document is to present the different methods and tools
frequently used to administer remote Windows systems.
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 of
- 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
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
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
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
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
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 18.104.22.168
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
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
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
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
- 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
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
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
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
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
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
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
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
- 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
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
Computer User name Client Type Opens Idle time
\\22.214.171.124 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 SeInteractiveLogonRight 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 the
server, 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 $