Authentication Methods and Types


The MRC program always authenticates locally to the remote machine.  Even if the MRC Client Agent Service is installed and running on the remote machine, the MRC Application user must be able to authenticate locally to that machine (i.e. Login at the console using the supplied credentials).  If a user does not have sufficient rights to log into a machine if he or she were physically at the machine, he or she will not be able to log into that machine using the MRC software either.


The MRC program uses the Operating System's built-in security.  Local Administrator rights are required on the remote machine to install, remove, start, stop, or upgrade/downgrade the MRC Client Agent Service.  However, Administrator rights are not required to simply make a connection if the MRC Client Agent Service is installed and running on the remote machine.  


The credentials must be a member of one of the following groups on the remote machine:



Power Users


Server Operators

Account Operators

Backup Operators

Print Operators


The Mini Remote Control program provides four methods of authentication, three of which are integrated into the Operating System's built-in security.  These are detailed below:


Proprietary Challenge/Response:

This authentication method works by having a custom proprietary User Name and Password defined in the settings of the MRC Client Agent Service on the remote machine.  The User Name and Password are stored in encrypted format in the Registry of the remote machine.  To connect to a remote machine using this authentication method, the MRC Application user must enter the proprietary User Name and Password in order to connect.  This authentication method does not use the Windows Operating System security.


Windows NT Challenge/Response:

This authentication method uses the integrated security of the Operating System for authentication to gain access to a remote machine with the MRC program.  When this option is selected, everything is handled directly by the Operating System.  Selecting this method also allows the MRC user to enable the “Use Current Logon Credentials” option which uses NT Pass-Through authentication to pass the current logged on credentials to the remote machine for authentication.


Encrypted Windows Logon:

The Encrypted Windows Logon is similar to the Windows NT Challenge/Response authentication method except that it allows the User Name and Password to be sent to the remote machine in an encrypted format.  This authentication method is designed primarily for situations where NT Challenge/Response authentication is not possible, or fails.  Examples of these situations include when Domain Controllers have been configured to disallow anonymous connections, NT Challenge/Response has been disabled, or when using any of the “Home” versions of Windows Operating Systems.


Smart Card Logon:

The Smart Card Logon authentication method allows the MRC user to authenticate to a remote machine using his Smart Card and PIN from his local machine, without a Smart Card reader being required on the remote machine.  This option works in conjunction with the Smart Card network implementation.  DameWare Development's Remote Smart Card Authentication and Interactive Smart Card Login functionality does not require any Middleware (other than Microsoft’s Smart Card Services – “scardsvr”), and it also does not require a Smart Card reader on the remote machine.  With Smart Card Logon it is even possible to remotely perform an Interactive Smart Card Login on a remote machine that is currently at the Logon Desktop or Lock Screen.


Requirements and Notes regarding DameWare Smart Card Logon functionality:


1.  According to Microsoft, Smart Card Login & Authentication is only supported on Windows 2000 and above, including:

• Windows 2000 Workstation

• Windows 2000 Server

• Windows XP Professional

• Windows 2003 Server

• Windows Vista

• Windows 2008 Server

• Windows 7


The following documentation from Microsoft may be used as reference:


The Secure Access Using Smart Cards Planning Guide


The Smart Card Deployment Cookbook


Smart Card Concepts


***According to Microsoft, Smart Card Authentication to Active Directory requires that Smart Card workstations, Active Directory, and Active Directory Domain Controllers be configured properly.  Active Directory must trust a certification authority to authenticate users based on certificates from that CA.  Both Smart Card workstations and Domain Controllers must be configured with correctly configured certificates.


***When using the Smart Card authentication method, a "New Hardware Found" notification may be displayed on the remote machine after the DameWare Virtual Smart Card reader is inserted on the user's behalf.  


Known Issues:


1.  When attempting to connect via Smart Card Login, (also applies to "Connect on Server Service Ping" via Smart Card Login) authentication may fail.  This is because TCP is one of the first Protocols/Services to start on a machine.  Also, other Services such as Microsoft's Smart Card Services (SCardSvr), Server Service, or NetLogon Service, may not have fully initialized yet either.  It may be necessary to try the Smart Card Logon again after a short delay.  The MRC program's "Connect on Server Service Ping" functionality also allows for the specification of a "Connect Delay" interval before attempting the reconnection.


2.  Although Smart Card functionality was designed to be supported in Windows 2000 and above, there are documented anomalies under Windows 2000, which may prevent the PIN dialog from being displayed after an MRC connection is made when using Smart Card Logon.  In order to resolve this behavior, perform one of the following actions:


• Attach a Smart Card reader to the remote machine.

• Disconnect and reconnect a few times resolves the issue.

• Verify the latest manufacturer's driver is installed.

• The following hotfix from Microsoft may be needed.  


A Windows 2000-based computer no longer recognizes a USB smart card reader