RE: [EXT] Re: The format of password change audit events seems to have changed, Can you confirm the correct record type ?

Warren, I missed this part of your message. I double checked the rules on a different RHEL 7.9 system , and it looks like we are only picking up password change attempts for accts in the user space, but not root, so if the password was changed directly from a root login rather than via sudo from another acct, we probably won’t see some of the related audit records. This is the rule I believe is picking up password change events: –a always,exit –F path=/usr/bin/passwd –F per=x –F auid>=1000 auid!=4294967295 –k privileged passwd There are also a specific watches on /etc/shadow and gshadow: -w /etc/shadow –p wa –k identity I just attempted , from a non-priv acct, to change the root passwd, and I see the following relevant audit records key-value pairs : This shows I successfully ran the passwd command and that the root acct was targeted , type=PROCTITLE ... proctitle=passwd root ... type=PATH name=/usr/bin/passwd type=SYSCALL ... comm=passwd exe=/usr/bin/passwd success=yes key=setuid This shows that a password change was attempted and failed, but doesn’t seem to correctly indicate that the root acct was targeted (id=myusername, not root): Type=USER_CHAUTHOK auid=myusername msg=’op=attempted-to-change-password id=myusername exe=/usr/bin/passwd res=failed So... based on this, unless the patch versions are a bit different between the two RHEL7.9 systems I’ve been looking at, it looks like you are actually generating a reasonable message when a password change is attempted, but we probably need to make sure we are picking up all password changes, not just those in the user space. I unfortunately don’t have permission to change the audit rules, but will see if I can the SA to test this for me. If you are able to test in your environment and can confirm my findings, that would be wonderful, but I think we probably found our smoking gun, LOL. Thanks so much, Karen Wiepecht