I'm using the python-freeipa module, but I made further tests using the curl method here: https://vda.li/en/posts/2015/05/28/talking-to-freeipa-api-with-sessions/
Whatever I do to try and set the all parameter to true (e.g. 'all':True 'all':1 all:'True' 'all':'true' ) the JSON returned is exactly the same and does not include the additional user attributes I get from the all option from the command line or the all=True option using the ipa console.
I'm trying to check the haspassword attribute and some additional attributes from objectclasses that I added to the user object.
haspassword
I've already gone through this on the FreeIPA mailing list: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/FWXAXWOKMS2JJDPQAT5RQZBKZRA6TUSM/
The script I'm using is:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39
#!/bin/sh export COOKIEJAR=/tmp/ipa-$$ export IPAHOSTNAME=my.ipa.fqdn if [ $# -ne 1 ]; then echo -e "Please enter krb or pass as argument." && exit 1 fi # User authentication if there is no cookie. if [ ! -f $COOKIEJAR ] ; then if [ $1 = "krb" ] ; then export KRB5_CONFIG=/etc/krb5-ipa.conf kinit admin curl -v \ -H referer:https://$IPAHOSTNAME/ipa \ -c $COOKIEJAR -b $COOKIEJAR \ --cacert /etc/ipa/ca.crt \ --negotiate -u : \ -X POST https://$IPAHOSTNAME/ipa/session/login_kerberos else read -p "Please enter user name: " username read -s -p "Please enter password: " password curl -v \ -H referer:https://$IPAHOSTNAME/ipa \ -H "Content-Type:application/ x-www-form-urlencoded" \ -H "Accept:text/plain"\ -c $COOKIEJAR -b $COOKIEJAR \ --cacert /etc/ipa/ca.crt \ --data "user=$username&password=$password" \ -X POST https://$IPAHOSTNAME/ipa/session/login_password fi fi # 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
I kinit to an appropriate user and use the krb option.
When I use the ipa console I get a correct response:
ipa console
(Custom IPA interactive Python console) >>> len(api.Command.user_find(all=True)['result'][0]) 20 >>> len(api.Command.user_find()['result'][0]) 12 >>>
This might not be a bug, it might just be that the API documentation gives no examples of usage. Just commands and parameters.
This is not a bug but rather a wrong usage.
You can use ipa -vvv <command> to see what JSON request is sent and what are the arguments there. There you'd see that ipa -vvv user_find --all would send a JSON with "all": true, not something else.
ipa -vvv <command>
ipa -vvv user_find --all
"all": true
As I responded on the freeipa-users@ mailing list, also user_find is a wrong command to retrieve haspassword. user_find is designed to return a subset of information that does not require additional computation on the server side: most notably, membership information is omitted, and password details discovery is omitted as well. So you are looking for details that would never be provided by user_find.
user_find
Your example used the command line. I am querying the usage of the REST API.
The REST API is responding to the equivalent request in an unexpected manner. This is a bug or a deficiency in the documentation of the REST API. If I’m doing it wrong please give an example of getting an —all query from the REST API using curl.
If the REST API gave the same output as the command line then it would suit my planned usage.
Found it, the issue was the query with the admin user gives a different response than with a user with the User Administrator role. A add the attributes to the System: Read User Kerberos Login Attributes permission and they're visible.
The correct parameter for the REST API is 'all':true using the JSON boolean type.
Closing as the issue was a user error.
Metadata Update from @frenaud: - Issue close_status updated to: invalid - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.