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

[JR Aquino]

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
    ^