FreeIPA plugin: not recognizing usernames greater than 11 characters

[dsajdak]

When running the freeipa plugin to sync groups, a username that has 12 or more characters in it is erroring out.

ipa: WARNING: User dsajdaktest should be added to freeipa group: academic
dsajdaktest academic Enabled Active
ipa: WARNING: User jbednasztest not found in FreeIPA

However, using the freeipa command (ipa group-add-member) to add the user to the group works.

I would say this is a high priority to fix as it's easy to miss this error if running in a cron.

Test Tasks:

1. Add a new user to FreeIPA with a username of 12 characters or more
2. Add user to an allocation that has the freeipa_group attribute
3. Run the freeipa sync for that user to see if the account is added to the group:
   coldfront freeipa_check -x -s -u username

[aebruno]

It appears this might be an issue with sssd infopipe GetUserAttr. We call this function to retrieve the nsaccountlock attribute to check whether the user is enabled/disabled. We're seeing random inconsistent results returned from this function. Steps to reproduce:

1. Run LDAP query for nsaccountlock attribute and verify user and attribute exist:

$ ldapsearch -Y GSSAPI uid=testuser nsaccountlock
# testuser, users, accounts, domain.edu
dn: uid=testuser,cn=users,cn=accounts,dc=domain,dc=edu
nsaccountlock: FALSE

2. Run dbus sssd.infopipe query for nsaccountlock fails with:

$ dbus-send --print-reply --system --dest=org.freedesktop.sssd.infopipe /org/freedesktop/sssd/infopipe org.freedesktop.sssd.infopipe.GetUserAttr string:"testuser" array:string:nsaccountlock
Error sbus.Error.NotFound: No such file or directory

3. Run this several times and will randomly fail or return empty array:

$ dbus-send --print-reply --system --dest=org.freedesktop.sssd.infopipe /org/freedesktop/sssd/infopipe org.freedesktop.sssd.infopipe.GetUserAttr string:"testuser" array:string:nsaccountlock
method return time=1659665196.841737 sender=:1.13 -> destination=:1.108 serial=175 reply_serial=2
   array [
   ]

$ dbus-send --print-reply --system --dest=org.freedesktop.sssd.infopipe /org/freedesktop/sssd/infopipe org.freedesktop.sssd.infopipe.GetUserAttr string:"testuser" array:string:nsaccountlock
Error sbus.Error.NotFound: No such file or directory

The rationale for using sssd.infopipe is because it's much faster than querying for this attribute via the FreeIPA api, especially when processing a large set of user accounts. However, given the inconsistent behavior of sssd.infopipe let's switch to using an LDAP query to lookup nsaccountlock. PR forthcoming.

TODO: revisit this in the future to see if sssd.infopipe can provide more reliable results. Given that this used to work for quite some time, it could be related to our recent switch from CentOS 7 to Ubuntu 20.04? More investigation is needed.