Rapid Response to Bulk Account Changes with Ansible

Open Source (OSS) / By
Servers, a network switch, and a CCTV camera linked to one automation console for account-credential changes

When a security incident such as an account-credential leak occurs, changing accounts across many information systems is an urgent and essential task. This article explains WIKI Security’s approach to building and optimizing open source software so that bulk account-credential changes can be automated with Ansible and handled quickly.

1. Why Automation Is Needed for Large-Scale Credential Changes

In a security incident where an account-credential leak is suspected, credentials within the affected scope must be revoked or changed quickly. If the information systems are spread across headquarters, branches, plants, and remote sites, manual logins and site visits alone cannot secure the speed or consistency the response requires.

Windows and Linux servers, routers and switches, firewalls, and CCTV and NVR systems in particular differ in how they are accessed and how their accounts are managed. After a change, you must confirm not only that the new credentials work, but also the effect on service accounts and connected systems.

  • Servers (SSH, WinRM, OS account-management modules) — watch dependencies of service accounts and scheduled tasks
  • Network and security appliances (SSH/CLI, HTTP(S) API) — watch for differences in vendor commands and privileges
  • CCTV, NVR, and dedicated devices (a standard management interface or a vendor API) — watch the effect on video, recording, and linked accounts

(*) An effective approach: instead of logging in to every system one by one, standardize the change against proven management interfaces and run it in batches.

2. Automating Account-Credential Changes with Ansible

Ansible is an open source IT automation tool widely used by engineers for server configuration management, application deployment, and infrastructure provisioning.

Ansible is appealing to information security engineers as well as to IT teams that repeat the same work, because it is agentless, declarative, easy to read, and based on Python.

Ansible defines the systems to manage in an Inventory and handles tasks in sequence, including errors, in a Playbook. The actual change is carried out through an operating-system module, SSH/CLI, or an HTTP(S) management API. Equipment that needs a separate adapter can be connected with Python or a similar language. The conceptual flow for automating bulk credential changes with Ansible is shown below.

  1. Target asset Inventory: IP, asset ID, vendor/model, approval status
  2. Ansible Playbook: pre-check → batch control → run the change → handle the result
  3. Management interface / API adapter: SSH and WinRM, REST API, standard and vendor-specific APIs
  4. Servers, network devices, security appliances, CCTV, and others: change credentials only for approved targets
  5. Post-change verification and evidence: new authentication, invalidation of the old credentials, service health, and exception classification

3. Use Case: Bulk Password Changes across Heterogeneous Information Systems

This case assumes heterogeneous information systems that use different management APIs, and configures Ansible to select an API type for each device and to change the password and re-authenticate. The code below is a simplified example of a mock API used in a real test. It is not a universal change command that can be used unchanged on every vendor’s equipment.

3.1 Selecting the Target and the Adapter

# inventory.ini (example)
[managed_devices]
device01 ansible_connection=local api_type=alpha camera_url=http://127.0.0.1:18081
device02 ansible_connection=local api_type=beta  camera_url=http://127.0.0.1:18082
….

The vendor-specific endpoint and HTTP method are selected from the api_type value in the Inventory.

# rotate.yml example — select the API by vendor
change_endpoint: "{{ '/api/v1/password' if api_type == 'alpha'
                     else '/vendor-b/security/admin' }}"
change_method: "{{ 'POST' if api_type == 'alpha' else 'PUT' }}"

3.2 Running the Change and Verifying Re-authentication

The same Playbook processes several devices in batches and checks not only whether the request succeeded, but also whether the new credentials are valid.

- name: Change password via selected API
  ansible.builtin.uri:
    url: "{{ camera_url }}{{ change_endpoint }}"
    method: "{{ change_method }}"
    headers:
      X-Current-Password: "{{ old_password }}"
    body_format: json
    body: "{{ change_body }}"
    status_code: 200
  no_log: true

- name: Verify new credential
  ansible.builtin.uri:
    url: "{{ camera_url }}/api/v1/auth-check"
    headers:
      X-Current-Password: "{{ new_password }}"
    status_code: 200
  no_log: true

In production, a different new password should be issued for each device and retrieved from an encrypted secret store. Vendor-specific response codes, authentication methods, invalidation of the old credentials, health of connected services, and handling of an unknown state (UNKNOWN) after a failure must also be implemented separately.

3.3 Verification Results and Conditions for a Wider Rollout

When account credentials are changed across a large number of information systems, a successful change command is not enough. You must also verify that the credentials actually changed and that related services still operate normally.

With Ansible, the result of each system can be collected automatically, and the following checks can be built in.

  • New credential check: confirm that authentication succeeds with the changed password
  • Old credential invalidation: confirm that the previous password no longer authenticates
  • Service health check: confirm whether the account change disrupted the system or a connected service
  • Failure and exception handling: separate systems that failed to change, lost communication, or are in an unknown state (UNKNOWN), and take follow-up action
  • Results and evidence: record the change time, execution result, and verification status for each system, and produce a report

When the work covers many systems, it is important to select representative systems by vendor, model, and operating environment and run a pilot first, rather than changing every system at once.

During the pilot, check API compatibility, the credential change and re-authentication, the effect on related services, and the failure-recovery procedure, and then expand the scope in stages.

Ansible’s batch execution (serial) and concurrency control (forks) let you adjust the scale of the work to the operating environment. The job can also be designed so that an error on some systems is identified automatically, and unfinished systems are rechecked and followed up.

This staged approach reduces the operational risk of a bulk credential change and helps secure both speed and stability in the early response to a security incident.

Frequently Asked Questions (FAQ)

Q1. Does every information system need a separate program installed in order to use Ansible?

Not necessarily. Ansible can use existing management interfaces such as SSH and HTTPS APIs, so network equipment and CCTV systems can be automated without installing a separate agent.

The target system does need a suitable management protocol and the right privileges. Depending on the module used, Windows and Linux servers may also need additional connection and runtime settings.

Q2. Can servers, network equipment, and CCTV systems from different vendors and models be managed with one Ansible Playbook?

Yes. The operating system, vendor, model, and management protocol of each device can be defined in the Ansible Inventory, and the Playbook can select the appropriate module or API adapter according to those conditions.

For example, a Linux server can use SSH, network equipment can use a vendor CLI, and a CCTV system can use a supported HTTP API.

Not every vendor and model is supported automatically. Before a real rollout, the management functions and API compatibility of each device must be verified.

Q3. When passwords are changed on thousands of systems, is there a risk that the old and new passwords will be exposed?

Passwords and authentication keys can be protected with Ansible Vault or a separate secret-management system. Setting no_log: true on tasks that handle sensitive data also keeps passwords out of the execution log.

In practice, the following should be applied together.

  • Use a unique password for each device
  • Encrypt credentials and restrict who can access them
  • Encrypt the communication path
  • Prevent passwords from appearing in logs and result files

Ansible Vault encrypts stored data, so protection of credentials while a job is running, and management of the logs, still need to be considered separately.

Q4. What should be done if some systems fail or a service is disrupted during a bulk change?

Ansible features such as serial, block/rescue, and conditional execution can split the targets into small batches and handle failed devices separately.

In live operation, the following procedure is recommended.

  1. Test the change in advance on a representative device
  2. Run the change in small batches
  3. Re-authenticate with the new password and confirm that related services are healthy
  4. Classify devices that failed or whose state is unknown
  5. Find the cause of the failure, then rerun or recover according to the approved procedure

A successful response from the password-change API is not enough to treat the job as complete. A device that lost connectivity during the change, in particular, must be checked to see whether the change actually took effect before it is processed again.

Q5. What should be prepared to automate account-credential changes with Ansible, and what does WIKI Security support?

First, confirm the Inventory of systems to be changed (IP, operating system, vendor, and model), the path into the management network, the authentication method, dependencies between accounts, and the approval procedure for the work.

Next, test the management commands on the actual equipment and build an Ansible Playbook that includes the change, verification, and recovery.

WIKI Security reviews the customer’s existing IT environment and supports the following work.

  • Selecting automation targets and reviewing whether they can be applied
  • Installing Ansible and designing the security architecture
  • Connecting management APIs for heterogeneous systems
  • Building Playbooks and the automation execution system
  • Verifying change results, handling failures, and optimizing operations

OSS-Based Security Automation with WIKI Security

Turning the cost advantage of open source into a real operational result requires a design that fits the customer’s environment and the capability to build it professionally.

WIKI Security supports the design, implementation, heterogeneous-system integration, and operational optimization of OSS-based security automation, including Ansible.

If you want to automate repetitive administration of the servers, network devices, and security appliances you operate today, consider WIKI Security’s OSS-based security automation service.