Changing package t openldap.

With openldap-2.4.35-3.fc19.x86_64 this is easily reproducable using IPA.

I did a yum downgrade openldap-clients openldap openldap-devel which brought me down to openldap-2.4.35-1.fc19.x86_64

Now ldapsearch works as before.

Note that by adding 

SASL_NOCANON off

to /etc/openldap/ldap.conf and restarting dirsrv then the search works again.

The man page for ldap.conf stills says the default is off.

SASL_NOCANON is enabled by default since openldap-2.4.35-3.fc19 (bug #949864) as a part of https://fedoraproject.org/wiki/Features/LessBrittleKerberos. 

This looks more like a configuration problem to me.

I think this is an openldap upstream issue, LDAPI is not handled well in the SASL_NOCANON=on case. I guess the related code is in libraries/libldap/cyrus.c in the function ldap_int_sasl_bind():

...
 /* If we don't need to canonicalize just use the host
  * from the LDAP URI.
  */
 if ( nocanon )
         saslhost = ld->ld_defconn->lconn_server->lud_host;
 else 
         saslhost = ldap_host_connected_to( ld->ld_defconn->lconn_sb,
                                "localhost" );
 rc = ldap_int_sasl_open( ld, ld->ld_defconn, saslhost );
 if ( !nocanon )
         LDAP_FREE( saslhost );
 }
...

As the comment says in the nocanon case the host part from the LDAP URI is used, which does not help much in the case of LDAPI. If you run e.g. ldapsearch with KRB5_TRACE=/dev/stderr  or with '.-d -1' you can see that the LDAPI path, e.g. '/var/run/slapd-IPA18-DEVEL.socket' is used as the saslhost and the Kerberos libraries try to find a matching principal which will certainly fail.

I would suggest to open an OpenLDAP upstream ticket about it and as temporary fix for F19 a fix like:

- if ( nocanon )
+ if ( nocanon && ld->ld_defconn->lconn_server->lud_scheme != NULL && strcmp("ldapi", ld->ld_defconn->lconn_server->lud_scheme) != 0)

This would force LDAPI requests to always call ldap_host_connected_to(). This might case a revers DNS lookup, but since it is only for the local machine I think it is acceptable for the time being.

Alternatively instead of using ld->ld_defconn->lconn_server->lud_host in the LDAPI case the result of gethostname() or uname() can be used.

Simo, do you have a chance to talk to Howard what would be the best solution here?

I guess using gethostname() would be as well in the ldapi case, and have ldapi treated completely differently.

I think something like this should be a patch to send upstream:

if (ld->ld_defconn->lconn_server->lud_scheme != NULL &&
    strcmp("ldapi", ld->ld_defconn->lconn_server->lud_scheme) != 0)
	saslhost = gethostname();
else if (nocanon)
        saslhost = ld->ld_defconn->lconn_server->lud_host;
else 
        saslhost = ldap_host_connected_to(ld->ld_defconn->lconn_sb,
                                          "localhost" );

Created attachment 744866 [details]
Patch for LDAPI SASL issue

Thank you Simo. I put your suggestion into a patch and it is working as expected:

[root@ipa18-devel ~]# rpm -qa |grep openldap-clients
openldap-clients-2.4.34-1.fc18.i686
[root@ipa18-devel ~]# LDAPSASL_NOCANON=on ldapsearch -H 'ldapi://%2fvar%2frun%2fslapd-IPA18-DEVEL.socket' -Y GSSAPI -s base dn
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
	additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Server krbtgt/SOCKET not found in Kerberos database)

update ...

[root@ipa18-devel ~]# rpm -qa |grep openldap-clients
openldap-clients-2.4.35-3sb.fc18.i686
[root@ipa18-devel ~]# LDAPSASL_NOCANON=on ldapsearch -H 'ldapi://%2fvar%2frun%2fslapd-IPA18-DEVEL.socket' -Y GSSAPI -s base dn
SASL/GSSAPI authentication started
SASL username: admin
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <dc=ipa18,dc=devel> (default) with scope baseObject
# filter: (objectclass=*)
# requesting: dn 
#

# ipa18.devel
dn: dc=ipa18,dc=devel

# search result
search: 4
result: 0 Success

# numResponses: 2
# numEntries: 1

Jan, can you review and include this patch to the next update for F18, F19 and rawhide? Thank you.

The patch looks ok, I'll apply it, as it fixes the problem for me as well.

Persuading upstream to include it would be nice.

Pushed:
http://pkgs.fedoraproject.org/cgit/openldap.git/commit/?id=ff5c1adb2a846e3d88c08875c998a99b8956492e

openldap-2.4.35-4.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/openldap-2.4.35-4.fc19

I can confirm that http://koji.fedoraproject.org/koji/buildinfo?buildID=417722 fixes the issue in F18.

openldap-2.4.35-4.fc18.1 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/openldap-2.4.35-4.fc18.1

(In reply to comment #8)
> The patch looks ok, I'll apply it, as it fixes the problem for me as well.
> 
> Persuading upstream to include it would be nice.

I talked with Howard Chu yesterday he is waiting for you to open an ITS and attach the patch.
Feel free to CC me when you do so.

fix from here:

https://admin.fedoraproject.org/updates/openldap-2.4.35-4.fc19

Tested and gave karma. 

Looks like this is fixed:

[root@f19-1 repo]# ldapsearch -Y GSSAPI -H 'ldapi://%2fvar%2frun%2fslapd-IPA-EXAMPLE-ORG.socket'
SASL/GSSAPI authentication started
SASL username: admin.ORG
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <dc=ipa,dc=example,dc=org> (default) with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

...output truncated...
# search result
search: 4
result: 0 Success

# numResponses: 254
# numEntries: 253


And IPA server was installed successfully and I can restart named without issues.
...
Global DNS configuration in LDAP server is empty
You can use 'dnsconfig-mod' command to set global DNS options that
would override settings in local named.conf files

Restarting the web server
==============================================================================
Setup complete

Next steps:
	1. You must make sure these network ports are open:
		TCP Ports:
		  * 80, 443: HTTP/HTTPS
		  * 389, 636: LDAP/LDAPS
		  * 88, 464: kerberos
		  * 53: bind
		UDP Ports:
		  * 88, 464: kerberos
		  * 53: bind
		  * 123: ntp

	2. You can now obtain a kerberos ticket using the command: 'kinit admin'
	   This ticket will allow you to use the IPA tools (e.g., ipa user-add)
	   and the web user interface.

Be sure to back up the CA certificate stored in /root/cacert.p12
This file is required to create replicas. The password for this
file is the Directory Manager password

[root@f19-1 repo]# systemctl restart named.service
[root@f19-1 repo]# 

That was all failing before.  Looks good now with fixed version in koji.

Package openldap-2.4.35-4.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing openldap-2.4.35-4.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-7759/openldap-2.4.35-4.fc19
then log in and leave karma (feedback).

(In reply to comment #13)
> I talked with Howard Chu yesterday he is waiting for you to open an ITS and
> attach the patch.
> Feel free to CC me when you do so.

The ITS is already open and is attached as an external tracker to this bugzilla (ITS#7585)

openldap-2.4.35-4.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

openldap-2.4.35-4.fc18.1 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

This patch has never been applied to OpenLDAP upstream as the required process was not followed.  It would be great if RedHat could follow up with OpenLDAP ITS#7585 (http://www.openldap.org/its/index.cgi/?findid=7585) following the requirements laid out in https://www.openldap.org/devel/contributing.html, particularly the part about providing a valid IPR notice (https://www.openldap.org/devel/contributing.html#notice).  Thanks!

(In reply to Quanah Gibson-Mount from comment #19)
> This patch has never been applied to OpenLDAP upstream as the required
> process was not followed.  It would be great if RedHat could follow up with
> OpenLDAP ITS#7585 (http://www.openldap.org/its/index.cgi/?findid=7585)
> following the requirements laid out in
> https://www.openldap.org/devel/contributing.html, particularly the part
> about providing a valid IPR notice
> (https://www.openldap.org/devel/contributing.html#notice).  Thanks!

IPR has been updated

Thanks Rich, much appreciated!