[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



Martin Kosek wrote:
On Thu, 2011-03-03 at 15:29 +0100, Martin Kosek wrote:
On Mon, 2011-02-28 at 18:15 +0000, JR Aquino wrote:

On 2/25/11 9:27 AM, "Pavel Zůna"<pzuna redhat com>  wrote:

On 2011-02-25 18:12, JR Aquino wrote:


On 2/25/11 5:58 AM, "Pavel Zuna"<pzuna 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 redhat com>    wrote:

On 2011-02-15 16:36, JR Aquino wrote:
On 2/15/11 6:52 AM, "Simo Sorce"<ssorce redhat com>     wrote:

On Tue, 15 Feb 2011 15:19:50 +0100
Pavel Zuna<pzuna 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-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
      ^




That's cool, I just wonder how it got there. :)

Fixed version attached.

Pavel

I've verified the following:
  install/migration/migration.py
  install/tools/ipa-compat-manage
  install/tools/ipa-compliance
  install/tools/ipa-host-net-manage
  install/tools/ipa-nis-manage
  install/tools/ipa-replica-prepare
  install/tools/ipa-server-install
  ipaserver/install/ldapupdate.py


ACK for everything except:  install/tools/ipa-server-certinstall

I'm not sure how best to test that particular tool.

The rest were verified by setting:nsslapd-minssf: 56
Then testing each tool to verify functionality without an ssf error.

ldapupdate.py was tested via running several different xml_rpc plugin
tests that indirectly utilize ldapupdate.py: test_hbac_plugin.py,
test_sudorule_plugin.py



I tested NIS with Pavel's patch, it worked OK for me.

But have anybody tested replicas with the Pavel's patch? In my
environment the replica server wasn't replicating when I prepared the
with modified ipa-replica-prepare:

$ sudo ipa-replica-install replica-info-vm-139.idm.lab.bos.redhat.com.gpg<-- produced by Pavel's ipa-replica-prepare
...
$ ipa user-find
--------------
1 user matched
--------------
   User login: admin
   Last name: Administrator
   Home directory: /home/admin
   Login shell: /bin/bash
   Account disabled: False
   Member of groups: admins
----------------------------
Number of entries returned 1
----------------------------

$ sudo ipa-server-install --uninstall --unattended
$ sudo ipa-replica-install replica-info-vm-139.idm.lab.bos.redhat.com.gpg.2<-- produced by clean version
...
$ ipa user-find
---------------
2 users matched
---------------
   User login: admin
   Last name: Administrator
   Home directory: /home/admin
   Login shell: /bin/bash
   Account disabled: False
   Member of groups: admins

   User login: ab
   First name: a
   Last name: b
   Home directory: /home/ab
   Login shell: /bin/sh
   Account disabled: False
   Member of groups: ipausers
----------------------------
Number of entries returned 2
----------------------------

User "ab" which was present on the master server (I called
ipa-replica-prepare on the master server) was replicated to the replica
server only when the replica information file (*.gpg) was created with
clean IPA server.

Martin

The above described problem was probably in a test environment. I tested
the patch on a clean VMs and replication was working just fine.

I did not run into any further errors during my NIS/Replica testing, I
think this patch is OK.

Martin

Pushed to master


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]