On Wed, 23 Feb 2011 23:41:33 +0100 Pavel Zůna <[email protected]> wrote:
> On 2011-02-15 16:36, JR Aquino wrote: > > On 2/15/11 6:52 AM, "Simo Sorce"<[email protected]> wrote: > > > >> On Tue, 15 Feb 2011 15:19:50 +0100 > >> Pavel Zuna<[email protected]> wrote: > >> > >>> I can't reproduce this. :-/ > >>> > >>> For me it goes fine: > >>> > >>> [root@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 > >> [email protected] > >> 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@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@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 _______________________________________________ Freeipa-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-devel
