Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1108213 - Installers should explicitly specify auth mechanism when calling ldapmodify
Installers should explicitly specify auth mechanism when calling ldapmodify
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipa (Show other bugs)
7.1
Unspecified Unspecified
medium Severity unspecified
: rc
: ---
Assigned To: Martin Kosek
Namita Soman
:
Depends On:
Blocks: 1108661
  Show dependency treegraph
 
Reported: 2014-06-11 10:49 EDT by Martin Kosek
Modified: 2015-03-05 05:11 EST (History)
4 users (show)

See Also:
Fixed In Version: ipa-4.0.3-1.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1108661 (view as bug list)
Environment:
Last Closed: 2015-03-05 05:11:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:0442 normal SHIPPED_LIVE Moderate: ipa security, bug fix, and enhancement update 2015-03-05 09:50:39 EST

  None (edit)
Description Martin Kosek 2014-06-11 10:49:12 EDT
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/freeipa/ticket/3895

This is a follow up for ticket #3776 (https://bugzilla.redhat.com/show_bug.cgi?id=983237).

Our calls to `ldapmodify` binary during `ipa-adtrust-install` (and others) do not specify authentication mechanism. If user has existing `.ldaprc` and have the default mechanism set to GSSAPI one, installers may crash with difficult-to-trace errors.

We should explicitly specify what auth mechanism we want to use, when calling LDAP modification binaries (in most cases, it's `EXTERNAL`).
Comment 1 Martin Kosek 2014-06-11 11:23:23 EDT
This request is already fixed in upstream FreeIPA project. Please refer to the linked ticket for additional details and related commits.
Comment 3 Steeve Goveas 2015-01-20 08:43:26 EST
Please add steps to test this bug
Comment 4 Martin Kosek 2015-01-20 09:43:30 EST
See reproduction and discussion in the cloned bug:

https://bugzilla.redhat.com/show_bug.cgi?id=1108661#c1
Comment 5 Scott Poore 2015-01-27 19:58:52 EST
Verified Sanity Only like the cloned bug.

Version ::

Results ::

[root@vm8 ~]# cat .ldaprc 
SASL_MECH GSSAPI

relevant history:

  103  ipa-server-install --setup-dns --forwarder=192.168.122.1 --hostname=vm8.ipa2.example.com --ip-address=192.168.122.208 -n ipa2.example.com -r IPA2.EXAMPLE.COM -a Secret123 -p Secret123 -U
  104  yum -y install samba-client samba-winbind-clients *ipa-server-trust-ad telnet
  105  cat ~/.ldaprc 
  106  ipa-adtrust-install --enable-compat --netbios-name=IPA2 --add-sids -a Secret123 -U

ipaserver-install.log:

2015-01-28T00:55:06Z DEBUG   [13/22]: activating extdom plugin
2015-01-28T00:55:06Z DEBUG Starting external process
2015-01-28T00:55:06Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' '/tmp/tmpun5VXp' '-H' 'ldapi://%2fvar%2frun%2fslapd-IPA2-EXAMPLE-COM.socket' '-Y' 'EXTERNAL'
2015-01-28T00:55:06Z DEBUG Process finished, return code=0
2015-01-28T00:55:06Z DEBUG stdout=add objectclass:
        top
        nsSlapdPlugin
        extensibleObject
add cn:
        ipa_extdom_extop
add nsslapd-pluginpath:
        libipa_extdom_extop
add nsslapd-plugininitfunc:
        ipa_extdom_init
add nsslapd-plugintype:
        extendedop
add nsslapd-pluginenabled:
        on
add nsslapd-pluginid:
        ipa_extdom_extop
add nsslapd-pluginversion:
        1.0
add nsslapd-pluginvendor:
        RedHat
add nsslapd-plugindescription:
        Support resolving IDs in trusted domains to names and back
add nsslapd-plugin-depends-on-type:
        database
add nsslapd-basedn:
        dc=ipa2,dc=example,dc=com
adding new entry "cn=ipa_extdom_extop,cn=plugins,cn=config"
modify complete


2015-01-28T00:55:06Z DEBUG stderr=ldap_initialize( ldapi://%2Fvar%2Frun%2Fslapd-IPA2-EXAMPLE-COM.socket/??base )
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0

2015-01-28T00:55:06Z DEBUG   duration: 0 seconds
Comment 7 errata-xmlrpc 2015-03-05 05:11:38 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2015-0442.html

Note You need to log in before you can comment on or make changes to this bug.