Centrify 5.X is case sensitive when looking up by unixname, but not by samAccountName.
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.