On ti, 07 marras 2017, Aaron Hicks wrote:
The massive checklist at https://my.ipa.fqdn/ipa/ui/#/e/permission/details/System%3A%20Read%20User%20 Kerberos%20Login%20Attributes
Tick them, save, and they're now visible.
has_password is defined with following mapping:
password_attributes = [('userpassword', 'has_password'), ('krbprincipalkey', 'has_keytab')]
This means if user account has userpassword attribute, we set has_password flag in the response. If there is a krbprincipalkey -- we set has_keytab flag.
We have this access control in freeIPA by default:
# This is used for the host/service one-time passwordn and keytab indirectors. # We can do a query on a DN to see if an attribute exists. dn: cn=accounts,$SUFFIX changetype: modify add: aci aci: (targetattr="userPassword || krbPrincipalKey")(version 3.0; acl "Search existence of password and kerberos keys"; allow(search) userdn = "ldap:///all";)
E.g. all authenticated users are allowed to check whether these two attributes exist in the searched entry (but cannot read the content of them). But because it is a search ACI, they need to be specified explicitly. This is done by the framework automatically in user_add, user_show, and user_mod but not in user_find.
When you are admin, you are able to see almost everything. That's why you see the attributes for passwords and is able to see has_password flag.
As I said, password detection in user_find is considered to be a bit more resource consuming operation than others (a separate request is done to discover existence of password attributes explicitly).
We're tying to compare user information between our customer management system and the directory. So we need to compare these attributes to see if a user account needs to be updated. I'm using user_find rather than user_show as user_find gives all the users as a big JSON object I can iterate over in memory and a single REST API request, rather than a many (2000+) individual rest queries. The single request takes less time that thousands of individual requests, so a no-op run takes about 5 seconds, a run that has to make a request for each user takes about 10 minutes.
Got it. Well, you just need to realize you are opening a bit wider hole with this permission change. If you are OK with that, that's fine.