Addendum for all the people using Google:

 

The correct REST API parameter is indeed “all”:true, once the correct permissions are given to the user doing the query the attributes are visible. The python-freeipa module can also get the attributes.

 

The answer is: Security stops you doing things you’re not allowed to do.

 

# Call to actual method

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

 

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


From: Alexander Bokovoy <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 iOS<https://aka.ms/o0ukef>
>________________________________
>From: Rob Crittenden <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>; 'FreeIPA users list'
>>><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>; 'FreeIPA users list'
>>><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>
>>>Cc: Aaron Hicks <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
>>>To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
>>
>> --
>> / Alexander Bokovoy
>>
>>
>> _______________________________________________
>> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>> To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
>>
>

--
/ Alexander Bokovoy