On 2011-02-25 18:12, JR Aquino wrote:
On 2/25/11 5:58 AM, "Pavel Zuna"<pz...@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<pz...@redhat.com> wrote:On 2011-02-15 16:36, JR Aquino wrote:On 2/15/11 6:52 AM, "Simo Sorce"<sso...@redhat.com> wrote:On Tue, 15 Feb 2011 15:19:50 +0100 Pavel Zuna<pz...@redhat.com> 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 Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-develThe 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 startI 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 ^
That's cool, I just wonder how it got there. :) Fixed version attached. Pavel
freeipa-pzuna-78-5-toolsldapi.patch
Description: application/mbox
_______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel