In Fedora 19, we have a feature to remove needless kerberos brittleness: https://fedoraproject.org/wiki/Features/LessBrittleKerberos One such soucre of brittleness is the behavior of openldap with regards to the host it passes to SASL. By openldap passes the IP address of the host it connected to to SASL, in an effort to force canonicalization of the host name. However krb5 has its own rdns canonicalization options. In Fedora 19 we've turned them off by default, in order to interoperate with most kerberos realms in the wild which are not careful about reverse DNS records. See bug# 908323. OpenLDAP should by default pass the full hostname to SASL, and let SASL (plugins like GSSAPI, krb5) decide whether they want to canonicalize the hostname or not. By adding 'SASL_NOCANON on' to /etc/openldap/ldap.conf we can have out of the box non-broken behavior for openldap when used with GSSAPI.
ldapwhoami output that exhibits the problem. win-fi8gnnit6cj.borg.thewalter.lan is an AD domain controller. 192.168.12.12 is its IP address. [stef@localhost cyrus-sasl]$ KRB5_TRACE=/dev/stderr ldapwhoami -d -1 -H ldap://win-fi8gnnit6cj.borg.thewalter.lan ldap_url_parse_ext(ldap://win-fi8gnnit6cj.borg.thewalter.lan) ldap_create ldap_url_parse_ext(ldap://win-fi8gnnit6cj.borg.thewalter.lan:389/??base) ldap_pvt_sasl_getmech ldap_search put_filter: "(objectclass=*)" put_filter: simple put_simple_filter: "objectclass=*" ldap_build_search_req ATTRS: supportedSASLMechanisms ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP win-fi8gnnit6cj.borg.thewalter.lan:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 192.168.12.12:389 ldap_pvt_connect: fd: 3 tm: -1 async: 0 attempting to connect: connect success ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_dump: buf=0x7feef137a540 ptr=0x7feef137a540 end=0x7feef137a580 len=64 0000: 30 3e 02 01 01 63 39 04 00 0a 01 00 0a 01 00 02 0>...c9......... 0010: 01 00 02 01 00 01 01 00 87 0b 6f 62 6a 65 63 74 ..........object 0020: 63 6c 61 73 73 30 19 04 17 73 75 70 70 6f 72 74 class0...support 0030: 65 64 53 41 53 4c 4d 65 63 68 61 6e 69 73 6d 73 edSASLMechanisms ber_scanf fmt ({) ber: ber_dump: buf=0x7feef137a540 ptr=0x7feef137a545 end=0x7feef137a580 len=59 0000: 63 39 04 00 0a 01 00 0a 01 00 02 01 00 02 01 00 c9.............. 0010: 01 01 00 87 0b 6f 62 6a 65 63 74 63 6c 61 73 73 .....objectclass 0020: 30 19 04 17 73 75 70 70 6f 72 74 65 64 53 41 53 0...supportedSAS 0030: 4c 4d 65 63 68 61 6e 69 73 6d 73 LMechanisms ber_flush2: 64 bytes to sd 3 0000: 30 3e 02 01 01 63 39 04 00 0a 01 00 0a 01 00 02 0>...c9......... 0010: 01 00 02 01 00 01 01 00 87 0b 6f 62 6a 65 63 74 ..........object 0020: 63 6c 61 73 73 30 19 04 17 73 75 70 70 6f 72 74 class0...support 0030: 65 64 53 41 53 4c 4d 65 63 68 61 6e 69 73 6d 73 edSASLMechanisms ldap_write: want=64, written=64 0000: 30 3e 02 01 01 63 39 04 00 0a 01 00 0a 01 00 02 0>...c9......... 0010: 01 00 02 01 00 01 01 00 87 0b 6f 62 6a 65 63 74 ..........object 0020: 63 6c 61 73 73 30 19 04 17 73 75 70 70 6f 72 74 class0...support 0030: 65 64 53 41 53 4c 4d 65 63 68 61 6e 69 73 6d 73 edSASLMechanisms ldap_result ld 0x7feef13710a0 msgid 1 wait4msg ld 0x7feef13710a0 msgid 1 (infinite timeout) wait4msg continue ld 0x7feef13710a0 msgid 1 all 1 ** ld 0x7feef13710a0 Connections: * host: win-fi8gnnit6cj.borg.thewalter.lan port: 389 (default) refcnt: 2 status: Connected last used: Tue Apr 9 09:17:09 2013 ** ld 0x7feef13710a0 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x7feef13710a0 request count 1 (abandoned 0) ** ld 0x7feef13710a0 Response Queue: Empty ld 0x7feef13710a0 response count 0 ldap_chkResponseList ld 0x7feef13710a0 msgid 1 all 1 ldap_chkResponseList returns ld 0x7feef13710a0 NULL ldap_int_select read1msg: ld 0x7feef13710a0 msgid 1 all 1 ber_get_next ldap_read: want=8, got=8 0000: 30 84 00 00 00 60 02 01 0....`.. ldap_read: want=94, got=94 0000: 01 64 84 00 00 00 57 04 00 30 84 00 00 00 4f 30 .d....W..0....O0 0010: 84 00 00 00 49 04 17 73 75 70 70 6f 72 74 65 64 ....I..supported 0020: 53 41 53 4c 4d 65 63 68 61 6e 69 73 6d 73 31 84 SASLMechanisms1. 0030: 00 00 00 2a 04 06 47 53 53 41 50 49 04 0a 47 53 ...*..GSSAPI..GS 0040: 53 2d 53 50 4e 45 47 4f 04 08 45 58 54 45 52 4e S-SPNEGO..EXTERN 0050: 41 4c 04 0a 44 49 47 45 53 54 2d 4d 44 35 AL..DIGEST-MD5 ber_get_next: tag 0x30 len 96 contents: ber_dump: buf=0x7feef137c680 ptr=0x7feef137c680 end=0x7feef137c6e0 len=96 0000: 02 01 01 64 84 00 00 00 57 04 00 30 84 00 00 00 ...d....W..0.... 0010: 4f 30 84 00 00 00 49 04 17 73 75 70 70 6f 72 74 O0....I..support 0020: 65 64 53 41 53 4c 4d 65 63 68 61 6e 69 73 6d 73 edSASLMechanisms 0030: 31 84 00 00 00 2a 04 06 47 53 53 41 50 49 04 0a 1....*..GSSAPI.. 0040: 47 53 53 2d 53 50 4e 45 47 4f 04 08 45 58 54 45 GSS-SPNEGO..EXTE 0050: 52 4e 41 4c 04 0a 44 49 47 45 53 54 2d 4d 44 35 RNAL..DIGEST-MD5 read1msg: ld 0x7feef13710a0 msgid 1 message type search-entry wait4msg continue ld 0x7feef13710a0 msgid 1 all 1 ** ld 0x7feef13710a0 Connections: * host: win-fi8gnnit6cj.borg.thewalter.lan port: 389 (default) refcnt: 2 status: Connected last used: Tue Apr 9 09:17:09 2013 ** ld 0x7feef13710a0 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x7feef13710a0 request count 1 (abandoned 0) ** ld 0x7feef13710a0 Response Queue: * msgid 1, type 100 ld 0x7feef13710a0 response count 1 ldap_chkResponseList ld 0x7feef13710a0 msgid 1 all 1 ldap_chkResponseList returns ld 0x7feef13710a0 NULL ldap_int_select read1msg: ld 0x7feef13710a0 msgid 1 all 1 ber_get_next ldap_read: want=8, got=8 0000: 30 84 00 00 00 10 02 01 0....... ldap_read: want=14, got=14 0000: 01 65 84 00 00 00 07 0a 01 00 04 00 04 00 .e............ ber_get_next: tag 0x30 len 16 contents: ber_dump: buf=0x7feef137c3c0 ptr=0x7feef137c3c0 end=0x7feef137c3d0 len=16 0000: 02 01 01 65 84 00 00 00 07 0a 01 00 04 00 04 00 ...e............ read1msg: ld 0x7feef13710a0 msgid 1 message type search-result ber_scanf fmt ({eAA) ber: ber_dump: buf=0x7feef137c3c0 ptr=0x7feef137c3c3 end=0x7feef137c3d0 len=13 0000: 65 84 00 00 00 07 0a 01 00 04 00 04 00 e............ read1msg: ld 0x7feef13710a0 0 new referrals read1msg: mark request completed, ld 0x7feef13710a0 msgid 1 request done: ld 0x7feef13710a0 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) adding response ld 0x7feef13710a0 msgid 1 type 101: ldap_parse_result ber_scanf fmt ({iAA) ber: ber_dump: buf=0x7feef137c3c0 ptr=0x7feef137c3c3 end=0x7feef137c3d0 len=13 0000: 65 84 00 00 00 07 0a 01 00 04 00 04 00 e............ ber_scanf fmt (}) ber: ber_dump: buf=0x7feef137c3c0 ptr=0x7feef137c3d0 end=0x7feef137c3d0 len=0 ldap_get_values ber_scanf fmt ({x{{a) ber: ber_dump: buf=0x7feef137c680 ptr=0x7feef137c683 end=0x7feef137c6e0 len=93 0000: 64 84 00 00 00 57 04 00 30 84 00 00 00 4f 30 84 d....W..0....O0. 0010: 00 00 00 49 04 17 73 75 70 70 6f 72 74 65 64 53 ...I..supportedS 0020: 41 53 4c 4d 65 63 68 61 6e 69 73 6d 73 31 84 00 ASLMechanisms1.. 0030: 00 00 2a 04 06 47 53 53 41 50 49 04 0a 47 53 53 ..*..GSSAPI..GSS 0040: 2d 53 50 4e 45 47 4f 04 08 45 58 54 45 52 4e 41 -SPNEGO..EXTERNA 0050: 4c 04 0a 44 49 47 45 53 54 2d 4d 44 35 L..DIGEST-MD5 ber_scanf fmt ([v]) ber: ber_dump: buf=0x7feef137c680 ptr=0x7feef137c6b0 end=0x7feef137c6e0 len=48 0000: 31 84 00 00 00 2a 04 06 47 53 53 41 50 49 04 0a 1....*..GSSAPI.. 0010: 47 53 53 2d 53 50 4e 45 47 4f 04 08 45 58 54 45 GSS-SPNEGO..EXTE 0020: 52 4e 41 4c 04 0a 44 49 47 45 53 54 2d 4d 44 35 RNAL..DIGEST-MD5 ldap_msgfree ldap_sasl_interactive_bind: server supports: GSSAPI GSS-SPNEGO EXTERNAL DIGEST-MD5 ldap_int_sasl_bind: GSSAPI GSS-SPNEGO EXTERNAL DIGEST-MD5 ldap_int_sasl_open: host=192.168.12.12 SASL/GSSAPI authentication started [3300] 1365491829.917294: Convert service ldap (service with host as instance) on host 192.168.12.12 to principal [3300] 1365491829.917357: Remote host after forward canonicalization: 192.168.12.12 [3300] 1365491829.917418: Remote host after reverse DNS processing: 192.168.12.12 [3300] 1365491829.917455: Get host realm for 192.168.12.12 ldap_msgfree ldap_err2string 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 (Cannot determine realm for numeric host address) ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 3 0000: 30 05 02 01 02 42 00 0....B. ldap_write: want=7, written=7 0000: 30 05 02 01 02 42 00 0....B. ldap_free_connection: actually freed
Upstream openldap discussion of the SASL_NOCANON issue is here: http://www.openldap.org/lists/openldap-bugs/200811/msg00178.html However, note that upstream MIT krb5 is moving away from using host canonicalization via reverse dns, and away from using CNAME's plus PTR records to balance between kerberos services that have different host principals.
Created attachment 733052 [details] Set SASL_NOCANON to on by default
+1 Note that relying on PTR records has never been recommended by the KErberos community, RFC 4120 in section 1.3 explictly recommend to never rely on DNS to resolve aliases, and it does that because relying on PTR records open the way to an attack via DNS spoofing.
openldap-2.4.35-3.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/openldap-2.4.35-3.fc19
Pushed: http://pkgs.fedoraproject.org/cgit/openldap.git/commit/?id=50ba1f03e93b9636dd537d3547b9bf5d7afeafff
Package openldap-2.4.35-3.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-3.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-5682/openldap-2.4.35-3.fc19 then log in and leave karma (feedback).
*** Bug 908913 has been marked as a duplicate of this bug. ***
openldap-2.4.35-3.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
The patch has that adds "SASL_NOCANON on" to the config file does so without a trailing newline. You can see by cat'ing the file: [root@localhost ~]# cat /etc/openldap/ldap.conf [snip_for_brevity] # Turning this off breaks GSSAPI used with krb5 when rdns = false SASL_NOCANON on[root@localhost ~]# This breaks sysadmin scripts that append to that file. For example: echo -e "TLS_CACERT\t/etc/openldap/server.crt" >> /etc/openldap/ldap.conf I discovered this when testing automation scripts against RHEL7 beta. Please fix this config file to have a trailing newline.
(In reply to Dax Kelson from comment #10) > The patch has that adds "SASL_NOCANON on" to the config file does so without > a trailing newline. Somehow, I forgot to fix this in F19. This will be fixed when bug 1067818 is fixed.
Want to add on going from RHEL6 to RHEL7 saslauthd stopped working for me where I was using MECH=ldap and ldap_use_sasl set to yes. I got it to work again by commenting out this SASL_NOCANON line in /etc/openldap/ldap.conf. I don't really understand the full consequence of this. I don't have rdns set in krb5.conf and the man pages implies the default is true so I guess I am okay. kinit still works.