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.

Get Outlook for iOS<>
From: Alexander Bokovoy <>
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:
>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" \
>     --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 []
>Sent: Monday, 6 November 2017 3:20 PM
>To: 'Alexander Bokovoy' <>; 'FreeIPA users list'
>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
>I've not found any documentation for using any Python modules provided by
>FreeAPI itself in standalone python scripts, rather than via the ipa
>-----Original Message-----
>From: Aaron Hicks []
>Sent: Monday, 6 November 2017 10:20 AM
>To: 'Alexander Bokovoy' <>; 'FreeIPA users list'
>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:
>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']
>        )
>'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']
>    )
>'freeIPA disabled')
>def ipa_query(*dargs, **kwargs):
>    if config['freeipa'].getboolean('enabled') is True:
>        return client.user_find(*dargs, **kwargs)
>    else:
>'freeIPA disabled')
>        return None
>-----Original Message-----
>From: Alexander Bokovoy []
>Sent: Friday, 3 November 2017 7:10 PM
>To: FreeIPA users list <>
>Cc: Aaron Hicks <>
>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
>>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])
>>>> len(api.Command.user_find(all=True)['result'][0])
>>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
>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
> machinery.
>Can you show a code you use to extend IPA classes?
>/ Alexander Bokovoy
>FreeIPA-users mailing list --
>To unsubscribe send an email to

/ Alexander Bokovoy
FreeIPA-users mailing list --
To unsubscribe send an email to

Reply via email to