[Freeipa-users] A crazy idea maybe, migration to Free-IPA 4.1.

[Alexander Bokovoy]

On Thu, 23 Oct 2014, Орхан Касумов wrote:
>
>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:
>>" 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
>>3.3. But in FreeIPA v4 host groups get in
>>'cn=ng,cn=compat,dc=<domain>'. So the script needs modification. But I
>>don't know how to modify the script, simply changing the string passed
>>to the ldapsearch command doesn't work.)
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: member, 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.

-- 
/ Alexander Bokovoy