diff --git a/docs/kb/changetracker/configuration-and-setup/how-to-determine-what-network-ports-need-to-be-open-for-change-tracker-or-log-trackerto-function.md b/docs/kb/changetracker/configuration-and-setup/how-to-determine-what-network-ports-need-to-be-open-for-change-tracker-or-log-trackerto-function.md new file mode 100644 index 0000000000..6003b85865 --- /dev/null +++ b/docs/kb/changetracker/configuration-and-setup/how-to-determine-what-network-ports-need-to-be-open-for-change-tracker-or-log-trackerto-function.md @@ -0,0 +1,106 @@ +--- +description: >- + Describes which network ports to open to allow Netwrix Change Tracker agents + and servers to communicate, including ports for agentless monitoring and + network device configuration. +keywords: + - Netwrix Change Tracker + - network ports + - firewall rules + - HTTPS + - agents + - agentless + - SSH + - port 443 +products: + - change-tracker +sidebar_label: Network Ports for Change Tracker +tags: [] +title: Determining which network ports should be open for Change Tracker to function +--- + +# Determining which network ports should be open for Change Tracker to function + +## Overview + +This article describes the network ports required for Netwrix Change Tracker to function properly. Use this information when configuring firewall rules for new deployments or troubleshooting connectivity issues. + +> **Note:** For the most current port requirements and network architecture details, refer to the official documentation: [Change Tracker 8.0 - Agent and Device Ports](/docs/changetracker/8.0/requirements/agentdeviceports.html) + +Although custom ports can be set in the agent's configuration files, the following are the default and recommended ports for Change Tracker. + +![Change Tracker network ports diagram](https://nwxcorp--c.na147.content.force.com/sfc/dist/version/download/?oid=00D7000000091pB&ids=0684u00000LdKFX&d=%2Fa%2F4u000000Lzny%2FZeSqAiVi0zhk87SB7gy6ozAik49vfOFITCzm__LZ4Fk&asPdf=false) + +## Instructions + +### Change Tracker Console + +- **Port:** 443 (HTTPS) or Custom +- **Direction:** Inbound to Change Tracker Hub server +- **Protocol:** HTTPS + +HTTPS communication to the Change Tracker Console is by default on port 443. This can be adjusted within IIS if other ports are deemed more suitable for your environment. + +### Change Tracker Agents (Windows & Linux) + +- **Port:** 443 (HTTPS) or Custom +- **Direction:** Outbound from agent to Change Tracker Hub +- **Protocol:** HTTPS + +HTTPS communication between Change Tracker and the agent is controlled by the agent's HUBURL, defined during installation. The HUBURL will resemble `https://MY_CT_SERVER/api/`. + +**Important:** Communication is one-way and will always be initiated by the agent connecting to the Hub server. + +### Agentless Monitoring - Linux Systems + +- **Port:** 22 (SSH) +- **Direction:** Outbound from Change Tracker Proxy Agent to monitored Linux systems +- **Protocol:** TCP/SSH + +One-way communication is initiated from the Change Tracker Proxy Agent to the monitored Linux systems. The proxy agent is typically collocated with Change Tracker but can be installed on a separate system if needed. + +### Agentless Monitoring - Windows Systems + +- **Port:** 445 (SMB) +- **Direction:** Outbound from Change Tracker Proxy Agent to monitored Windows systems +- **Protocol:** SMB + +One-way communication is initiated from the Change Tracker Proxy Agent to the Remote Registry Service on the Windows devices being monitored. + +### Network Devices (Routers, Switches, Firewalls) + +#### SSH-Based Monitoring + +- **Port:** 22 +- **Direction:** Outbound from Change Tracker Proxy Agent to network devices +- **Protocol:** TCP/SSH + +#### Telnet-Based Monitoring (Legacy) + +- **Port:** 23 +- **Direction:** Outbound from Change Tracker Proxy Agent to network devices +- **Protocol:** TCP/Telnet + +> **Note:** SSH (port 22) is recommended over Telnet (port 23) for security reasons. + +### Firewall Configuration Summary + +For a typical Change Tracker deployment, ensure the following firewall rules are in place: + +**Inbound to Change Tracker Hub:** +- Port 443 (HTTPS) - for console access and agent communication + +**Outbound from Change Tracker Hub/Proxy Agent:** +- Port 22 (SSH) - for agentless Linux and network device monitoring +- Port 23 (Telnet) - for legacy network device monitoring (if required) +- Port 445 (SMB) - for agentless Windows monitoring + +**Outbound from Agents:** +- Port 443 (HTTPS) - to communicate with Change Tracker Hub + +## Related Links + +- [Gen 7 Agent Deployment Options](/docs/changetracker/kb/gen-7-agent-deployment-options) +- [Agent and Device Ports](/docs/changetracker/8.0/requirements/agentdeviceports) +- [Gen 7 Agent Requirements - Windows](/docs/changetracker/8.0/requirements/gen7agentwindows) +- [Gen 7 Agent Requirements - Linux](/docs/changetracker/8.0/requirements/gen7agentlinux) diff --git a/docs/kb/changetracker/configuration-and-setup/how-to-update-agents-from-the-change-tracker-console.md b/docs/kb/changetracker/configuration-and-setup/how-to-update-agents-from-the-change-tracker-console.md new file mode 100644 index 0000000000..53321e38b1 --- /dev/null +++ b/docs/kb/changetracker/configuration-and-setup/how-to-update-agents-from-the-change-tracker-console.md @@ -0,0 +1,320 @@ +--- +description: >- + Comprehensive guide for updating Netwrix Change Tracker agents from the Hub + console, including download instructions, upload procedures, deployment + scheduling, phased rollout strategies, testing recommendations, and + troubleshooting. +keywords: + - Netwrix Change Tracker + - agent update + - Agent Updates + - Agent Software Updates + - Groups + - Gen 7 + - Auto Updates + - Hub + - deployment + - phased rollout +products: + - change-tracker +sidebar_label: Updating Agents From the Console +tags: [] +title: Updating Agents From the Change Tracker Console +--- + +# Updating Agents From the Change Tracker Console + +## Overview + +When a new Netwrix Change Tracker agent version is released, you can deploy it automatically from the Change Tracker Hub console. This article provides a comprehensive guide for downloading, uploading, and deploying agent updates, along with best practices for phased rollouts and troubleshooting common issues. + +> **Note:** For the most current agent update procedures and screenshots, refer to the official documentation: [Agent Updates](/docs/changetracker/8.0/admin/settingstab/agentsanddevices/agentupdates.html) + +> **END OF SUPPORT NOTICE** +> +> Gen 7 Agent v7.0.0 reached End of Support on **October 1, 2024**. +> +> Ensure all agents are upgraded to Gen 7 Agent v7.1 or later for continued support and security updates. + +## Prerequisites + +Before updating agents, ensure you have: + +1. **Downloaded the agent update files** from the Netwrix customer portal: + - **Path:** Netwrix > Members > Member Downloads > Latest Versions of Software and Support Information for Existing Customers > 01. Netwrix Change Tracker Gen 7 > Hub and Agent Downloads + +2. **Required files:** + - Netwrix Change Tracker Gen 7 Windows Agent Only Installer (`.zip`) + - Netwrix Change Tracker Gen 7 Windows Agent Control File for Auto Updates (`.upd` file) + +3. **Important:** Do NOT extract the zip files. They must be uploaded as zip archives to the Change Tracker console. + +4. **Permissions:** Administrator access to the Change Tracker console and IIS (for troubleshooting) + +## Security Considerations + +- **Update Integrity:** The `.upd` control file cryptographically signs the update to prevent tampering. +- **HTTPS Communication:** All agent-to-Hub communication is encrypted via HTTPS. +- **Scheduled Updates:** Consider deploying during maintenance windows to minimize disruption. +- **Network Security:** Ensure only authorized agents can access the Hub (use IP restrictions or VPN if needed). +- **Credential Protection:** Agent credentials are encrypted in HubDetails.xml. + +## Instructions + +### Step 1: Upload Agent Update Files + +1. Log in to the **Change Tracker console** through a web browser. + +2. Navigate to **Settings > Agent Updates**. + +3. Click the **Actions** button and select **Upload an Agent Update**. + +4. In the upload dialog, select both files: + - The agent installer `.zip` file + - The agent control `.upd` file + +5. Click **Open**, then click **Upload files**. + +6. Verify that both files appear in the Agent Updates list. + +![Agent update files](https://nwxcorp--c.na147.content.force.com/sfc/dist/version/download/?oid=00D7000000091pB&ids=0684u00000LdJrz&d=%2Fa%2F4u000000Lzsd%2FBurJF_bIoNw3JzJwCGWLeAlup_tkmAgHLN1IPXnwX_M&asPdf=false) + +### Step 2: Create or Select a Device Group + +For organized deployments, use device groups to control which agents receive updates and when. + +1. Navigate to **Settings > Groups**. + +2. Then, either select an existing group for the update, or click **+ Add** to create a new group. + + > **Note:** If creating a new group, provide a descriptive name that indicates the update phase or target devices (e.g., "Agent Update - Pilot"). + +### Step 3: Configure the Update Schedule + +1. Navigate to the group you created or selected. + +2. Click the **Agent Software Updates** tab. + +3. Click **+ Define the update schedule**. + +4. Configure the deployment: + - **Agent version:** Select the uploaded agent version from the dropdown. + - **Schedule:** Choose when the update should deploy: + - **Immediate:** Updates deploy as soon as agents check in. + - **Scheduled:** Specify a date and time for deployment. + +5. Click **Update** to save the schedule. + +![Agent update schedule](https://nwxcorp--c.na147.content.force.com/sfc/dist/version/download/?oid=00D7000000091pB&ids=0684u00000LdKHv&d=%2Fa%2F4u000000Lzn9%2F_1yH60.vjIMuX2cZFJxnW1pRRGEU2sHysN74dlIt6kY&asPdf=false) + +### Step 4: Assign Agents to the Update Group + +1. Navigate to **Settings > Agents & Devices**. + +2. Locate the device(s) you want to update. + +3. Click the **Edit** button for each device. + +4. In the **Groups** field, add the update group you configured (e.g., "Agent Update - Pilot"). + +5. Click **Update** to save the changes. + +6. The assigned agents will receive the update according to the defined schedule. + +### Step 5: Verify Update Deployment + +1. Navigate to **Settings > Agents & Devices**. + +2. Check the **Devices** tab to monitor update progress. + +3. Verify that updated agents show the new version number. + +4. Check that agents remain online and are communicating with the Hub. + +## Phased Rollout Strategy + +For production environments, implement a phased rollout to minimize risk: + +### Phase 1: Initial Pilot + +- Select 3-5 test devices representing different OS versions and configurations. +- Create a group: "Agent Update - Pilot". +- Deploy updates immediately. +- Monitor agent status and logs before proceeding. + +### Phase 2: Early Adopters + +- Select 10-20% of production devices. +- Create a group: "Agent Update - Early Adopters". +- Schedule updates during a maintenance window. +- Monitor for issues before broader deployment. + +### Phase 3: Staged Production Deployment + +- Deploy to remaining devices in batches. +- Create multiple groups by department, location, or criticality. +- Stagger deployments to manage risk. + +### Phase 4: Post-Deployment Verification + +- Confirm all agents are updated. +- Review agent logs for issues. +- Document lessons learned. + +## Testing Checklist + +Before deploying to production, verify: + +- [ ] Agent update files uploaded successfully +- [ ] Update schedule configured correctly +- [ ] Test devices assigned to pilot group +- [ ] Pilot devices updated successfully +- [ ] Updated agents communicate with Hub +- [ ] Policy templates apply correctly +- [ ] Compliance reports generate successfully +- [ ] Baseline data intact after update +- [ ] Event collection functioning normally +- [ ] Rolling logs show no errors + +## Rollback Plan + +If issues occur during deployment: + +1. **Halt Deployment:** + - Remove devices from update groups. + - Delete or modify the update schedule. + +2. **Assess Impact:** + - Check affected agent rolling logs. + - Review Hub server logs. + - Identify common failure patterns. + +3. **Manual Intervention:** + - Uninstall problematic agent version. + - Reinstall previous stable version. + - Reconfigure HubDetails.xml if needed. + +4. **Contact Support:** + - Gather rolling logs from affected agents. + - Document error messages. + - Open a [support ticket with Netwrix](https://netwrix.com/en/support/). + +## Troubleshooting + +### Upload Fails with "System Error / An unknown error occurred" + +**Symptom:** +- Upload fails with error: `System Error: An unknown error occurred` +- Message indicates: "X File(s) failed to upload" + +**Cause:** +The default IIS maxAllowedContentLength is too low for agent update files. + +**Resolution:** + +1. Stop IIS services: + ```bat + iisreset /stop + ``` + +2. Open the Web.config file: + ```text + C:\inetpub\wwwroot\Change Tracker Generation 7 (NetCore) Hub\Web.config + ``` + +3. Modify the `` node: + ```xml + + + + ``` + +4. Save the file and restart IIS: + ```bat + iisreset /start + ``` + +5. Retry the upload in the Change Tracker console. + +### Agents Not Receiving Updates + +**Check:** +- Agent is assigned to the correct group +- Update schedule is active and not expired +- Agent can communicate with Hub (check agent status) +- Agent has sufficient disk space for update +- Review agent rolling-log.txt for errors + +**Verify:** +- Hub server has outbound connectivity (if agents are remote) +- Firewall rules allow agent-to-Hub communication (port 443 by default) +- Agent service is running on target devices + +### Update Fails on Specific Agents + +**Common causes:** +- Insufficient disk space on agent system +- Antivirus blocking update installation +- Conflicting software or services +- OS version incompatibility + +**Actions:** +1. Check agent rolling-log.txt for specific error messages. +2. Verify OS compatibility with new agent version. +3. Add Netwrix agent paths to antivirus exclusions. +4. Free up disk space (minimum 500MB recommended). + +### Agent Goes Offline After Update + +**Immediate steps:** +1. Check if agent service is running. +2. Review rolling-log.txt for startup errors. +3. Verify HubDetails.xml configuration is intact. +4. Test network connectivity to Hub. +5. Check Windows Event Viewer for service errors. + +**If agent won't start:** +- Reinstall previous agent version. +- Verify .NET dependencies are installed. +- Check for conflicting software. + +## Version Compatibility + +| Agent Version | Hub Version | Release Date | Support Status | +|---------------|-------------|--------------|----------------| +| v7.1.x | v8.0, v8.1 | Jan 2024+ | ✅ Supported | +| v7.0.0.x | v7.x, v8.0 | 2017-2019 | ❌ EOS Oct 1, 2024 | +| v6.5.x | v6.5, v7.x | Pre-2017 | ❌ End of Life | + +> **Important:** Always verify compatibility in the release notes before deploying updates. + +## FAQ + +**Q: Can I update Linux agents from the console?** +A: No, this process applies to Windows agents only. Linux agents must be updated manually using RPM packages. + +**Q: How often should I update agents?** +A: Update agents when new versions address security vulnerabilities or critical bugs. Review release notes for each version. + +**Q: Can I schedule updates for specific times?** +A: Yes, use the schedule feature in the Agent Software Updates tab to specify deployment date and time. + +**Q: What happens if an agent is offline during the scheduled update?** +A: The agent will receive the update the next time it checks in with the Hub after the scheduled time. + +**Q: Do agents need to reboot after updating?** +A: Typically no, the agent service restarts automatically. However, some updates may require a system reboot (check release notes). + +**Q: Can I cancel an in-progress update?** +A: Once an agent begins installing an update, it cannot be cancelled. However, you can remove devices from the update group to prevent additional deployments. + +**Q: Where can I see the current agent version?** +A: Navigate to Settings > Agents & Devices. The version is displayed in the Devices tab for each agent. + +## Related Links + +- [Agent Updates (Official Documentation)](/docs/changetracker/8.0/admin/settingstab/agentsanddevices/agentupdates) +- [Device Groups](/docs/changetracker/8.0/admin/settingstab/devicegroups) +- [Gen 7 Agent Deployment Options](/docs/changetracker/kb/gen-7-agent-deployment-options) +- [Agent and Device Ports](/docs/changetracker/8.0/requirements/agentdeviceports) +- [Component Release History](/docs/changetracker/8.0/componentreleases) diff --git a/docs/kb/changetracker/database-and-diagnostics/decouple-the-redis-application-from-change-tracker.md b/docs/kb/changetracker/database-and-diagnostics/decouple-the-redis-application-from-change-tracker.md new file mode 100644 index 0000000000..f903bdce62 --- /dev/null +++ b/docs/kb/changetracker/database-and-diagnostics/decouple-the-redis-application-from-change-tracker.md @@ -0,0 +1,199 @@ +--- +description: >- + Explains how to decouple Redis from Change Tracker and install it on a Linux + system to address security vulnerabilities in the Windows version. Includes + installation, configuration, and connectivity setup instructions. +keywords: + - Netwrix Change Tracker + - Redis + - message broker + - Linux installation + - Redis configuration + - Hub Workers + - vulnerability scanner + - Redis password + - firewall configuration +products: + - change-tracker +sidebar_label: Decouple Redis from Change Tracker +tags: [] +title: Decouple the Redis Application from Change Tracker +--- + +# Decouple the Redis Application from Change Tracker + +## Scenario + +Redis is used by Change Tracker to cache information between Change Tracker and all the workers within the Change Tracker architecture. By default, Redis is installed on the Change Tracker server and runs as a service. At the time of writing, the version of Redis installed on Windows is 3.2, but the current stable release is 5.0.8, which means vulnerability scanners may identify the need for Redis to be upgraded. Version 3.2 is the latest version of Redis available for Windows, and to upgrade Redis, the application needs to be decoupled and installed onto a Linux system. + +Change Tracker only uses Redis as its message broker to keep all the Worker devices in sync when there are changes to the Change Tracker configuration. The Redis communication channel broadcasts when any of the following changes occur: + +- Groups, Devices +- Planned Changes +- Config (System) Settings +- IP Address Blocking +- Report or Tracking Templates + +## Summary of Tasks + +- Build a Linux system +- Ensure connectivity between the Change Tracker server, all Hub Workers, and the new Linux system +- Install and configure the Redis configuration file on the Linux system +- Configure Change Tracker to connect to Redis +- Disable the local Redis Service and restart the worker services + +## Build a Linux System + +Redis can be run on a variety of Linux distributions, including CentOS, RHEL, and AWS Linux. Any current version of the operating system should be suitable for the Redis installation. The system hosting Redis can be minimal, as we are not caching anything in RAM; Redis can be used as an in-memory datastore, but we are only using the message broker function. + +- 2 vCPUs +- 2GB RAM +- Default port: 6379 + +## Ensure Connectivity Between Change Tracker Server, All Hub Workers, and the New Linux System + +The Redis default port is 6379; however, this can be changed to a port of your choosing. + +If using Windows, check that the Redis port is allowed outbound. + +Check that the Linux system's firewall is running, and if so, add a rule to allow for the Redis connection. Below is a list of useful commands that can be used for testing from CentOS 7. + +```plaintext +# firewall-cmd --state +# firewall-cmd --permanent --add-port=6379/tcp +# firewall-cmd --reload +# firewall-cmd --list-ports +``` + +## Install, Compile, and Configure Redis on the Linux System + +### Install from a Repo + +```plaintext +# rpm -ivh https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm +# rpm -ivh https://rpms.remirepo.net/enterprise/remi-release-7.rpm +``` + +NOTE: The below relates to RHEL. If using CentOS, this line can be dropped. + +```plaintext +# subscription-manager repos --enable=rhel-7-server-optional-rpms +``` + +```plaintext +# yum install -y redis --enablerepo=remi +# systemctl start redis +# systemctl enable redis +``` + +Change the following lines in `redis.conf`: + +```plaintext +# sudo nano /etc/redis.conf +``` + +Use the search functions of your text editor to find the line within the config file that needs to be changed. + +Add the IP address of the port for which the Change Tracker will connect. + +```plaintext +bind 127.0.0.1 -> bind 127.0.0.1 172.31.21.101 +``` + +Change the following settings in the Redis configuration file: + +```plaintext +daemonize no -> daemonize yes +protected-mode yes -> protected-mode no +``` + +### Configuring a Redis Password + +Note: A complex password can be created using the line below: + +```plaintext +echo "RedisForChangeTracker" | sha256sum +c28b560b2b8dd06bf9f7b0fa873365a9a95a9947860d4b60b7849702bce13f8b +``` + +Configuring a Redis Password in the Redis configuration file: + +```plaintext +# requirepass foobared -> requirepass +``` + +Restart the Redis service: + +```plaintext +# systemctl restart redis +``` + +## Check the Service is Running and Using Authentication + +From the Linux command prompt: + +```plaintext +# redis-cli +127.0.0.1:6379> ping +(error) NOAUTH Authentication required. +127.0.0.1:6379> auth +OK +127.0.0.1:6379> ping +PONG +``` + +## Configure Change Tracker to Connect to Redis + +### Run the Netwrix Maintenance Application + +Run the Netwrix Change Tracker maintenance application to reconfigure the Redis configuration. + +Open PowerShell and run as administrator: + +```plaintext +cd "C:\Program Files\NNT Change Tracker Suite\Gen7\Maintenance" + +.\NNT.Hub.Service.Maintenance.App.exe -e Production -l "C:\inetpub\wwwroot\Change Tracker Generation 7 (NetCore) Hub\Configs" +``` + +From the options that appear, select **M** to modify DB and Cache Service connection details and answer the questions that are specific to your configuration. + +```plaintext +Select option from menu above and press ENTER : M +Has Database Username/Password authentication been removed from the connection? Please provide a yes or no answer. +yes +Please provide a Connection String or press Enter to retain the current value (mongodb://localhost). + +Please provide a Database Name or press Enter to retain the current value (NNTHubService). + +Please provide a yes or no answer to using an SSL certificate to protect the Database Connection or press Enter to retain the current value (no). + +Has the Password requirement for the Cache server (Redis) connection been removed? Please provide a yes or no answer. +no +Please provide a host name for the Cache server (Redis) or press Enter to retain the current value (172.31.21.101). + +Please provide a port number for the Cache server (Redis) or press Enter to retain the current value (6379). + +Please provide the Password required to connect to the Cache server (Redis). + +``` + +To confirm that the Redis configuration has changed, check the Production JSON file using a text editor. The Redis entries within the editor should look like this: + +![Redis Configuration](https://nwxcorp--c.na147.content.force.com/sfc/dist/version/download/?oid=00D7000000091pB&ids=0684u00000LdK8r&d=%2Fa%2F4u000000M0CY%2FQvMM00AZ.qEgABMbSfa1B2552qW5IQfsgwS6Ul9HrSc&asPdf=false) + +## Disable the Local Redis Service and Restart the Worker Services + +From the service manager or via PowerShell, stop the Redis service and change the startup status to Disabled. + +```plaintext +Stop-Service Redis +Set-Service -Name Redis -StartupType Disabled +``` + +Once Redis is disabled, restart the worker service to pick up the change in the Redis configuration. + +```plaintext +Restart-Service NNTWorker.AllPurpose +Restart-Service NNTWorker.HubTasks +``` diff --git a/docs/kb/changetracker/troubleshooting-and-errors/how-to-determine-if-the-default-agent-password-is-in-use.md b/docs/kb/changetracker/troubleshooting-and-errors/how-to-determine-if-the-default-agent-password-is-in-use.md new file mode 100644 index 0000000000..46649355b8 --- /dev/null +++ b/docs/kb/changetracker/troubleshooting-and-errors/how-to-determine-if-the-default-agent-password-is-in-use.md @@ -0,0 +1,192 @@ +--- +description: >- + Use the UI indicators and provided scripts to determine whether the default + agent account password is in use on the Netwrix Change Tracker Hub. Includes + PowerShell and Bash scripts for versions prior to 7.7.4 and guidance for + versions 7.7.4 and later. +keywords: + - default password + - agent account + - Netwrix Change Tracker + - hub + - PowerShell + - Bash + - authentication + - 7.7.4 +products: + - change-tracker +sidebar_label: 'How to Determine If the Default Agent Password Is ' +tags: [] +title: How to Determine If the Default Agent Password Is in Use +--- + +# How to Determine If the Default Agent Password Is in Use + +> **LEGACY SYSTEM NOTE** +> +> This article applies to legacy Change Tracker installations only. +> +> **Current versions (v8.0+) automatically generate unique passwords for each agent.** +> +> Use this article to: +> - Verify your installation has upgraded from the legacy default password +> - Detect if any legacy systems still use the default password + +## Overview + +An account named `agent` is created during the installation of the Netwrix Change Tracker Hub. In versions prior to 7.7.4, it was recommended that the `agent` account's default password be updated after installation of the Hub. Since the release of 7.7.4, a complex password for the `agent` account is required to be entered during installation. + +## Instructions + +### Versions post-7.7.4 + +Versions of the Hub from 7.7.4 will warn if any agent is using the default password by displaying the following warning in the bottom right of the screen. + +![Default password warning.png](./images/ka0Qk00000078VV_0EMQk00000863Ej.png) + +The User Notifications page will also display the warning. + +![Default password warning 2.png](./images/ka0Qk00000078VV_0EMQk00000860Li.png) + +### Versions pre-7.7.4 + +For users on versions prior to 7.7.4, the scripts below can be used to determine whether an agent is using the default password. These scripts can be rolled out by an IT automation system. However, if only one account is used by agents to authenticate, then manually running it on one device will be enough as all agents will be using the same authentication details. + +The script asks for the Hub's URL and attempts to authenticate as an agent by using the default password. If it connects, then the default password is in use and the following outputs will be produced. + +Refer to the following examples of default passwords in use if using versions prior to 7.7.4. + +Windows + +![Default password in use on Windows.png](./images/ka0Qk00000078VV_0EMQk0000085xEB.png) + +Linux + +![Default password in use on Linux](./images/ka0Qk00000078VV_0EMQk00000863eX.png) + +If it fails to connect, then the default password is **not** in use and the following outputs will be seen. + +Windows + +![Default password not in use on Windows.png](./images/ka0Qk00000078VV_0EMQk0000085xm3.png) + +Linux + +![Default password not in use on Linux.png](./images/ka0Qk00000078VV_0EMQk0000085xZ8.png) + +For users on versions prior to 7.7.4, the scripts below can be used to determine if an agent is using the default password. + +### Windows (PowerShell) + +```powershell +# You should modify the host to match with the ChangeTracker host being tested +$CT_HOST="http://192.168.18.16:5000" +Write-Host "Modify the ChangeTracker host (CT_HOST value) if this appears incorrect -> ChangeTracker Host :" $CT_HOST + +# Default Agent settings +$agentUser='agent' +$defaultAgentPwd="passWord123" + +Function TrustAnyCertificate() +{ + if ("AnyCertificatePolicy" -as [type] -eq $null ) { +add-type @" + using System.Net; + using System.Security.Cryptography.X509Certificates; + + public class AnyCertificatePolicy : ICertificatePolicy { + + public AnyCertificatePolicy() {} + public bool CheckValidationResult( + ServicePoint sPoint, X509Certificate cert, + WebRequest wRequest, int certProb) { + return true; + } + } +"@ + Write-Host "Added trust for any HTTPS certificate" + } + [System.Net.ServicePointManager]::CertificatePolicy = new-object AnyCertificatePolicy +} + +TrustAnyCertificate + +Try { + + Write-Host "Acquiring User Session: $agentUser ("$CT_HOST.replace("=$defaultAgentPwd", "=******")")" + + $headers = New-Object "System.Collections.Generic.Dictionary[[String],[String]]" + $headers.Add("Accept", "application/json") + $params = "username=$agentUser&password=$defaultAgentPwd&format=json" + + $response = Invoke-RestMethod "$($CT_HOST)/api/auth/credentials" -Method 'POST' -Headers $headers -Body $params + + if ($null -ne $response -and $response.UserId -ge 0) { + Write-Output "WARNING: The default password for the User 'agent' is still active." + } + +} +Catch [System.Exception] { + $resp = $_.Exception.Response; + if ($null -ne $resp -and $resp.StatusCode -eq [Net.HttpStatusCode]::Unauthorized) { + Write-Output "The default password for the User 'agent' is NOT active." + } + else { + if($null -ne $resp -and $resp.StatusCode -eq [Net.HttpStatusCode]::Forbidden) { + Write-Output "The agent account is currently blocked" + Write-Output $_.Exception.Message + } + else { + Write-Output "Error occured, ensure the correct ChangeTracker host has been specified." + Write-Output $_.Exception.Message + } + } +} +Read-Host -Prompt "Press any key to finish" +``` + +### Linux (Bash) + +```bash +#!/bin/bash + +# You should modify the host to match with the ChangeTracker host being tested +CT_HOST="https://192.168.18.16" +echo "Modify the ChangeTracker host (CT_HOST value) if this appears incorrect -> ChangeTracker Host: $CT_HOST" + +# Default Agent settings +agentUser='agent' +defaultAgentPwd="passWord123" + +echo "Acquiring User Session: $agentUser (${CT_HOST//=$defaultAgentPwd/=******})" + +# Set headers and parameters +headers="-H 'Accept: application/json'" +params="username=$agentUser&password=$defaultAgentPwd&format=json" + +# Make the API call using curl (with sudo), and capture the response and HTTP status code +response=$(sudo curl -sS -k -X POST "$CT_HOST/api/auth/credentials" \ +-H "Accept: application/json" \ +--data "$params" \ +--write-out "%{http_code}" --output response_body.txt) + +# Read the HTTP status code +http_code="${response: -3}" # Last 3 characters of the response variable +response_body=$(