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

[Simo Sorce]

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.

-- 
Simo Sorce * Red Hat, Inc * New York