The sign you are doing good automation

Let me help you with passwords

I am bad at AIX automation. Not because I don’t know AIX or Ansible. I know how to use them. However, for me, the biggest advantage of them is that they automate my work. I don’t go deep into details. The playbook is run, the work is done. Was it wrong? Let’s change it and run it one more time.

Many of you work the other way. The playbook must not only run but also produce no failures or a changed state if nothing was changed. Sometimes we need IBM support to get Ansible working as it should. Sometimes IBM support needs time or community support to find a solution. Let’s help IBM support!

The problem with passwords

The problem is reported. You can find it on Github.

If you set a user’s password, it is always set. It is not checked if the password is the same as the old password.

First run:

Second run:

As for me, not the biggest problem! The password stays the same, and the user can be used.

On the other side are security requirements. If you set the password in the playbook and the playbook runs daily, then your last password change time is updated daily. You lose the possibility to check when you last changed the user’s password. There are environments where you must change users’ passwords regularly.

Compare the lastupdate attribute to the last playbook run time:

Check the password on AIX

AIX password hashes are stored in /etc/security/passwd. This is a normal text file, and you can look at it with view or edit it with vi.

The file has AIX standard stanza format. Each user entry is a stanza with the name of the user. Let’s say we have a user named user01. Then the stanza would look like:

The first field, password, contains the hash of the password.

The second field is a UNIX timestamp, showing when the password was last changed.

There can be a third field with flags.

In our case, the first field is important. It contains the password hash. The field also has some “sub-fields”. First, we see the hashing algorithm in curly braces - {ssha512}. The next is the “cost” of the algorithm. It is 06 in this case.

Between dollar signs is the “salt” value, which is used to hash the original password. After the dollar sign is the hash of the password.

The main rule is that if you use the same hashing algorithm, with the same cost and the same salt, you will always get the same hash.

This is the principle of how the standard UNIX authentication works.

We can slightly modify the playbook and watch that the hash is always the same.

First run:

Second run:

As you see, it is the same hash as on the server.

Compare the hashes using Ansible

I would like to use the same command I used to get the last update field from /etc/security/passwd, but unfortunately it doesn’t work with password hashes:

It means we must use standard UNIX tools. Remember, /etc/security/passwd is a standard text file:

How would it look in Ansible?

    - name: Get hash from the server
      ansible.builtin.shell:
        cmd: grep -p user01 /etc/security/passwd | awk '/password/ {print $NF}'
      changed_when: false
      failed_when: false
      register: existing_hash

If the password is defined for the user, we have the hash in existing_hash.stdout_lines.0. We must only check if it is set:

    - name: Create user
      ibm.power_aix.user:
        name: user01
        password: "{{ pwhash.hash }}"
        state: present
        change_passwd_on_login: false
      when: |
        existing_hash.stdout_lines.0 is not defined or
        existing_hash.stdout_lines.0 != pwhash.hash

Done?

Yes and no.

The problem is solved. But if you add some user attributes into the playbook, like:

    - name: Create user
      ibm.power_aix.user:
        name: user01
        password: "{{ pwhash.hash }}"
        state: present
        change_passwd_on_login: false
        attributes:
          rlogin: "true"
      when: |
        existing_hash.stdout_lines.0 is not defined or
        existing_hash.stdout_lines.0 != pwhash.hash

and want to change them next time, they will be skipped. Only because the password is the same. It is wrong. We must check each attribute, and this is the job for the Ansible module, not for our playbook.

The function change_password

This is the function in the power_aix Ansible collection, that is responsible for setting users’ passwords:

We must add password hash comparison to it, but only if load_modules is set to files.

The comparison can look like:

The next problem is that the function returns only one value - the message. Whenever the function is called, it is assumed that the function changed the password or failed.

We must return two values - the message and if the password was changed:

But it means that we must change the function calls:

and:

The new function:

AI Assistant for AIX

We are developing AI Assistant for AIX.

This is an AIX-specific AI chatbot that can answer all (or many) of your questions regarding AIX. It is trained by experts in both AI and AIX to help next-generation administrators solve daily problems. The first beta will be available in September 2025. Now you can subscribe to get a notification when the beta is open. The beta version will be free and available only online. But we have an on-prem version in the roadmap, too.

Subscribe to the free beta here - https://shop.power-devops.com/assistant-aix

Done!

Now it works as it should. If the user doesn’t exist, it is created, and a password is set. If the user's attributes are changed, the new attributes are set. If nothing is changed, OK is the answer.

What's next?

I will create a pull request for the module and hope that it will be implemented in the next version.

But I have a to-do item for you. Go to Github and submit at least one issue that you had with the ibm.power_aix Ansible collection. Let’s make it better together!

Have fun with AIX password and Ansible!

Andrey

Hi, I am Andrey Klyachkin, IBM Champion and IBM AIX Community Advocate. This means I don’t work for IBM. Over the last twenty years, I have worked with many different IBM Power customers all over the world, both on-premise and in the cloud. I specialize in automating IBM Power infrastructures, making them even more robust and agile. I co-authored several IBM Redbooks and IBM Power certifications. I am an active Red Hat Certified Engineer and Instructor.

Follow me on LinkedIn, Twitter and YouTube.

You can meet me at events like IBM TechXchange, the Common Europe Congress, and GSE Germany’s IBM Power Working Group sessions.