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

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project

Reply via email to