[Freeipa-devel] [PATCH] 78 Use ldapi: instead of unsecured ldap: in ipa core tools.

Thu Mar 3 16:43:45 UTC 2011

On Thu, 2011-03-03 at 15:29 +0100, Martin Kosek wrote:
> On Mon, 2011-02-28 at 18:15 +0000, JR Aquino wrote:
> > 
> > On 2/25/11 9:27 AM, "Pavel Zůna" <pzuna at redhat.com> wrote:
> > 
> > >On 2011-02-25 18:12, JR Aquino wrote:
> > >>
> > >>
> > >> On 2/25/11 5:58 AM, "Pavel Zuna"<pzuna at redhat.com>  wrote:
> > >>
> > >>> On 02/23/2011 11:53 PM, Simo Sorce wrote:
> > >>>> On Wed, 23 Feb 2011 23:41:33 +0100
> > >>>> Pavel Zůna<pzuna at redhat.com>   wrote:
> > >>>>
> > >>>>> On 2011-02-15 16:36, JR Aquino wrote:
> > >>>>>> On 2/15/11 6:52 AM, "Simo Sorce"<ssorce at redhat.com>    wrote:
> > >>>>>>
> > >>>>>>> On Tue, 15 Feb 2011 15:19:50 +0100
> > >>>>>>> Pavel Zuna<pzuna at redhat.com>    wrote:
> > >>>>>>>
> > >>>>>>>> I can't reproduce this. :-/
> > >>>>>>>>
> > >>>>>>>> For me it goes fine:
> > >>>>>>>>
> > >>>>>>>> [root at ipadev tools]# ./ipa-nis-manage enable
> > >>>>>>>> Directory Manager password:
> > >>>>>>>>
> > >>>>>>>> Enabling plugin
> > >>>>>>>> This setting will not take effect until you restart Directory
> > >>>>>>>> Server. The rpcbind service may need to be started.
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>> Pavel,
> > >>>>>>> Jr has set the minimum ssf to a non default value to test a
> > >>>>>>> configuration in which all communications are required to be
> > >>>>>>> encrypted. That's why you can't reproduce with the vanilla
> > >>>>>>> configuration.
> > >>>>>>>
> > >>>>>>> We want to support that mode although it won't be the default, so
> > >>>>>>> we need to fix any issue that causes that configuration to break
> > >>>>>>> (ie all non-encrypted/non-ldapi connections).
> > >>>>>>>
> > >>>>>>> Simo.
> > >>>>>>>
> > >>>>>>> --
> > >>>>>>> Simo Sorce * Red Hat, Inc * New York
> > >>>>>>>
> > >>>>>>> _______________________________________________
> > >>>>>>> Freeipa-devel mailing list
> > >>>>>>> Freeipa-devel at redhat.com
> > >>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel
> > >>>>>>
> > >>>>>> The best way to do this is:
> > >>>>>>
> > >>>>>> -=-
> > >>>>>> service ipa stop
> > >>>>>> Edit /etc/dirsrv/slapd-DOMAIN/dse.ldif
> > >>>>>>
> > >>>>>> Change:
> > >>>>>> nsslapd-minssf: 0
> > >>>>>>
> > >>>>>> To:
> > >>>>>> nsslapd-minssf: 56<- 56 is chosen because SASL communicates a 56bit
> > >>>>>> handshake even though we utilize a much strong cipher... (It is a
> > >>>>>> known bug/feature)
> > >>>>>>
> > >>>>>> service ipa start
> > >>>>>>
> > >>>>>
> > >>>>> I tried to use the LDAPUpdate class (ipaserver/install/ldapupdate.py)
> > >>>>> with ldapi=True, but it raises a NotFound exception when trying to
> > >>>>> call IPAdmin.do_external_bind() (ipaserver/ipaldap.py). This
> > >>>>> exception originates in IPAdmin.__lateinit() when trying to retrieve
> > >>>>> this
> > >>>>>
> > >>>>> cn=config,cn=ldbm database,cn=plugins,cn=config
> > >>>>>
> > >>>>> For some reason it looks like this entry is inaccessible when doing a
> > >>>>> SASL EXTERNAL bind as root.
> > >>>>>
> > >>>>> I can retrieve the entry as "cn=directory manager":
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> [root at vm-090 freeipa]# ldapsearch -D "cn=directory manager" -W -H
> > >>>>> ldapi://%2fvar%2frun%2fslapd-IDM-LAB-BOS-REDHAT-COM.socket -b
> > >>>>> "cn=config,cn=ldbm database,cn=plugins,cn=config" -s one
> > >>>>> Enter LDAP Password:
> > >>>>> # extended LDIF
> > >>>>> #
> > >>>>> # LDAPv3
> > >>>>> # base<cn=config,cn=ldbm database,cn=plugins,cn=config>   with scope
> > >>>>> oneLevel # filter: (objectclass=*)
> > >>>>> # requesting: ALL
> > >>>>> #
> > >>>>>
> > >>>>> # default indexes, config, ldbm database, plugins, config
> > >>>>> dn: cn=default indexes,cn=config,cn=ldbm
> > >>>>>database,cn=plugins,cn=config
> > >>>>> objectClass: top
> > >>>>> objectClass: extensibleObject
> > >>>>> cn: default indexes
> > >>>>>
> > >>>>> # search result
> > >>>>> search: 2
> > >>>>> result: 0 Success
> > >>>>>
> > >>>>> # numResponses: 2
> > >>>>> # numEntries: 1
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> but not as root:
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> [root at vm-090 freeipa]# ldapsearch -Y EXTERNAL -H
> > >>>>> ldapi://%2fvar%2frun%2fslapd-IDM-LAB-BOS-REDHAT-COM.socket -b
> > >>>>> "cn=config" SASL/EXTERNAL authentication started
> > >>>>> SASL username:
> > >>>>>gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
> > >>>>> SASL SSF: 0
> > >>>>> # extended LDIF
> > >>>>> #
> > >>>>> # LDAPv3
> > >>>>> # base<cn=config>   with scope subtree
> > >>>>> # filter: (objectclass=*)
> > >>>>> # requesting: ALL
> > >>>>> #
> > >>>>>
> > >>>>> # SNMP, config
> > >>>>> dn: cn=SNMP,cn=config
> > >>>>> objectClass: top
> > >>>>> objectClass: nsSNMP
> > >>>>> cn: SNMP
> > >>>>> nsSNMPEnabled: on
> > >>>>>
> > >>>>> # 2.16.840.1.113730.3.4.9, features, config
> > >>>>> dn: oid=2.16.840.1.113730.3.4.9,cn=features,cn=config
> > >>>>> objectClass: top
> > >>>>> objectClass: directoryServerFeature
> > >>>>> oid: 2.16.840.1.113730.3.4.9
> > >>>>> cn: VLV Request Control
> > >>>>>
> > >>>>> # search result
> > >>>>> search: 2
> > >>>>> result: 0 Success
> > >>>>>
> > >>>>> # numResponses: 3
> > >>>>> # numEntries: 2
> > >>>>>
> > >>>>>
> > >>>>> I'm not sure what the problem is, I tried setting different SASL
> > >>>>> security properties, but nothing helped. :( Next step is to analyze
> > >>>>> DS logs, but before I do that, I wanted to ask if anyone has any tips
> > >>>>> on what the solution might be.
> > >>>>
> > >>>> We have very strict ACIs when using EXTERNAL SASL as root.
> > >>>> Is there any reason you need to operate as root ?
> > >>>> you can also authenticate with SIMPLE (Dir MGr credentials), or
> > >>>> SASL/GSSAPI if you ahve credentials.
> > >>>>
> > >>>> If you need to run unattended as root then we may need to make
> > >>>> root+SASL/EXTERNAL more powerful but I'd like to understand exactly
> > >>>>why
> > >>>> you need that and can't use regular authentication with DirMgr or
> > >>>> GSSAPI credentials.
> > >>>>
> > >>>> Simo.
> > >>>>
> > >>>
> > >>> Thanks for advice! New version of the patch attached.
> > >>
> > >> Sorry Pavel, I Have to NACK again:
> > >> It looks like some comment info got left in the patch perhaps.
> > >>
> > >>
> > >> [root at auth2 ~]# ipa-compat-manage status
> > >>    File "/usr/sbin/ipa-compat-manage", line 169
> > >>      <<<<<<<  HEAD
> > >>
> > >>
> > >> [root at auth2 ~]# ipa-host-net-manage status
> > >>    File "/usr/sbin/ipa-host-net-manage", line 195
> > >>      <<<<<<<  HEAD
> > >>      ^
> > >>
> > >>
> > >>
> > >
> > >That's cool, I just wonder how it got there. :)
> > >
> > >Fixed version attached.
> > >
> > >Pavel
> > 
> > I've verified the following:
> >  install/migration/migration.py
> >  install/tools/ipa-compat-manage
> >  install/tools/ipa-compliance
> >  install/tools/ipa-host-net-manage
> >  install/tools/ipa-nis-manage
> >  install/tools/ipa-replica-prepare
> >  install/tools/ipa-server-install
> >  ipaserver/install/ldapupdate.py
> > 
> > 
> > ACK for everything except:  install/tools/ipa-server-certinstall
> > 
> > I'm not sure how best to test that particular tool.
> > 
> > The rest were verified by setting:nsslapd-minssf: 56
> > Then testing each tool to verify functionality without an ssf error.
> > 
> > ldapupdate.py was tested via running several different xml_rpc plugin
> > tests that indirectly utilize ldapupdate.py: test_hbac_plugin.py,
> > test_sudorule_plugin.py 
> > 
> > 
> 
> I tested NIS with Pavel's patch, it worked OK for me.
> 
> But have anybody tested replicas with the Pavel's patch? In my
> environment the replica server wasn't replicating when I prepared the
> with modified ipa-replica-prepare:
> 
> $ sudo ipa-replica-install replica-info-vm-139.idm.lab.bos.redhat.com.gpg     <-- produced by Pavel's ipa-replica-prepare
> ...
> $ ipa user-find
> --------------
> 1 user matched
> --------------
>   User login: admin
>   Last name: Administrator
>   Home directory: /home/admin
>   Login shell: /bin/bash
>   Account disabled: False
>   Member of groups: admins
> ----------------------------
> Number of entries returned 1
> ----------------------------
> 
> $ sudo ipa-server-install --uninstall --unattended
> $ sudo ipa-replica-install replica-info-vm-139.idm.lab.bos.redhat.com.gpg.2     <-- produced by clean version
> ...
> $ ipa user-find
> ---------------
> 2 users matched
> ---------------
>   User login: admin
>   Last name: Administrator
>   Home directory: /home/admin
>   Login shell: /bin/bash
>   Account disabled: False
>   Member of groups: admins
> 
>   User login: ab
>   First name: a
>   Last name: b
>   Home directory: /home/ab
>   Login shell: /bin/sh
>   Account disabled: False
>   Member of groups: ipausers
> ----------------------------
> Number of entries returned 2
> ----------------------------
> 
> User "ab" which was present on the master server (I called
> ipa-replica-prepare on the master server) was replicated to the replica
> server only when the replica information file (*.gpg) was created with
> clean IPA server.
> 
> Martin

The above described problem was probably in a test environment. I tested
the patch on a clean VMs and replication was working just fine.

I did not run into any further errors during my NIS/Replica testing, I
think this patch is OK.

Martin