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

Thu Mar 3 14:29:48 UTC 2011

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