How to discriminate an specific local user from constant queries to AD for authenticate

Document ID : KB000074280
Last Modified Date : 24/05/2018
Show Technical Document Details
Issue:
We have already changed the token in uxauth.ini user_minimal_uid = 990 just to disable most of the local users to constantly looking AD to authenticate.
It was fine till we find another local user which UID is 2005 but cannot change the above parameter because Active Directory (AD) uidNumbers begin in 1000.

mymachine:/opt/CA/uxauth # grep -w myuser /etc/passwd

myuser:x:2005:2005::/home/op:/bin/bash

This results in multiple queries for lookup in AD being written to /var/log/messages. Entries may be causing the messages from filling

2018-03-07T17:58:39.836271+01:00 sc1001 uxauthd[15469]: Looking for user 'myuser' in 'DC=mydc,DC=myorg,DC=myent,DC=com' as (&(objectCategory=person)(objectClass=user)(sAMAccountName=myuser))

Is there another parameter to avoid this situation?. Is possible to change some attributes of /etc/pam.d/common-auth to manage this user?
Environment:
PAM SC 14.0 and PIM 12.X endpoints on Linux
Resolution:
Assuming UNAB is being used in full integration mode, it is possible to configure complete exclusion of processing of local accounts from UNAB. Exclusion of an individual account or lists of individual accounts from processing by UNAB is not supported in the present version of UNAB, beyond the user_minimal_uid mechanism in uxauth.ini.

This will require customization of PAM configuration on your UNAB endpoints in such a way that pam_unix2 modules gets to process all logons first. 

Here is how the key piece in /etc/pam.d/common-auth will look like. 

auth required pam_env.so 
auth sufficient pam_unix2.so 
auth sufficient pam_uxauth.so 

That is a common system admin task (fine-tuning performance as per usage patterns), but a rather sensitive one, so I please keep a ssh open while performing operations and do not close it until you are completely sure your solution works. In case of doubt, please contact CA Support.

An alternative way of suppressing excessive messaging is to administer what ends up in log files on Unix, which may be preferred. The reason why that debug message and related others are seen in messages is because debug-level syslog message collection is likely enabled on this system.

Typically, debug messages are of interest for some specific situations, so if we want to get rid of all debug-level messages from the auth facility to which UNAB being a security/authentication subsystem submits them, the the rsyslogd configuration may be updated to exclude logging of auth.debug (debug-level) messages.