🔐 Preventing AD Lockouts When Automating Aruba Devices with Ansible

When you're automating configuration backups or deployments across Aruba switches using Ansible, there's a real risk of getting your AD account locked out—especially if multiple SSH sessions fail or time out simultaneously. We hit this exact issue when a few unreachable devices caused a cascade of authentication failures.

The most common cause? Parallel sessions trying to authenticate at once, often against AOS devices that require an enable password or have strict SSH key exchange settings.

Example 1: Run your playbook with 2 concurrent forks

ansible-playbook backup.yml -i inventory.yaml -f 2

Example 2: Inventory group for AOS switches

all:
  children:
    aruba_aos:
      hosts:
        switch01:
        switch02:
        switch03:
      vars:
        ansible_connection: network_cli
        ansible_user: "{{ vault_username }}"
        ansible_password: "{{ vault_password }}"
        ansible_become: true
        ansible_become_method: enable
        ansible_become_password: "{{ vault_enable_password }}"
        ansible_ssh_common_args: '-o KexAlgorithms=+diffie-hellman-group14-sha1'

Example 3: Graceful error handling in the playbook

- name: Backup running config
  hosts: aruba_aos
  gather_facts: no

  tasks:
    - name: Get running config
      raw: show running-config  
      register: output
      ignore_errors: yes

    - name: Save config to file
      copy:
        content: "{{ output.stdout[0] }}"
        dest: "backups/{{ inventory_hostname }}.txt"
      when: output.stdout is defined

With these steps in place, our backups completed without triggering any AD lockouts, even when some switches timed out or had outdated SSH settings. We could re-run the playbook safely without re-auth failures.

Pro tip: Aruba AOS devices often require an enable password even for read-only commands. Make sure it's set correctly in your inventory or vault.