Very interesting! You're right, I used simple "ldapsearch -x" command on the client when browsing the LDAP database. With IPA 3.3 it returned a whole lot of info about hostgroups, but with IPA 4.1 - only a single string 'cn=ng,cn=compat,$SUFFIX'. That's why current script didn't work. Tomorrow at work I'll try your advice, and if there's no another problem between the chair and the keyboard, I'll definitely stick with FreeIPA 4.1! Отправлено от <a href="http://r.bluemailapp.com">Blue Mail</a> <head><head><style type="text/css"> pre.blue {white-space: pre-wrap; word-wrap:break-word; font-family: sans-serif; margin-top: 0px} div, p { -ms-word-break: break-all; word-break: break-all; word-break: break-word; -webkit-hyphens: auto; -moz-hyphens: auto; -ms-hyphens: auto;hyphens: auto;} a {color: #226EF9 ;}</style></head><body style="zoom: 100%; "><div class="gmail_quote" >На 23.10.2014, в 21:40, Alexander Bokovoy <<a href="mailto:abokovoy@redhat.com" target="_blank">abokovoy@redhat.com</a>> написал:п<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <pre class="blue">On Thu, 23 Oct 2014, Орхан Касумов wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> Alright then, thanks for info! Tomorrow is the deadline for my researches on FreeIPA. Then I have to start deploying a centralized management solution in our production environment. Please help me to make a final decision on which version of FreeIPA to choose - 3.3 or 4.1? I'd like to have all the benefits of the latest version, but all our production servers are FreeBSD. With all information sources at my disposal right now I tend to choose FreeIPA 3.3. The cause is that otherwise I can't use host groups with sudo commands - the cron script proposed at FreeBSD forums works with old way of storing host group information in the LDAP directory of FreeIPA. Is there any workaround for this? (P.S. Here's what I'm talking about: <blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">" The tricky part was getting sudo to work with host groups. FreeIPA keeps host groups in netgroups, and FreeBSD's support for netgroups is limited. One solution would have been to enable NIS services on the FreeIPA server so that we could use proper netgroups on FreeBSD clients. We didn't like that solution, so instead we wrote a script that pulls all netgroup data from FreeIPA and stores it in /etc/netgroup . We run the script every hour via cron . " The script looks for host groups in 'cn=hostgroups,cn=accounts,dc=<domain>', and="" that="" works="" with="" freeipa<br="">3.3. But in FreeIPA v4 host groups get in 'cn=ng,cn=compat,dc=<domain>'. so="" the="" script="" needs="" modification.="" but="" i<br="">don't know how to modify the script, simply changing the string passed to the ldapsearch command doesn't work.) </domain>'.></domain>',></blockquote></blockquote>I think you completely missed the way FreeIPA works. :) Host groups are always in cn=hostgroups,cn=accounts,$SUFFIX, no changes were done. What you see in cn=ng,cn=compat,$SUFFIX are net groups for compatibility with older applications which expect old LDAP schema. The tree in cn=compat,$SUFFIX is provided through schema compatibility plugin and was also provided this way for quite a long time. What I think you are stumbling upon is the fact that starting with FreeIPA 4.0 we are providing more fine-grained access control to the data in LDAP tree. For example: $ ipa permission-find --subtree=cn=hostgroups,cn=accounts,dc=ipacloud,dc=test --right=read --------------------- 2 permissions matched --------------------- Permission name: System: Read Hostgroup Membership Granted rights: read, compare, search Effective attributes: memb! er, memberhost, memberof, memberuser Default attributes: member, memberof, memberuser, memberhost Bind rule type: all Subtree: cn=hostgroups,cn=accounts,dc=ipacloud,dc=test Type: hostgroup Permission name: System: Read Hostgroups Granted rights: read, compare, search Effective attributes: businesscategory, cn, createtimestamp, description, entryusn, ipauniqueid, modifytimestamp, o, objectclass, ou, owner, seealso Default attributes: cn, businesscategory, objectclass, description, o, ipauniqueid, owner, ou, seealso Bind rule type: all Subtree: cn=hostgroups,cn=accounts,dc=ipacloud,dc=test Type: hostgroup ---------------------------- Number of entries returned 2 ---------------------------- As you can see, both permissions require bind rule type 'all' which means 'all authenticated users'. On contrast, in schema compat tree you'll get the whole tree anonymously $ ipa permission-find --target=cn=ng,cn=compat,dc=ipacloud,dc=test --right=read -------------------- 1 permission matched -------------------- Permission name: System: Read Netgroup Compat Tree Granted rights: read, compare, search Effective attributes: cn, createtimestamp, entryusn, membernisnetgroup, modifytimestamp, nisnetgrouptriple, objectclass Default attributes: objectclass, nisnetgrouptriple, membernisnetgroup, cn Bind rule type: anonymous Subtree: dc=ipacloud,dc=test Target DN: cn=ng,cn=compat,dc=ipacloud,dc=test ---------------------------- Number of entries returned 1 ---------------------------- This means that your script should work as before, only that it needs to authenticate before connecting. As you run it as root, you can use host keytab, try adding something like this: old_krb5_ccache=${KRB5_CCACHE} KRB5_CCACHE=/tmp/_hostgroups_access.ccache.$$ export KRB5_CCACHE kinit -k -t /etc/krb5.keytab host/`hostname` # perform actual search ldapsearch -Y GSSAPI ..... # end of script kdestroy KRB5_CCACHE=${old_krb5_ccache} export KRB5_CCACHE note that ldapsearch -Y GSSAPI will use Kerberos authentication when talking to IPA LDAP server and use host/`hostname` principal for that. This should be enough for allowing access to the host groups. </pre></blockquote></div></body></head>