Removed user still exists in cache for months (UNAB-AD)

Products

• CA Privileged Identity Management Endpoint (PIM)

Issue/Introduction

A user that was defined in Active Directory and used in UNIX server via UNAB after deleting it in AD for UNAB (cache) "see" it as a local disabled user for very long period of time (if not forever) and this gives a possibility to work with this non-existed from administrative point of view user with any tool for non-password login ('su -' as root or even public_key-authenticated ssh).

Faced the problem as a "user disappeared" problem for user, that was work for months from scheduler (that use 'su -' to launch tasks with different owners) after UNAB cache clean operation - nobody knows now when, why and by whom the user was deleted from AD months (or may be years) ago - we checked last month - it was not there.

Any worker before leave the organization can make for his user public_key-authentication in his home dir and still use the permissions of user, that was actually deleted from AD by ssh without password...

Removing the cache (by removing *.db files from /opt/CA/uxauth/etc before starting unab) removes all this "illegal" users on specific server, but it's not a solution.
In uxauth.ini we have:

# grep cache /etc/uxauth.ini | egrep -v '^#|^;'
nss_cache_update_startup = 1
nss_cache_update_usr_mode = 1
nss_cache_update_grp_mode = 1
nss_cache_update_interval = 60
nss_cache_update_usr_login = yes
nss_cache_update_grp_login = yes
nss_cache_update_post_job = none
pam_delete_user_ccache = yes
pam_leave_user_ccache = no

 

here is an example of deleting a user account on the endpoint side:

uxconsole -db -del pw aduser1

Another option :  One can leave the nss_xxx tokens as they are and even with UNAB up, purge user data in nss.db (sqlite3 /opt/CA/uxauth/etc/nss.db  'delete from pw') and on the next update uxauthd will re-populate cache without deleted account.
So it is not about a bug, but rather about sysadmin's knowing what is best and how to do it.  For instance, purging rather than waiting for a full update may be preferred under particular circumstances since its effect is immediate.

Environment

UNAB all versions

Cause

Guidance

Resolution

Answer:

nss.db is set up to be updated incrementally, i.e., accounts introduced (new) or modified since the last nss.db update are picked up or updated.   A user or group that is deleted on the AD side is none of those, so it stays in nss.db as is afterwards.   It can be deleted on the endpoint using uxconsole -db -del functionality.   Alternatively,  UNAB can be switched to full-update mode either (A) at startup or (B) during periodic updates, i.e.,  

(A)
nss_cache_update_startup = 2

(B)
nss_cache_update_usr_mode = 2
nss_cache_update_grp_mode = 2

Each of these has advantages and disadvantages: it is up to the admin to pick the approach that suits them best.  It is feasible to introduce a mechanism to clean up deleted accounts by uxauthd, but in view of its performance impact and ability to easily address that behavior (if it is a problem) using above means it was not implemented.