Sometimes it may occur that the same user is defined in two different domains from which UNAB is retrieving usernames and credentials for authentication
For instance, let's take it that one has
These are two different users as they belong to two different domains, even if the username is actually the same
Certain organizations may be interested in logging in to UNAB with one or the other user and to load different UNIX environments depending on whether it is one or other user
However, UNIX/Linux does not distinguish between both domains as it only takes into account the username, and the way UNAB worked so far an error is obtained if trying to use both users. Assuming [email protected] is already used in UNAB, trying to log in as [email protected] results in the following;
sshd[1503103]: Invalid user [email protected] from <ip_address> port <connetion port>
sshd[1503103]: pam_unix(sshd:auth): check pass; user unknown
sshd[1503103]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost= <ip_address>
uxauthd[2999]: GSSAPI client step 1
uxauthd[2999]: GSSAPI client step 2
uxauthd[2999]: Failed to add record in table 'pw' (nssdb_add_cache_user). Native error: UNIQUE constraint failed: pw.name
CA PAM SC UNAB versions prior to unab-pkg-14.10.60.216
As mentioned earlier this is due to a constraint in the nss.db pw table which limits each entry by username.
While this is working as UNIX would expect, the need for the use case described (same user in different domains logging in into the same UNAB environment) has been taking into account as an improvement in later versions of UNAB
Please upgrade to unab-pkg-14.10.60.216 and add the following setting to uxauth.ini in the section where nss-related parameters are defined, if it does not exist:
nss_enforce_unique_name = yes
for the existing behaviour (i.e. no two users may exist with the same username even if they belong to different windows domains in UNAB)
nss_enforce_unique_name = no
For the full username + domain to be taken into account. In this second case, [email protected] and [email protected] will be registered to UNAB, each with its own unix attributes and it will be possible to log in as one or the other