[Freeipa-devel] [PATCH] 78 Use ldapi: instead of unsecured ldap: in ipa core tools.
Rob Crittenden
rcritten at redhat.com
Thu Mar 3 19:04:50 UTC 2011
Martin Kosek wrote:
> 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
Pushed to master
More information about the Freeipa-devel
mailing list