Bug 1972553

Equivalent command of the WebUI action is:
ipa user-find --uid=<uid>

# rpm -qa | grep ipa | sort
ipa-client-4.9.2-3.module+el8.4.0+10412+5ecb5b37.x86_64
ipa-client-common-4.9.2-3.module+el8.4.0+10412+5ecb5b37.noarch
ipa-common-4.9.2-3.module+el8.4.0+10412+5ecb5b37.noarch
ipa-healthcheck-0.7-3.module+el8.4.0+9007+5084bdd8.noarch
ipa-healthcheck-core-0.7-3.module+el8.4.0+9007+5084bdd8.noarch
ipa-selinux-4.9.2-3.module+el8.4.0+10412+5ecb5b37.noarch
ipa-server-4.9.2-3.module+el8.4.0+10412+5ecb5b37.x86_64
ipa-server-common-4.9.2-3.module+el8.4.0+10412+5ecb5b37.noarch
ipa-server-dns-4.9.2-3.module+el8.4.0+10412+5ecb5b37.noarch
ipa-server-trust-ad-4.9.2-3.module+el8.4.0+10412+5ecb5b37.x86_64
libipa_hbac-2.4.0-9.el8.x86_64
python3-iniparse-0.4-31.el8.noarch
python3-ipaclient-4.9.2-3.module+el8.4.0+10412+5ecb5b37.noarch
python3-ipalib-4.9.2-3.module+el8.4.0+10412+5ecb5b37.noarch
python3-ipaserver-4.9.2-3.module+el8.4.0+10412+5ecb5b37.noarch
python3-libipa_hbac-2.4.0-9.el8.x86_64
redhat-logos-ipa-84.4-1.el8.noarch
sssd-ipa-2.4.0-9.el8.x86_64

This is easily reproducible.

The UI only searches using the attributes defined in user search fields found under IPA Server -> Configuration. uidnumber is not included by default.

The search field in general represents a difference between the capabilities of the UI and CLI. The CLI provides a couple of dozen attributes to search against as options. The UI only does the equivalent of ipa user-find <term>.

Not all data types will work with the user search fields, notably numeric ones, because of the way the LDAP filter is generated. This means that adding uidnumber to the search fields will not fix this. The generated filter contains (uidnumber="*<integer value>*") which isn't meaningful in an LDAP query of an integer.

The full query that was generated when I added uidnumber to the user search fields is:

[16/Jun/2021:08:47:04.249281910 -0400] conn=129 op=2 SRCH base="cn=users,cn=accounts,dc=example,dc=test" scope=1 filter="(&(|(uid=*1743600001*)(givenName=*1743600001*)(sn=*1743600001*)(telephoneNumber=*1743600001*)(ou=*1743600001*)(title=*1743600001*)(uidNumber=*1743600001*))(objectClass=posixaccount))" attrs="ipaSshPubKey uid

One possible solution would be in the filter generator to check the syntax of the attribute and don't add wildcards if it is INTEGER (1.3.6.1.4.1.1466.115.121.1.27).

A more complex solution would be to create an Advanced Search in the UI to use the extended capabilities of the *-find commands.

Thanks @rcritten 

Another related issue is the inconsistency of the term "uid". UID can represent username or uidnumber interchangeably. 

WebUI:
"User Login" = uid
"UID" = uidNumber

Command line:
ipa user-find --uid=<uid>   ====>>>> This search uidNumber

This is causing unnecessary confusion.

I'm not sure what the question is here but the LDAP schema for organizing users is something we don't have control over because we need to interoperate with other systems.

IPA uses a mapping to try to present a more modern view of the information but there are places, such as the search fields, where the actual names bleed through.

The show-mappings CLI command can be used to translate between naming (IPA name on the left, LDAP attribute on the right):

$ ipa show-mappings user-find |grep uid
login                : uid?
uid                  : uidnumber?

The question mark means this attribute is optional with the user-find command.

This enhancement will be considered in the new WebUI only and the new ticket issue will be tracked here: https://github.com/freeipa/freeipa-webui/issues/106