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

[Orkhan Gasimov]

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!

Отправлено от Blue Mail



На 21:40, 23.10.2014, в 21:40, Alexander Bokovoy <abokovoy at redhat.com> написал:п>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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141023/0a294628/attachment.htm>