On 2/25/11 5:58 AM, "Pavel Zuna" <[email protected]> wrote:
>On 02/23/2011 11:53 PM, Simo Sorce wrote: >> 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. >> > >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@auth2 ~]# ipa-compat-manage status File "/usr/sbin/ipa-compat-manage", line 169 <<<<<<< HEAD [root@auth2 ~]# ipa-host-net-manage status File "/usr/sbin/ipa-host-net-manage", line 195 <<<<<<< HEAD ^ _______________________________________________ Freeipa-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-devel
