Bug 960222 - SASL canonicalization semantic change between Fedora 17 and Fedora 19
Summary: SASL canonicalization semantic change between Fedora 17 and Fedora 19
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: openldap
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jan Synacek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-05-06 17:52 UTC by Petr Spacek
Modified: 2019-04-18 20:34 UTC (History)
13 users (show)

Fixed In Version: openldap-2.4.35-4.fc18.1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-05-14 04:49:35 UTC


Attachments (Terms of Use)
/etc/hosts (241 bytes, text/plain)
2013-05-06 17:52 UTC, Petr Spacek
no flags Details
Patch for LDAPI SASL issue (1.57 KB, patch)
2013-05-07 18:58 UTC, Sumit Bose
no flags Details | Diff


Links
System ID Priority Status Summary Last Updated
OpenLDAP ITS 7585 None None None Never

Description Petr Spacek 2013-05-06 17:52:10 UTC
Created attachment 744283 [details]
/etc/hosts

Description of problem:
LDAP connection via Unix socket to SASL+Kerberos secured LDAP server (389-ds-base-1.3.1.0-1.fc19.x86_64 installed by freeipa-server-3.1.99-0.20130506T1137Zgitbe8c9ec.fc19.x86_64) fails with weird error: "Server krbtgt/SOCKET@TESTRELM.COM not found in Kerberos database".

It looks like some failure in name canonicalization (???).


The example below worked on F17 without any problem:
cyrus-sasl-2.1.23-31.fc17.x86_64


Version-Release number of selected component (if applicable):
cyrus-sasl-2.1.26-6.fc19.x86_64
cyrus-sasl-2.1.23-36.fc19.x86_64


How reproducible:
100 %


Steps to Reproduce:
1. kinit as someone to acquire Kerberos TGT
2. run
$ ldapsearch -Y GSSAPI -H 'ldapi://%2fvar%2frun%2fslapd-TESTRELM-COM.socket'
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@TESTRELM.COM not found in Kerberos database)


Actual results:
Connection fails with weird error.


Expected results:
Connection is established.


Additional info:
Everything works when I use real hostname (of the local machine) instead of Unix socket.

$ ldapsearch -Y GSSAPI -H 'ldap://f19-1.testrelm.com'
SASL/GSSAPI authentication started
SASL username: DNS/f19-1.testrelm.com@TESTRELM.COM
SASL SSF: 56
SASL data security layer installed.

Comment 1 Rob Crittenden 2013-05-06 19:36:25 UTC
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.

Comment 2 Rob Crittenden 2013-05-06 19:51:32 UTC
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.

Comment 3 Jan Včelák 2013-05-06 21:56:40 UTC
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.

Comment 4 Sumit Bose 2013-05-07 07:32:31 UTC
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?

Comment 5 Simo Sorce 2013-05-07 12:48:06 UTC
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" );

Comment 6 Sumit Bose 2013-05-07 18:58:13 UTC
Created attachment 744866 [details]
Patch for LDAPI SASL issue

Comment 7 Sumit Bose 2013-05-07 19:00:39 UTC
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@IPA18.DEVEL 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@IPA18.DEVEL
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.

Comment 8 Jan Synacek 2013-05-09 07:32:15 UTC
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.

Comment 10 Fedora Update System 2013-05-09 09:12:54 UTC
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

Comment 11 Anthony Messina 2013-05-09 11:35:09 UTC
I can confirm that http://koji.fedoraproject.org/koji/buildinfo?buildID=417722 fixes the issue in F18.

Comment 12 Fedora Update System 2013-05-09 13:38:39 UTC
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

Comment 13 Simo Sorce 2013-05-09 14:07:04 UTC
(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.

Comment 14 Scott Poore 2013-05-09 15:21:02 UTC
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@IPA.EXAMPLE.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.

Comment 15 Fedora Update System 2013-05-09 17:56:21 UTC
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).

Comment 16 Jan Synacek 2013-05-10 05:18:58 UTC
(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)

Comment 17 Fedora Update System 2013-05-14 04:49:35 UTC
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.

Comment 18 Fedora Update System 2013-05-21 08:46:09 UTC
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.

Comment 19 Quanah Gibson-Mount 2019-04-18 01:33:51 UTC
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!

Comment 20 Rich Megginson 2019-04-18 20:27:52 UTC
(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

Comment 21 Quanah Gibson-Mount 2019-04-18 20:34:51 UTC
Thanks Rich, much appreciated!


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