Remote Controlling an agent workstation may fail with the following error
"Unable to establish a secure session with the remote computer (-5)."
If you check the RemoteControl.dll.log in the ManagementSuite\log folder you find the following error:
03/08/2010 08:54:25 INFO 4368:10 RollingLog : Exception The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
NOTE: This error is most common when using Remote Control security types of "Certificate Based" or "Integrated Security" .
This error has numerous causes but is most commonly attributed to a failure in the authentication that was passed through SSL
Regardless of who is logged into the Management Console, the user credentials logged into Windows on the Remote Controlling workstation are the credentials that are passed to the core server/target machine. If the user logged into Windows on the Remote Controlling workstation does not have the remote control rights, the error above will be returned and along with a prompt for credentials.
- The failure can occur in the LANDesk1 COM+ object when using an account that cannot read into Active Directory structure or OU. This includes using the default LANDeskCOMPlus account or using an Active Directory account that has read privileges to all areas of the structure. Many people have set up service accounts that have Domain Admin privileges, though this may not be possible for all environments.
In order to see if a user is in a Domain Group, a user with Domain access is needed. By default, the LANDesk COM+ objects are set to use LANDeskCOMPlus user which is a local account on the core. This Identity cannot query the domain for security group membership information. It is designed to be a placeholder identity until the LANDesk administrator replaces it with a functional account.
On the Core Server, if the LANDesk1 COM+ application identity does not have permission to enumerate groups on the domain, the following will be seen in the UserValidatorErrlog.txt that is located in the ManagementSuite directory:
- This failure can also occur when using Domain Groups (sometimes called a Nested Group) in the LANDesk Management Suite group on the Core Server or the Remote Control Operators group on the agent workstation.
In order to see if a user is in a Domain Group, a user with Domain access is needed. By default, the LANDesk COM+ objects are set to use LANDeskCOMPlus user which is a local account on the core. It cannot query the domain for security group membership information.
On the Core Server, if the LANDesk1 COM+ application identity does not have permission to enumerate groups on the domain, the following will be seen in the UserValidatorErrlog.txt that is located in the ManagementSuite directory
ERROR on 12/21/2009 11:25:46 PM with user STEELIO\Administrator, and core 88Core:
GetGroupUsers() : NetGroupGetUsers failed with an ERROR_LOGON_FAILURE code. IIS may not have permission to query the domain for group information.
- If only a few users receive this error, AND one user's remote control session works on the SAME machine where another users session failed:
There may be corruption in that user's profile causing this error to appear. This happens due to Remote Control needing to create and save files into the Application Data directory of the user's profile.
These errors can be resolved in different ways. Review the resolutions below and determine the resolution best suited for your environment.
Configure COM+ to use a Domain User
On the Core Server, open Administrative Tools | Component Services.
In Component Services, browse to Component Services | Computers | My Computer | COM+ Applications | LANDesk.
Note: These same steps must also be performed against the LANDesk1 COM+ Application.
Right-click the object and click on Properties.
Select the Identity tab.
- Change the LANDeskComPlus user to a valid domain user.
Note: A valid domain user is one that has read access to Active Directory. The user account must be in the format Domain\UserName. Again, both COM+ Applications LANDesk and LANDesk1 should be modified.
- Select the Advanced tab.
- Check the Leave running when Idle radio button.
Note: This will prevent the COM+ object from shutting down after it starts and resolves the issue.
- Click OK
- Right-click and choose Shutdown on both Landesk and Landesk1 COM+ objects.
- Right-click and choose start on each.
Note: If the issue is not corrected then the core may need to be rebooted as shutting down and starting com+ objects doesn't always clear their cache.
Verify rights of the COM+ users
Verify that the user in the COM+ objects is a member of the LANDesk Management Suite Group
- Verify that the user in the COM+ objects has full read Access to the AD domain.
Add the User to the Management Suite Group Explicitly
Add any remote control user accounts explicitly to the LANDesk Management Suite group on the Core Server.
- Login to Windows as a user that has the remote control rights
NOTE: This can also affect a group of users if their Group is not added to the LANDesk ManagementSuite group on the core. This group has NTFS permissions that are specific for successful Remote Control using Integrated Security.
Login to the Remote Controlling Workstation as a User with Remote Control Rights
- Log into the OS with a user that has Remote Control rights.
Note: Remote Control authenticates with the user logged into the Windows Operating System, not the user logged into LANDesk Console.
Remove and Recreate the User account
- Log into the machine as an Administrator account and remove the account of the user who is being affected.
- Have the user log back into the machine and regenerate their profile.
If using NT Security Type...
Add the User to the Remote Control operators group Explicitly
Make sure that the user logged into the Operating System on the remote controlling workstation or the viewer workstation is in the Remote Control operators group on the client.