Design an Ansible account provisioning workflow

Account creation often spans multiple systems. A Windows directory holds the user object and Unix identity attributes. An Identity Management (IdM) environment may need an ID override for trusted domain users. Automation Controller provides the operator interface.

The durable design is one job with clearly separated execution contexts and explicit validation.

1. Define the input contract#

Use an Automation Controller survey to collect the identity fields that change per request:

• Username and display name
• UID and GID
• Home directory
• Login shell, if your standard permits choices

Store fixed infrastructure settings in inventory or version-controlled variables. Keep domain controller and IdM host names in configuration, rather than entering them in every survey.

2. Split the workflow by target#

A single playbook can contain multiple plays. The Windows play runs against an Active Directory management host over WinRM. The Linux play connects to an IdM management host over SSH.

---
- name: Create and configure the AD identity
  hosts: ad_management
  gather_facts: false
  tasks:
    - name: Validate supplied UID and GID
      ansible.builtin.assert:
        that:
          - uid | int > 0
          - gid | int > 0

    # Use your approved AD modules and attributes here.

- name: Apply the IdM trust-view override
  hosts: idm_management
  gather_facts: false
  tasks:
    - name: Inspect the selected identity values
      ansible.builtin.debug:
        msg: "Preparing override for {{ username }}"

    # Create or update the Default Trust View override here.

This is an architectural example, not a complete provisioning playbook. The exact modules and IdM commands depend on your trust configuration, permissions, and installed collections.

3. Make identity changes idempotent#

Start by checking whether the account exists. Enforce uniqueness for username and UID, define what happens when an existing value conflicts, and verify the results after each system change.

Consider the failure mode where AD succeeds and the IdM override fails. The run should produce an actionable error and a safe retry path. Avoid silently creating multiple identities or resetting credentials on a retry.

4. Keep secrets in the right place#

Use Automation Controller credentials for WinRM and SSH. Configure which hosts each play targets and how each credential is used. Avoid fixed initial passwords and printed passwords in job output. Use the approved password generation and delivery policy for your environment.

5. Prove the end state#

A successful job needs more than a green Ansible result. Confirm the AD object, the intended Unix attributes, and the IdM override. Test the final resolved identity on a trusted Linux client when practical.

A good automation job returns the account name, UID, GID, target view, and verification status without revealing secrets.

References: Ansible playbooks and Red Hat IdM documentation.