1108661 – Installers should explicitly specify auth mechanism when calling ldapmodify

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1108661 - Installers should explicitly specify auth mechanism when calling ldapmodify

Summary: Installers should explicitly specify auth mechanism when calling ldapmodify

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 6
Classification:	Red Hat
Component:	ipa
Sub Component:
Version:	6.6
Hardware:	Unspecified
OS:	Unspecified
Priority:	medium
Severity:	unspecified
Target Milestone:	rc
Target Release:	---
Assignee:	Martin Kosek
QA Contact:	Namita Soman
Docs Contact:
URL:
Whiteboard:
Depends On:	1108213
Blocks:
TreeView+	depends on / blocked

Reported:	2014-06-12 12:08 UTC by Martin Kosek
Modified:	2014-10-14 07:32 UTC (History)
CC List:	6 users (show)
Fixed In Version:	ipa-3.0.0-40.el6
Doc Type:	Bug Fix
Doc Text:	Cause: IPA installer may call ldapmodify without explicitly specifying the authentication method, making it overridable by ldapmodify user configuration. Consequence: The installer may fail when the authentication method is set in ldapmodify user configuration. Fix: Make sure the installer always calls ldapmodify with the authentication method explicitly specified. Result: The installer does not fail when authentication method is set in ldapmodify user configuration.
Clone Of:	1108213
Environment:
Last Closed:	2014-10-14 07:32:53 UTC
Target Upstream Version:
Embargoed:
Flags:	nsoman: needinfo+

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHBA-2014:1383	0	normal	SHIPPED_LIVE	ipa bug fix and enhancement update	2014-10-14 01:21:36 UTC

Description Martin Kosek 2014-06-12 12:08:34 UTC

+++ This bug was initially created as a clone of Bug #1108213 +++

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`).

--- Additional comment from Martin Kosek on 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 1 Martin Kosek 2014-06-12 12:12:53 UTC

Reproducer #1:
1) Create /root/.ldaprc with:
SASL_MECH GSSAPI
2) Install IPA server with Trusts:
   # ipa-server-install
   # ipa-adtrust-install


Reproducer #2:
1) Install IPA server
   # ipa-server-install
2) Disable anonymous bind
3) Install Trusts:
   # ipa-adtrust-install

Comment 2 Martin Kosek 2014-06-12 12:13:35 UTC

Fixed upstream:

master: eaaf7ed0f20b81ce10e1e36ce36c673445a83f2b

Comment 5 Scott Poore 2014-07-18 16:01:15 UTC

How do I confirm that reproducer #2 in comment #1 has failed?  

I tried this on both RHEL6.5 and 6.6 and see the same results on both so far. 

From my 6.5 host:

[root@rhel6-5 quickinstall]# ldapmodify -x -D "cn=Directory Manager" -w Secret123 -h $(hostname) -p 389
 
dn: cn=config
changetype: modify
replace: nsslapd-allow-anonymous-access
nsslapd-allow-anonymous-access: rootdse
modifying entry "cn=config"

[root@rhel6-5 quickinstall]# service dirsrv restart
Shutting down dirsrv: 
    PKI-IPA...                                             [  OK  ]
    TESTRELM-TEST...                                       [  OK  ]
Starting dirsrv: 
    PKI-IPA...                                             [  OK  ]
    TESTRELM-TEST...                                       [  OK  ]

[root@rhel6-5 quickinstall]# ipa-adtrust-install 

The log file for this installation can be found in /var/log/ipaserver-install.log
==============================================================================
This program will setup components needed to establish trust to AD domains for
the FreeIPA Server.

This includes:
  * Configure Samba
  * Add trust related objects to FreeIPA LDAP server

To accept the default shown in brackets, press the Enter key.


The following operations may take some minutes to complete.
Please wait until the prompt is returned.

Configuring cross-realm trusts for IPA server requires password for user 'admin'.
This user is a regular system account used for IPA server administration.

admin password: 

Enter the NetBIOS name for the IPA domain.
Only up to 15 uppercase ASCII letters and digits are allowed.
Example: EXAMPLE.


NetBIOS domain name [TESTRELM]: 

Configuring CIFS
  [1/18]: stopping smbd
  [2/18]: creating samba domain object
  [3/18]: creating samba config registry
  [4/18]: writing samba config file
  [5/18]: adding cifs Kerberos principal
  [6/18]: adding cifs principal to S4U2Proxy targets
  [7/18]: adding admin(group) SIDs
  [8/18]: adding RID bases
  [9/18]: updating Kerberos config
'dns_lookup_kdc' already set to 'true', nothing to do.
  [10/18]: activating CLDAP plugin
  [11/18]: activating sidgen plugin and task
  [12/18]: activating extdom plugin
  [13/18]: configuring smbd to start on boot
  [14/18]: adding special DNS service records
  [15/18]: restarting Directory Server to take MS PAC and LDAP plugins changes into account
  [16/18]: adding fallback group
  [17/18]: setting SELinux booleans
  [18/18]: starting CIFS services
Done configuring CIFS.

=============================================================================
Setup complete

You must make sure these network ports are open:
	TCP Ports:
	  * 138: netbios-dgm
	  * 139: netbios-ssn
	  * 445: microsoft-ds
	UDP Ports:
	  * 138: netbios-dgm
	  * 139: netbios-ssn
	  * 389: (C)LDAP
	  * 445: microsoft-ds

Additionally you have to make sure the FreeIPA LDAP server is not reachable
by any domain controller in the Active Directory domain by closing down
the following ports for these servers:
	TCP Ports:
	  * 389, 636: LDAP/LDAPS

You may want to choose to REJECT the network packets instead of DROPing
them to avoid timeouts on the AD domain controllers.

=============================================================================

Then in ipaserver-install.log (just one example of ldapmodify):

2014-07-18T15:47:04Z DEBUG   [16/18]: adding fallback group
2014-07-18T15:47:04Z DEBUG args=/usr/bin/ldapmodify -v -f /tmp/tmpQibgIP -H ldapi://%2fvar%2frun%2fslapd-TESTRELM-TEST.socket
2014-07-18T15:47:04Z DEBUG stdout=add cn:
        Default SMB Group
add description:
        Fallback group for primary group RID, do not add users to this group
add gidnumber:
        999
add objectclass:
        top
        ipaobject
        posixgroup
adding new entry "cn=Default SMB Group,cn=groups,cn=accounts,dc=testrelm,dc=test"
modify complete


2014-07-18T15:47:04Z DEBUG stderr=ldap_initialize( ldapi://%2Fvar%2Frun%2Fslapd-TESTRELM-TEST.socket/??base )
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0

2014-07-18T15:47:04Z DEBUG   duration: 0 seconds

Then in /var/log/messages, I see a lot of errors I think related to anonymous bind being disabled:

Jul 18 10:47:43 rhel6-5 smbd[4619]: [2014/07/18 10:47:43.222067,  0] ../source3/smbd/server.c:1280(main)
Jul 18 10:47:43 rhel6-5 smbd[4619]:   standard input is not a socket, assuming -D option
Jul 18 10:47:43 rhel6-5 winbindd[4640]: [2014/07/18 10:47:43.753784,  0] ../source3/winbindd/winbindd_cache.c:3161(initialize_winbindd_cache)
Jul 18 10:47:43 rhel6-5 winbindd[4640]:   initialize_winbindd_cache: clearing cache and re-creating with version number 2
Jul 18 10:47:44 rhel6-5 smbd[4620]: [2014/07/18 10:47:44.385235,  0] ipa_sam.c:3845(bind_callback)
Jul 18 10:47:44 rhel6-5 smbd[4620]:   bind_callback: cannot perform interactive SASL bind with GSSAPI. LDAP security error is 49
Jul 18 10:47:44 rhel6-5 smbd[4620]: [2014/07/18 10:47:44.385389,  0] ../source3/lib/smbldap.c:998(smbldap_connect_system)
Jul 18 10:47:44 rhel6-5 smbd[4620]:   failed to bind to server ldapi://%2fvar%2frun%2fslapd-TESTRELM-TEST.socket with dn="[Anonymous bind]" Error: Invalid credentials
Jul 18 10:47:44 rhel6-5 smbd[4620]:   #011SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context
Jul 18 10:47:44 rhel6-5 winbindd[4651]: [2014/07/18 10:47:44.386011,  0] ipa_sam.c:3845(bind_callback)
Jul 18 10:47:44 rhel6-5 winbindd[4651]:   bind_callback: cannot perform interactive SASL bind with GSSAPI. LDAP security error is 49
Jul 18 10:47:44 rhel6-5 winbindd[4651]: [2014/07/18 10:47:44.413272,  0] ../source3/lib/smbldap.c:998(smbldap_connect_system)
Jul 18 10:47:44 rhel6-5 winbindd[4651]:   failed to bind to server ldapi://%2fvar%2frun%2fslapd-TESTRELM-TEST.socket with dn="[Anonymous bind]" Error: Invalid credentials
Jul 18 10:47:44 rhel6-5 winbindd[4651]:   #011SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context

And winbind crashes.

I see that on both 6.5 and 6.6 though.  So, how do I confirm the bug using the second reproducer?

Comment 6 Scott Poore 2014-07-18 18:17:36 UTC

Also, is this the expected failure we'll see for reproducer #1?

...
Configuring CIFS
  [1/18]: stopping smbd
  [2/18]: creating samba domain object
  [3/18]: creating samba config registry
  [4/18]: writing samba config file
  [5/18]: adding cifs Kerberos principal
  [6/18]: adding cifs principal to S4U2Proxy targets
  [7/18]: adding admin(group) SIDs
  [8/18]: adding RID bases
  [9/18]: updating Kerberos config
'dns_lookup_kdc' already set to 'true', nothing to do.
  [10/18]: activating CLDAP plugin
ipa         : CRITICAL Failed to load ipa-cldap-conf.ldif: Command '/usr/bin/ldapmodify -v -f /tmp/tmp_gqUji -H ldapi://%2fvar%2frun%2fslapd-IPA1-EXAMPLE-TEST.socket' returned non-zero exit status 50
  [11/18]: activating sidgen plugin and task
ipa         : CRITICAL Failed to load ipa-sidgen-conf.ldif: Command '/usr/bin/ldapmodify -v -f /tmp/tmp_qU4EM -H ldapi://%2fvar%2frun%2fslapd-IPA1-EXAMPLE-TEST.socket' returned non-zero exit status 50
ipa         : CRITICAL Failed to load ipa-sidgen-task-conf.ldif: Command '/usr/bin/ldapmodify -v -f /tmp/tmp3mAhm8 -H ldapi://%2fvar%2frun%2fslapd-IPA1-EXAMPLE-TEST.socket' returned non-zero exit status 50
  [12/18]: activating extdom plugin
ipa         : CRITICAL Failed to load ipa-extdom-extop-conf.ldif: Command '/usr/bin/ldapmodify -v -f /tmp/tmpjovL9f -H ldapi://%2fvar%2frun%2fslapd-IPA1-EXAMPLE-TEST.socket' returned non-zero exit status 50
  [13/18]: configuring smbd to start on boot
  [14/18]: adding special DNS service records
  [15/18]: restarting Directory Server to take MS PAC and LDAP plugins changes into account
  [16/18]: adding fallback group
  [17/18]: setting SELinux booleans
  [18/18]: starting CIFS services
Done configuring CIFS.

Comment 7 Martin Kosek 2014-07-21 08:51:51 UTC

(In reply to Scott Poore from comment #6)
> Also, is this the expected failure we'll see for reproducer #1?

I think so, you could check the logs to be absolutely sure.

(In reply to Scott Poore from comment #5)
> How do I confirm that reproducer #2 in comment #1 has failed?  
> 
> I tried this on both RHEL6.5 and 6.6 and see the same results on both so
> far. 

Could this be related to Bug 1104901? CCing Alexander. In my test with ipa-server-3.0.0-42.el6.x86_64, this scenario worked:

# ipa-server-install

# ldapmodify -x -D "cn=directory manager" -w Secret123 -h `hostname`
dn: cn=config
changetype: modify
replace: nsslapd-allow-anonymous-access
nsslapd-allow-anonymous-access: rootdse

modifying entry "cn=config"

# service dirsrv restart
Shutting down dirsrv: 
    IDM-LAB-BOS-REDHAT-COM...                              [  OK  ]
    PKI-IPA...                                             [  OK  ]
Starting dirsrv: 
    IDM-LAB-BOS-REDHAT-COM...                              [  OK  ]
    PKI-IPA...                                             [  OK  ]

# ipa-adtrust-install 
...
Configuring CIFS
  [1/18]: stopping smbd
  [2/18]: creating samba domain object
  [3/18]: creating samba config registry
  [4/18]: writing samba config file
  [5/18]: adding cifs Kerberos principal
  [6/18]: adding cifs principal to S4U2Proxy targets
  [7/18]: adding admin(group) SIDs
  [8/18]: adding RID bases
  [9/18]: updating Kerberos config
'dns_lookup_kdc' already set to 'true', nothing to do.
  [10/18]: activating CLDAP plugin
  [11/18]: activating sidgen plugin and task
  [12/18]: activating extdom plugin
  [13/18]: configuring smbd to start on boot
  [14/18]: adding special DNS service records
  [15/18]: restarting Directory Server to take MS PAC and LDAP plugins changes into account
  [16/18]: adding fallback group
  [17/18]: setting SELinux booleans
  [18/18]: starting CIFS services
Done configuring CIFS.
...

# tail /var/log/samba/log.smbd
[2014/07/21 16:43:16.238069,  1] ../source3/passdb/account_pol.c:346(account_policy_get)
  account_policy_get: tdb_fetch_uint32 failed for type 8 (bad lockout attempt), returning 0
[2014/07/21 16:43:16.238151,  1] ../source3/passdb/account_pol.c:346(account_policy_get)
  account_policy_get: tdb_fetch_uint32 failed for type 9 (disconnect time), returning 0
[2014/07/21 16:43:16.241315,  1] ../source3/passdb/account_pol.c:346(account_policy_get)
  account_policy_get: tdb_fetch_uint32 failed for type 10 (refuse machine password change), returning 0
[2014/07/21 16:43:16.291057,  1] ../source3/rpc_server/epmd.c:148(start_epmd)
  Forking Endpoint Mapper Daemon
[2014/07/21 16:43:16.361693,  1] ../source3/rpc_server/lsasd.c:854(start_lsasd)
  Forking LSA Service Daemon


I am now actually thinking where did the reproducer #2 come from. Reproducer #1 is solid, #2 may not be so relevant.

Comment 8 Alexander Bokovoy 2014-07-21 10:45:46 UTC

I have got reproducer #2 working, prior to the patch it was failing and the failure is visible in /var/log/ipaserver-install.log. Note that you should look there instead of attempting to use smbd because if entries were not created properly, you'll never get smbd working properly either but the root problem should be seen at ipa-adtrust-install time (i.e. in ipaserver-install.log).

Comment 9 Scott Poore 2014-07-21 13:17:20 UTC

Martin,

In logs I do see success for reproducer #1 where it fails on older:

On older server where it failed:

2014-07-18T17:55:33Z DEBUG   [12/18]: activating extdom plugin
2014-07-18T17:55:33Z DEBUG args=/usr/bin/ldapmodify -v -f /tmp/tmpjovL9f -H ldapi://%2fvar%2frun%2fslapd-IPA1-EXAMPLE-TEST.socket
2014-07-18T17:55:33Z 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=ipa1,dc=example,dc=test
adding new entry "cn=ipa_extdom_extop,cn=plugins,cn=config"


2014-07-18T17:55:33Z DEBUG stderr=ldap_initialize( ldapi://%2Fvar%2Frun%2Fslapd-IPA1-EXAMPLE-TEST.socket/??base )
SASL/GSSAPI authentication started
SASL username: admin.TEST
SASL SSF: 56
SASL data security layer installed.
ldap_add: Insufficient access (50)
        additional info: Insufficient 'add' privilege to add the entry 'cn=plugins,cn=config'.


2014-07-18T17:55:33Z CRITICAL Failed to load ipa-extdom-extop-conf.ldif: Command '/usr/bin/ldapmodify -v -f /tmp/tmpjovL9f -H ldapi://%2fvar%2frun%2fslapd-IPA1-EXAMPLE-TEST.socket' returned non-zero exit status 50
2014-07-18T17:55:33Z DEBUG   duration: 0 seconds


On RHEL6.6 server where it did not fail:

2014-07-18T17:55:34Z DEBUG   [12/18]: activating extdom plugin
2014-07-18T17:55:34Z DEBUG args=/usr/bin/ldapmodify -v -f /tmp/tmp7DRmGd -H ldapi://%2fvar%2frun%2fslapd-IPA1-EXAMPLE-TEST.socket -Y EXTERNAL
2014-07-18T17:55:34Z 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=ipa1,dc=example,dc=test
adding new entry "cn=ipa_extdom_extop,cn=plugins,cn=config"
modify complete


2014-07-18T17:55:34Z DEBUG stderr=ldap_initialize( ldapi://%2Fvar%2Frun%2Fslapd-IPA1-EXAMPLE-TEST.socket/??base )
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0

2014-07-18T17:55:34Z DEBUG   duration: 0 seconds

Thanks

Comment 10 Scott Poore 2014-07-21 14:23:33 UTC

Alexander,

Do you have an example of what I should see in ipaserver-install.log when this fails for reproducer #2?

I tried again and saw the same thing:

Looking at the same failure I saw in comment #9 from reproducer #1, I checked again for reproducer #2 to fail.  However, I don't see a failure.

2014-07-21T14:18:23Z DEBUG   [12/18]: activating extdom plugin
2014-07-21T14:18:23Z DEBUG args=/usr/bin/ldapmodify -v -f /tmp/tmpmZj03R -H ldapi://%2fvar%2frun%2fslapd-IPA1-EXAMPLE-TEST.socket
2014-07-21T14:18:23Z 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=ipa1,dc=example,dc=test
adding new entry "cn=ipa_extdom_extop,cn=plugins,cn=config"
modify complete


2014-07-21T14:18:23Z DEBUG stderr=ldap_initialize( ldapi://%2Fvar%2Frun%2Fslapd-IPA1-EXAMPLE-TEST.socket/??base )
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0

2014-07-21T14:18:23Z DEBUG   duration: 0 seconds

Thanks,
Scott

Comment 11 Scott Poore 2014-07-21 18:00:29 UTC

Also, is there a way to verify this one that does not require ipa-adtrust-install?  Or is that the primary culprit here?  What about ipa-dns-install? Could I test with that instead?

Comment 12 Martin Kosek 2014-07-22 08:36:42 UTC

I tried ipa-dns-install with reproducer #1 and it worked fine. So the only known reproducer for this bug is still reproducer #1 and ipa-adtrust-install.

Comment 13 Scott Poore 2014-07-23 14:33:06 UTC

I talked to Alexander and unfortunately we don't have example ipaserver-install.log failures to compare.  Since I was unable to reproduce with #2, I'll mark this verified sanityonly with reproducer #1.

Verified.

Version ::

ipa-server-3.0.0-42.el6.x86_64

Results ::

See comment #9

Comment 14 errata-xmlrpc 2014-10-14 07:32:53 UTC

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.

http://rhn.redhat.com/errata/RHBA-2014-1383.html

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