November 2017 - FreeIPA-users - Fedora mailing-lists

RHEL/CentOS 5 and IPA 4.5
by Sigbjorn Lie 08 Nov '17

08 Nov '17

Hi list, RHEL/CentOS 5.11 clients does not seem to work with IPA 4.5 unless I go from sssd-ipa to sssd-ldap. I would prefer to continue to use sssd-ipa to allow the existing HBAC rules to function. Is there a known workaround to get EL 5.11 clients to work with IPA 4.5 using sssd-ipa? Thanks. Regards, Siggi [root@ipaclient sssd]# kinit -kt /etc/krb5.keytab kinit(v5): Preauthentication failed while getting initial credentials ipaserver krb5kdc log file: /var/log/krb5kdc: Nov 06 15:51:55 ipaserver1.realm.net <http://ipaserver1.realm.net/> krb5kdc[10673](info): AS_REQ (12 etypes {18 17 16 23 1 3 2 11 10 15 12 13}) 192.168.137.46: NEEDED_PREAUTH: host/ipaclient.realm.net(a)REALM.NET <mailto:host/ipaclient.realm.net@REALM.NET> for krbtgt/REALM.NET(a)REALM.NET <mailto:krbtgt/REALM.NET@REALM.NET>, Additional pre-authentication required Nov 06 15:51:55 ipaserver1.realm.net <http://ipaserver1.realm.net/> krb5kdc[10673](info): Doing certauth authorize for [host/ipaclient.realm.net(a)REALM.NET <mailto:host/ipaclient.realm.net@REALM.NET>] Nov 06 15:51:55 ipaserver1.realm.net <http://ipaserver1.realm.net/> krb5kdc[10673](info): Got cert filter [(userCertificate;binary=xxxxxxx Nov 06 15:51:55 ipaserver1.realm.net <http://ipaserver1.realm.net/> krb5kdc[10673](info): No matching entry found Nov 06 15:51:55 ipaserver1.realm.net <http://ipaserver1.realm.net/> krb5kdc[10673](info): preauth (pkinit) verify failure: Certificate mismatch Nov 06 15:51:55 ipaserver1.realm.net <http://ipaserver1.realm.net/> krb5kdc[10673](info): AS_REQ (12 etypes {18 17 16 23 1 3 2 11 10 15 12 13}) 192.168.137.46: PREAUTH_FAILED: host/ipaclient.realm.net(a)REALM.NET <mailto:host/ipaclient.realm.net@REALM.NET> for krbtgt/REALM.NET(a)REALM.NET <mailto:krbtgt/REALM.NET@REALM.NET>, Certificate mismatch Nov 06 15:51:55 ipaserver1.realm.net <http://ipaserver1.realm.net/> krb5kdc[10673](info): closing down fd 10 client sssd log files: ==> sssd_nss.log <== (Mon Nov 6 16:18:23 2017) [sssd[nss]] [accept_fd_handler] (6): Client connected! (Mon Nov 6 16:18:23 2017) [sssd[nss]] [sss_cmd_get_version] (5): Received client version [1]. (Mon Nov 6 16:18:23 2017) [sssd[nss]] [sss_cmd_get_version] (5): Offered version [1]. (Mon Nov 6 16:18:23 2017) [sssd[nss]] [nss_cmd_getpwuid_search] (4): Requesting info for [693200437(a)realm.net <mailto:693200437@realm.net>] (Mon Nov 6 16:18:23 2017) [sssd[nss]] [sss_dp_send_acct_req_create] (4): Sending request for [realm.net <http://realm.net/>][4097][1][idnumber=693200437] ==> ldap_child.log <== (Mon Nov 6 16:18:24 2017) [[sssd[ldap_child[13376]]]] [ldap_child_get_tgt_sync] (4): Principal name is: [host/ipaclient.realm.net(a)REALM.NET <mailto:host/ipaclient.realm.net@REALM.NET>] (Mon Nov 6 16:18:24 2017) [[sssd[ldap_child[13376]]]] [ldap_child_get_tgt_sync] (0): Failed to init credentials: Certificate mismatch (Mon Nov 6 16:18:24 2017) [[sssd[ldap_child[13376]]]] [main] (1): ldap_child_get_tgt_sync failed. ==> sssd_realm.net.log <== (Mon Nov 6 16:18:24 2017) [sssd[be[realm.net <http://realm.net/>]]] [read_pipe_handler] (6): EOF received, client finished (Mon Nov 6 16:18:24 2017) [sssd[be[realm.net <http://realm.net/>]]] [sdap_get_tgt_recv] (6): Child responded: 14 [Certificate mismatch], expired on [0] (Mon Nov 6 16:18:24 2017) [sssd[be[realm.net <http://realm.net/>]]] [sdap_kinit_done] (4): Could not get TGT: 14 [Bad address] (Mon Nov 6 16:18:24 2017) [sssd[be[realm.net <http://realm.net/>]]] [sdap_cli_kinit_done] (6): Cannot get a TGT: ret [5] result [4] (Mon Nov 6 16:18:24 2017) [sssd[be[realm.net <http://realm.net/>]]] [fo_set_port_status] (4): Marking port 0 of server 'ipaserver1.realm.net <http://ipaserver1.realm.net/>' as 'not working' (Mon Nov 6 16:18:24 2017) [sssd[be[realm.net <http://realm.net/>]]] [fo_resolve_service_send] (4): Trying to resolve service 'IPA' (Mon Nov 6 16:18:24 2017) [sssd[be[realm.net <http://realm.net/>]]] [get_server_status] (7): Status of server 'ipaserver22.realm.net <http://ipaserver22.realm.net/>' is 'name resolved' (Mon Nov 6 16:18:24 2017) [sssd[be[realm.net <http://realm.net/>]]] [get_port_status] (7): Port status of port 389 for server ‘ipaserver2.realm.net <http://ipaserver2.realm.net/>' is 'not working' (Mon Nov 6 16:18:24 2017) [sssd[be[realm.net <http://realm.net/>]]] [get_server_status] (7): Status of server 'ipaserver1.realm.net <http://ipaserver1.realm.net/>' is 'name resolved' (Mon Nov 6 16:18:24 2017) [sssd[be[realm.net <http://realm.net/>]]] [get_port_status] (7): Port status of port 389 for server 'ipaserver1.realm.net <http://ipaserver1.realm.net/>' is 'not working' (Mon Nov 6 16:18:24 2017) [sssd[be[realm.net <http://realm.net/>]]] [get_server_status] (7): Status of server 'ipaserver21.realm.net <http://ipaserver21.realm.net/>' is 'name resolved' (Mon Nov 6 16:18:24 2017) [sssd[be[realm.net <http://realm.net/>]]] [get_port_status] (7): Port status of port 389 for server 'ipaserver21.realm.net <http://ipaserver21.realm.net/>' is 'not working' (Mon Nov 6 16:18:24 2017) [sssd[be[realm.net <http://realm.net/>]]] [get_server_status] (7): Status of server 'ipaserver1.realm.net <http://ipaserver1.realm.net/>' is 'name resolved' (Mon Nov 6 16:18:24 2017) [sssd[be[realm.net <http://realm.net/>]]] [get_port_status] (7): Port status of port 0 for server 'ipaserver1.realm.net <http://ipaserver1.realm.net/>' is 'not working' (Mon Nov 6 16:18:24 2017) [sssd[be[realm.net <http://realm.net/>]]] [fo_resolve_service_send] (1): No available servers for service 'IPA' (Mon Nov 6 16:18:24 2017) [sssd[be[realm.net <http://realm.net/>]]] [be_resolve_server_done] (7): Server resolution failed: 5 (Mon Nov 6 16:18:24 2017) [sssd[be[realm.net <http://realm.net/>]]] [sdap_id_op_connect_done] (1): Failed to connect, going offline (5 [Input/output error]) (Mon Nov 6 16:18:24 2017) [sssd[be[realm.net <http://realm.net/>]]] [be_run_offline_cb] (3): Going offline. Running callbacks. (Mon Nov 6 16:18:24 2017) [sssd[be[realm.net <http://realm.net/>]]] [acctinfo_callback] (4): Request processed. Returned 1,11,Offline (Mon Nov 6 16:18:24 2017) [sssd[be[realm.net <http://realm.net/>]]] [child_sig_handler] (7): Waiting for child [13376]. (Mon Nov 6 16:18:24 2017) [sssd[be[realm.net <http://realm.net/>]]] [child_sig_handler] (4): child [13376] finished successfully.

4 7

Find IPA user or computer account from windows
by Ronald Wimmer 08 Nov '17

08 Nov '17

Is it possible to find an IPA user or computer account from a windows (AD) machine [trust between ipa and ad domain is set up]? If I try that, all i get is a message that no object can be found. Regards, Ronald

2 2

master - replica relationship
by Lachlan Musicman 08 Nov '17

08 Nov '17

Hola, I'm still trying to wrap my head around the master-replica concept. From what I read in the documentation (Chapter 4 of https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/ht… ) the replica should be able to take over as master should master go offline. Our replica was set up with CA & without DNS - the same as master, and it seems to be working on the whole. The problem I'm having is in the replication. create user on master: ipa user-add master_test_user --first=MT --last=ML create user on replica: ipa user-add replica_test_user --first=RT --last=RL find user on master: [root@vmpr-linuxidm ~]# ipa user-find test_user --------------- 2 users matched --------------- User login: master_test_user First name: MT Last name: ML Home directory: /home/master_test_user Login shell: /bin/bash Principal name: master_test_user(a)UNIX.DOMAIN.COM Principal alias: master_test_user(a)UNIX.DOMAIN.COM Email address: master_test_user(a)domain.com UID: 1718800021 GID: 1718800021 Account disabled: False User login: replica_test_user First name: RT Last name: RL Home directory: /home/replica_test_user Login shell: /bin/bash Principal name: replica_test_user(a)UNIX.DOMAIN.COM Principal alias: replica_test_user(a)UNIX.DOMAIN.COM Email address: replica_test_user(a)domain.com UID: 1718850502 GID: 1718850502 Account disabled: False ---------------------------- Number of entries returned 2 ---------------------------- find user on replica: [root@vmdr-linuxidm ~]# ipa user-find test_user -------------- 1 user matched -------------- User login: replica_test_user First name: RT Last name: RL Home directory: /home/replica_test_user Login shell: /bin/bash Principal name: replica_test_user(a)UNIX.DOMAIN.COM Principal alias: replica_test_user(a)UNIX.DOMAIN.COM Email address: replica_test_user(a)domain.com UID: 1718850502 GID: 1718850502 Account disabled: False ---------------------------- Number of entries returned 1 ---------------------------- If I run ipa user-add on the replica, I see it upstream on master, but if I run ipa add-user on the master, that's not replicated down to the replica. Also, ipa user-del (even with --no-preserve) works on master, but doesn't delete the user on the replica. What has gone wrong? Cheers L. ------ "The antidote to apocalypticism is *apocalyptic civics*. Apocalyptic civics is the insistence that we cannot ignore the truth, nor should we panic about it. It is a shared consciousness that our institutions have failed and our ecosystem is collapsing, yet we are still here — and we are creative agents who can shape our destinies. Apocalyptic civics is the conviction that the only way out is through, and the only way through is together. " *Greg Bloom* @greggish https://twitter.com/greggish/status/873177525903609857

3 2

Using user-mod to set a hashed password
by Aaron Hicks 07 Nov '17

07 Nov '17

Hello the list, The next terrible bad thing our customer service model says we'd like to do with FreeIPA is set user passwords from our customer management system. It's not AD and it's not LDAP. It does have a store of salted hashed sha512 passwords. I have set the FreeIPA directory in migration mode as per http://www.freeipa.org/page/NIS_accounts_migration_preserving_Passwords We are able to add new users (with add-user) and set their password with --setattr userpassword={crypt}$6$reallylongsalteddsha512hashsoveryverylong The previous bit is working. The next bit is not. We have a bunch of users in the directory who were created before we enabled this feature in user creation, and another bunch who have not yet generated a password hash. These users have no password set in FreeIPA. Our script is capable of figuring out if an account hasPassword attribute is True or False. We'd like to set these user's passwords if they are not already set, but: ipa user-mod username --setattr userpassword={crypt}$6$reallylongsalteddsha512hashsoveryverylong ipa: ERROR: Constraint violation: Pre-Encoded passwords are not valid We get the same response when we kinit as admin or a user with the System: Change User password permission. Is there a specific configuration mode option or account attribute that allows this to work? Regards, Aaron Hicks

2 3

Re: Searching for user by extended attribute
by Aaron Hicks 06 Nov '17

06 Nov '17

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

2 1

Re: Searching for user by extended attribute
by Aaron Hicks 06 Nov '17

06 Nov '17

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

1 0

Re: Searching for user by extended attribute
by Alexander Bokovoy 06 Nov '17

06 Nov '17

On ma, 06 marras 2017, Aaron Hicks wrote: >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?” You can see that query with 'ipa -vvv user_find --all'. We keep repeating this multiple times, but that is really all you need to use to get the correct format. > >Get Outlook for iOS<https://aka.ms/o0ukef> >________________________________ >From: Alexander Bokovoy <abokovoy(a)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(a)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(a)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(a)redhat.com>; 'FreeIPA users list' >>>><freeipa-users(a)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(a)redhat.com>; 'FreeIPA users list' >>>><freeipa-users(a)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(a)lists.fedorahosted.org> >>>>Cc: Aaron Hicks <aaron.hicks(a)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(a)lists.fedorahosted.org >>>>To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org >>> >>> -- >>> / Alexander Bokovoy >>> >>> >>> _______________________________________________ >>> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org >>> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org >>> >> > >-- >/ Alexander Bokovoy -- / Alexander Bokovoy

1 0

Re: Searching for user by extended attribute
by Alexander Bokovoy 06 Nov '17

06 Nov '17

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(a)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(a)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(a)redhat.com>; 'FreeIPA users list' >>><freeipa-users(a)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(a)redhat.com>; 'FreeIPA users list' >>><freeipa-users(a)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(a)lists.fedorahosted.org> >>>Cc: Aaron Hicks <aaron.hicks(a)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(a)lists.fedorahosted.org >>>To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org >> >> -- >> / Alexander Bokovoy >> >> >> _______________________________________________ >> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org >> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org >> > -- / Alexander Bokovoy

2 1

Re: Searching for user by extended attribute
by Rob Crittenden 06 Nov '17

06 Nov '17

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(a)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(a)redhat.com>; 'FreeIPA users list' >><freeipa-users(a)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(a)redhat.com>; 'FreeIPA users list' >><freeipa-users(a)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(a)lists.fedorahosted.org> >>Cc: Aaron Hicks <aaron.hicks(a)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(a)lists.fedorahosted.org >>To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org > > -- > / Alexander Bokovoy > > > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org >

2 1

Searching for user by extended attribute
by Aaron Hicks 06 Nov '17

06 Nov '17

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. 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. Regards, Aaron Hicks

2 10

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users November 2017