Applies to:

Versions of Centrify DirectControl 5.x or higher

Problem:

Centrify 5.x is case sensitive when performing adquery lookup by unixname, but not by samAccountName.
 
When the AD user unixname is unique (i.e. not equivalent to the canonicalName, userPrincipalName, or samAccountName) the command

$ adquery user -A <unixname>
where <unixname> includes uppercase letters, fails with the message:
Error: No such user <unixName>
 
For example:
 
[root@engcen6 ssh]# adquery user -A wade-test
unixname:wade-test
samAccountName:wade
userPrincipalName:wade@centrifyimage.vms
canonicalName:centrifyimage.vms/Staff/Security/Wade Test
 
This is successful because the argument on the command line "wade-test" is the same as the unixname string "wade-test"

The same command using mixed case / Upper Case letters in the unixname will fail.
[root@engcen6 ssh]# adquery user -A wade-TEST
Error: No such user wade-TEST
 
This same adquery (with Upper Case letters) worked prior to Centrify 5.x
 
Doing a lookup by samAccountName will be successful even with a mixed case username value.

For example, the following lookup by samAccountName is successful
 
[root@engcen6 ssh]# adquery user -A WaDE
unixname:wade-test
samAccountName:wade
userPrincipalName:wade@centrifyimage.vms
canonicalName:centrifyimage.vms/Staff/Security/Wade Test


Cause:

There was major logic restructuring in version 5.x to support hierarchical zone.  Because of the new inheritance requirement, where user unixname can be overridden in the hierarchy, there is an additional check on user unixname. Technically, in the unix world, user Joe, joe, and JOE are 3 different people.  With the tighter unixname lookup, they are now treated as different people.


Workaround:

None.  This is working as designed.