Skip to content

Troubleshooting: Job Connectivity and Errors

In this troubleshooting topic, we focus specifically on resolving issues related to remote connectivity and job execution failures between the 12Port Credential Rotation module and target host machines. If you are encountering errors with Job execution like "Connection time out" or "401" errors, please review this topic to troubleshoot and resolve the issues.

Connection timed out: connect

When the Credential Rotation module is unable to establish a connection with a Windows host machine, a "Connectivity Timeout" error may occur. This can be caused by several factors related to network settings, configuration issues, or credentials. To resolve this error, follow the suggestions below:

 

Ensure WinRM is Running and Configured Properly on the Target Host

The Windows Remote Management (WinRM) service is required for establishing remote PowerShell connections to a Windows host. If WinRM is not running or is misconfigured, 12Port will not be able to establish a connection, resulting in a timeout error.

Suggestion:

  • Open a PowerShell prompt on the target host with Administrator rights.
  • Run the following command to check and configure WinRM:
winrm quickconfig

This command will ensure that WinRM is properly configured and running on the target host. If WinRM is not configured, this command will prompt you to enable and configure it.

 

Ping the Target Host from the Server Running 12Port

Network connectivity between the 12Port server and the target host is essential for remote access. If 12Port cannot reach the target host over the network, the connection attempt will fail and result in a timeout error.

Suggestion:

  • From the server where 12Port is running, open a command prompt or PowerShell window.
  • Use the ping command to check connectivity:

ping <target_host_ip_or_hostname>

If the ping is successful, the network connection between the server and the target host is working correctly. If the ping fails, you may need to troubleshoot network connectivity between the two machines, such as firewall settings, routing issues, or DNS resolution problems.

 

Use Hostname Instead of IP Address in the Asset

In some cases, using the IP address of the target host in the Asset can cause issues with DNS resolution or network routing. If you are using the IP address in the Asset and experiencing a timeout error, try switching to the hostname instead.

Suggestion:

  • Edit the Asset for the target host and replace the IP address with the target's fully qualified domain name (FQDN) or hostname.
  • Save the changes and try to execute the task again.

Using the hostname can sometimes resolve issues related to IP address misconfiguration or DNS resolution.

 

Check the Format of the Username in the Asset

Incorrect username formatting in the Asset can cause authentication issues when attempting to connect to the target host. If you are using a domain account or local account, the format of the username must be specified correctly.

Suggestion:

  • In the Asset for the target host, verify that the username is in the correct format:
    • If you are using a domain account, the format should be domain\username.
    • If you are using a local account, the format should be computername\username.
  • Update the Asset with the correct username format and try task execution again.

Ensuring the correct format of the username will help avoid authentication issues that could prevent a successful connection.

 

Ensure the Password in the Asset is Valid

An incorrect or expired password in the Asset can also result in a timeout error. Double-check that the password stored in the Asset is valid and up to date.

Suggestion:

  • Open the Asset for the target host and verify that the password is correct.
  • If necessary, update the password to the current valid password for the target host.
  • Save the changes and attempt to execute the task again.

By verifying the password is correct and up to date, you can eliminate authentication issues as the cause of the timeout error.

 

Test WinRM Connectivity between the 12Port Server and Target Host (Windows only)

WinRM is required to remotely execute PowerShell commands from the 12Port host server and all target Windows assets. Testing WinRM to ensure it is properly configured on the target asset, credentials are valid, and the account provided has the required permission to execute remote PowerShell scripts to crucial to a successful job execution.

Suggestion:

  • Open a PowerShell prompt on the target host with Administrator rights.
  • Run the following to test WinRM execution.
    • Replace remote-host with the Hostname of the target Windows asset
    • Replace domain\username with the credentials from the target Windows asset if you're using domain-based authentication. If you're using local accounts, you would specify the local computer name computername\username. If you don’t want to hardcode the username, you can also use Get-Credential to prompt for the credentials interactively: -Credential (Get-Credential).
Invoke-Command -ComputerName remote-host -Credential domain\user -ScriptBlock {dir \}

The command should complete without errors and display the directory listing of the root directory on the target host.

If the command fails, confirm WinRM connectivity is configured properly and try again.

By following these troubleshooting steps, you should be able to resolve the "Connectivity Timeout" error and restore remote connectivity between 12Port and your Windows host machine. If the issue persists after trying these steps, please contact the 12Port support team at support@12port.com for further assistance.

Response error: 401

A 401 Unauthorized error in the context of WinRM (Windows Remote Management) typically indicates that the client failed to authenticate with the remote server. This error occurs when the server receives the request but refuses to process it due to missing or invalid authentication credentials. Troubleshooting this error involves checking both authentication configuration and user access rights on both the client and target machines. To resolve this error, follow the suggestions below:

 

Ensure Credentials are Valid

The username or password from the Asset (or the Shadow Account record, if that is being used for Task Execution), used to authenticate with the remote server is incorrect. This could be due to typos, outdated credentials, or incorrect format.

Suggestion:

Double-check the credentials in the Asset or Shadow Account and ensure they are entered in the correct format:

  • If you are using a domain account, the format should be domain\username.
  • If you are using a local account, the format should be computername\username.
    • Update the Asset with the correct username format and try task execution again.

Also, confirm the password entered in the Asset's Password field is correct.

 

User Lacks required Remote Access Rights

Even if the user has valid credentials, they must also be authorized for remote access. By default, only members of the local Administrators group or members of Remote Management Users group can use WinRM.

Suggestion:

  • Add this Asset or Shadow user to the local Remote Management Users group or the local Administrators group on the target machine.

After this user has been added as a member of the Remote Management Users group in the target machine, as defined in the Asset's Host field, try executing the script again.

 

UAC Remote Restrictions (on Local Administrator accounts)

UAC restricts local administrator accounts from authenticating remotely over the network, unless a registry key is set to allow full token elevation.

Suggestion:

Note

Consult with your IT department before attempting this suggestion as it requires modifying the System Registry on the target machine.

On the target machine, create the LocalAccountTokenFilterPolicy registry value:

New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" `
-Name "LocalAccountTokenFilterPolicy" -Value 1 -PropertyType DWord -Force

Next, restart the WinRM service:

Restart-Service winrm

Once the service is restarted, try the script execution again.

 

Confirm Account Lock Status

If the user account being used for WinRM authentication is locked out, which typically happens after multiple failed login attempts due to incorrect credentials or saved credentials being reused, this needs to be resolved before continuing.

Suggestion:

Talk to your IT department if this is a locked domain account. Otherwise, locate this account in your Active Directory (for domain accounts) or Local Users and Groups (lusrmgr.msc for target machine local accounts) and unlock it. You can do this via Active Directory Users and Computers (ADUC), PowerShell or GUI controls.

After the account is confirmed to be not locked, try the script execution again.

Failed: Exception calling "ChangePassword"

An exception failure returned during a Reset Password operation is frequently associated with password policy enforcement within a Windows domain environment. In many cases, the password change request fails because the proposed password does not satisfy the requirements defined by either the local system security policy or the domain’s password policy.

Troubleshooting Steps

To diagnose this issue, perform the following steps:

  1. Log in directly to the affected remote host.
  2. Attempt to manually change the password for the account in question.
  3. If the manual password change also fails, review the applicable password policy settings.
    • For domain-managed accounts, verify the policy on the Domain Controller.
    • For local accounts, review the Local Security Policy on the target system.

Confirm that the new password satisfies all configured policy requirements.

Password Complexity Requirements

If the "Password must meet complexity requirements" policy is enabled, the password requirements defined in 12Port PAM must comply with the enforced complexity rules of the remote host's local or domain policy.

At minimum, the generated password must satisfy three out of the following four categories:

  • Required Number of Upper Case Characters: 1 or greater
  • Required Number of Lower Case Characters: 1 or greater
  • Required Number of Numeric Characters: 1 or greater
  • Required Number of Special Characters: 1 or greater

Ensure that the PAM password requirements are configured to produce passwords that meet these criteria.

Minimum Password Age Considerations

Many domain and local security policies also enforce a Minimum Password Age setting, which prevents passwords from being changed again until a defined period has passed. Depending on the policy configuration, this may restrict password changes to once per day or less frequently.

While this restriction is important for protecting production accounts, it can introduce challenges during testing scenarios where passwords may need to be rotated repeatedly within a short time frame. In such cases, administrators should verify whether the minimum password age policy is preventing the requested password update.

Failed: Exception "Access Denied" During Password Reset

An Access Denied exception may occur during a password reset operation when the account performing the action does not have sufficient permissions to modify the target account's password. This condition typically indicates that the requesting user is not authorized to reset passwords within the local system or the domain.

In some environments, users are restricted from resetting their own passwords or the passwords of other accounts. If the password reset request originates from an account without the necessary privileges, the operation will fail and return an Access Denied response.

Troubleshooting Steps

To investigate and resolve this issue, perform the following checks:

  1. Verify the permissions of the account being used to perform the password reset.
  2. Confirm whether the account has the appropriate rights on the target system or within the domain to reset the password of the specified user (either itself or other user accounts).
  3. If possible, log in to the target host and attempt to manually reset the password using the same account credentials to confirm whether the permission issue persists.

If the manual reset attempt also fails with an access-related error, the account likely lacks the required privileges.

Using a Shadow Account

If the primary account does not have permission to reset its own password, or to reset the password of another user, it is recommended to configure and use a Shadow Account.

A Shadow Account is an administrative or service account that has been granted the appropriate permissions on the local host or within the domain to perform password management operations. When configured in this manner, the Shadow Account can execute password resets on behalf of the original account.

When implementing this approach:

  • Ensure the Shadow Account has the necessary rights to reset passwords on the target system or within the domain.
  • Configure the Shadow Account within the PAM system to perform password reset operations where the primary account lacks sufficient permissions.

Using a Shadow Account ensures that password rotation and management tasks can proceed successfully even when the managed account itself does not have the authority to modify its own credentials.

By following these troubleshooting steps, you should be able to resolve the "401" error and restore remote connectivity between 12Port and your Windows host machine. If the issue persists after trying these steps, please contact the 12Port support team at support@12port.com for further assistance.