Hello everyone,
Apologies for the terse emails earlier, I was on my ride into work.
We missed an important part of the exercise. Who we were using for kinit?
I'm getting different responses when querying as admin vs. querying as a User Administrator.
When I use user-find via the REST API as the admin I get the attributes.
When I use user-find via the REST API as a User Administrator I the attributes are missing.
Sooo. the question is now: how do I give the User Administrator role permission to read those attributes?
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.
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.
While I may seem grumpy, I did appreciate your help. It did help me find the solution.
Regards,
Aaron Hicks
From: Aaron Hicks [mailto:aaron.hicks@nesi.org.nz] Sent: Tuesday, 7 November 2017 9:03 AM To: Alexander Bokovoy abokovoy@redhat.com Cc: Rob Crittenden rcritten@redhat.com; FreeIPA users list freeipa-users@lists.fedorahosted.org Subject: Re: [Freeipa-users] Re: Searching for user by extended attribute
I am on a bus :) your suggestion are things I have already tried. I know the command line works.
My question is "what is the correct REST API query parameter that duplicates the -all command line parameter?"
Get Outlook for iOS https://aka.ms/o0ukef
_____
From: Alexander Bokovoy <abokovoy@redhat.com mailto:abokovoy@redhat.com > Sent: Tuesday, November 7, 2017 8:51:59 AM To: Aaron Hicks Cc: Rob Crittenden; FreeIPA users list Subject: Re: [Freeipa-users] Re: Searching for user by extended attribute
On ma, 06 marras 2017, Aaron Hicks wrote:
I am querying the REST API and it does not respond the same as the command line. So I know that command works and it gives the information I want. I need the REST API (which I'm querying via a python module using plain ordinary HTTP requests) to give the same information.
I'd like to know the correct REST query or figure if the REST API has a bug.
So, did you try to use exactly same JSON request as 'ipa -vvv user-find --all' shows?
From your terse responses it is unclear at what state you are since my morning's answers. You seem to ignore suggestions we made -- at least, you are not showing what's different for you.
Get Outlook for iOShttps://aka.ms/o0ukef ________________________________ From: Rob Crittenden <rcritten@redhat.com mailto:rcritten@redhat.com > Sent: Tuesday, November 7, 2017 8:31:31 AM To: FreeIPA users list; Alexander Bokovoy Cc: Aaron Hicks Subject: Re: [Freeipa-users] Re: Searching for user by extended attribute
Aaron Hicks via FreeIPA-users wrote:
Sorry, this does not address that the REST API is giving a different response than the command line or built in Python API.
This behaviour is unexpected and not described in the documentation.
What difference is that? I ran your command and user-find and got identical output.
rob
Get Outlook for iOS https://aka.ms/o0ukef
*From:* Alexander Bokovoy <abokovoy@redhat.com
*Sent:* Monday, November 6, 2017 8:14:29 PM *To:* FreeIPA users list *Cc:* Aaron Hicks *Subject:* Re: [Freeipa-users] Re: Searching for user by extended
attribute
On ma, 06 marras 2017, Aaron Hicks via FreeIPA-users wrote:
Hi everyon,
This seems to be a flaw in the FreeIPA API itself.
Using curl and the session method Alexander wrote up here: https://vda.li/en/posts/2015/05/28/talking-to-freeipa-api-with-sessions/
There is no combination of the 'all':somevalue that seem to trigger a
proper
all response. This is either broken or improperly documented. I've tried 'all':True 'all':1 all:'True'
This is the curl request I'm making at the end:
curl -v \ -H referer:https://$IPAHOSTNAME/ipa \ -H "Content-Type:application/json" \ -H "Accept:applicaton/json" \ -c $COOKIEJAR -b $COOKIEJAR \ --cacert /etc/ipa/ca.crt \ -d '{"method":"user_find","params":[[""],{"all":"true"}],"id":0}' \ -X POST https://$IPAHOSTNAME/ipa/session/json
See my other answer.
I think what you are confused about as well is the fact that 'user_find' is not the command that returns _everything_ from the user entries it finds. Instead, it returns a curated list of attributes -- there are two lists, actually, -- one for a normal (without --all) and one for extended operation. The reason for that is because in all '<object>-find' calls we don't want to resolve potential membership information for an object to be returned. The list of members/membership would be too involving in case of a large database which would slow down find operations a lot. As result, we tuned find operation to provide a smaller subset (still, --all produces a bit larger one too). If you need all attributes, use '<object>-show' instead, once you found the name for an object.
-----Original Message----- From: Aaron Hicks [mailto:aaron.hicks@nesi.org.nz] Sent: Monday, 6 November 2017 3:20 PM To: 'Alexander Bokovoy' <abokovoy@redhat.com mailto:abokovoy@redhat.com
; 'FreeIPA users list'
<freeipa-users@lists.fedorahosted.org
mailto:freeipa-users@lists.fedorahosted.org >
Subject: RE: [Freeipa-users] Searching for user by extended attribute
Ah, another point of difference is that I'm using this module to
communicate
with the API https://github.com/opennode/python-freeipa
I've not found any documentation for using any Python modules provided by FreeAPI itself in standalone python scripts, rather than via the ipa console...
-----Original Message----- From: Aaron Hicks [mailto:aaron.hicks@nesi.org.nz] Sent: Monday, 6 November 2017 10:20 AM To: 'Alexander Bokovoy' <abokovoy@redhat.com mailto:abokovoy@redhat.com
; 'FreeIPA users list'
<freeipa-users@lists.fedorahosted.org
mailto:freeipa-users@lists.fedorahosted.org >
Subject: RE: [Freeipa-users] Searching for user by extended attribute
Ugh, on further testing; the ipa python console is giving different responses that the code I'm using in a python script.
In the ipa console, the additional attributes are listed.
In the script I'm setting up a python-freeipa.Client object (called client)and passing the following call:
client.user_find(all=True)
and the user records that are returned are still only the 'default' attributes, even though the attributes are set and have values.
This is the code I'm testing, it's loading all the variables from a configuration file provided by the config object.
# First two lines import the project's configuration and logging objects from this.configuration import config, args from this.log import
base_logger
from python_freeipa import Client
logger = base_logger.getChild(__name__)
if config['freeipa'].getboolean('enabled') is True: if config['freeipa'].getboolean('verify_ssl') is not True: logger.warning( 'Verifying TLS connection to %s disabled.' % config['freeipa']['server'] ) logger.info('freeIPA startup') client = Client( config['freeipa']['server'], version=config['freeipa']['version'], verify_ssl=config['freeipa'].getboolean('verify_ssl') ) client.login( config['freeipa']['user'], config['freeipa']['password'] ) else: logger.info('freeIPA disabled')
def ipa_query(*dargs, **kwargs): if config['freeipa'].getboolean('enabled') is True: return client.user_find(*dargs, **kwargs) else: logger.info('freeIPA disabled') return None
ipa_query(all=True)
Regards,
Aaron
-----Original Message----- From: Alexander Bokovoy [mailto:abokovoy@redhat.com] Sent: Friday, 3 November 2017 7:10 PM To: FreeIPA users list <freeipa-users@lists.fedorahosted.org
mailto:freeipa-users@lists.fedorahosted.org >
Cc: Aaron Hicks <aaron.hicks@nesi.org.nz mailto:aaron.hicks@nesi.org.nz
Subject: Re: [Freeipa-users] Searching for user by extended attribute
On pe, 03 marras 2017, Aaron Hicks via FreeIPA-users wrote:
Hi all,
We've added two objectclasses to the default user in our FreeIPA
instance.
We're able to set and modify them fine, however we need two additional functions.
We need two additional attributes auedupersonsharedtoken and edupersonprinciplename to be included in the user attributes when executing user-find with the python-freeipa module. It works fine from the command line by adding the --all argument, but there's no equivalent to --all the python-freeipa module.
It is all there.
$ ipa console (Custom IPA interactive Python console)
len(api.Command.user_find()['result'][0])
11
len(api.Command.user_find(all=True)['result'][0])
24
We need to be able to user-find to search for users by these attributes, both from the command line and the python-freeipa module. There does not seem to be an equivalent of the --setattr command on the find function to search by attributes provided by additional objectclass
schema. This is a bit different. You need to make sure you injected those
attributes
into existing object definitions if you want to see them used by the baseldap.py machinery.
Can you show a code you use to extend IPA classes?
-- / Alexander Bokovoy
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
mailto:freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to
freeipa-users-leave@lists.fedorahosted.org mailto:freeipa-users-leave@lists.fedorahosted.org
-- / Alexander Bokovoy
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
mailto:freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to
freeipa-users-leave@lists.fedorahosted.org mailto:freeipa-users-leave@lists.fedorahosted.org
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.
freeipa-users@lists.fedorahosted.org
-
Aaron Hicks -
Alexander Bokovoy