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.
--
/ Alexander Bokovoy