SASL auth to LDAP behind HAPROXY with name mismatches

My kerberos domain in MYEXAMPLE.ORG, but servers are located in the dmz-int.example.org dns zone.

LDAP server is b1.dmz-int.example.org; its keytab include:

udo ktutil -k /etc/krb5.keytab list
/etc/krb5.keytab:

Vno  Type                     Principal                              Aliases
  7  arcfour-hmac-md5         [email protected]
  7  aes128-cts-hmac-sha1-96  [email protected]
  7  aes256-cts-hmac-sha1-96  [email protected]
  7  arcfour-hmac-md5         host/[email protected]
  7  aes128-cts-hmac-sha1-96  host/[email protected]
  7  aes256-cts-hmac-sha1-96  host/[email protected]
  7  arcfour-hmac-md5         ldap/[email protected]
  7  aes128-cts-hmac-sha1-96  ldap/[email protected]
  7  aes256-cts-hmac-sha1-96  ldap/[email protected]
  7  arcfour-hmac-md5         ldap/[email protected]
  7  aes128-cts-hmac-sha1-96  ldap/[email protected]
  7  aes256-cts-hmac-sha1-96  ldap/[email protected]
  7  arcfour-hmac-md5         ldap/[email protected]
  7  aes128-cts-hmac-sha1-96  ldap/[email protected]
  7  aes256-cts-hmac-sha1-96  ldap/[email protected]

ldap2.myexample.org is a CNAME of b1.dmz-int.example.org

Now I can connect with GSSAPI to LDAP server:

$ kinit
$ ldapsearch -ZZ -h b1.dmz-int.example.org 'uid=test'
SASL/GSSAPI authentication started
SASL username: [email protected]
SASL SSF: 56
SASL data security layer installed.
[...]
$ ldapsearch -ZZ -h ldap2.myexample.org 'uid=test'
SASL/GSSAPI authentication started
SASL username: [email protected]
SASL SSF: 56
SASL data security layer installed.
[...]
$ klist
Credentials cache: FILE:/tmp/krb5cc_1000
    Principal: [email protected]

Issued                Expires               Principal
Sep  6 09:03:35 2016  Sep  6 19:03:32 2016  krbtgt/[email protected]
Sep  6 09:03:39 2016  Sep  6 19:03:32 2016  ldap/[email protected]

Looks fine.

Now comes the proxy.

Proxy A record is ldap.dmz-int.example.org and it has a CNAME as ldap.myexample.org.

Proxy is a HAPROXY layer 4 for ports 389 and 636. Without SASL it works fine.

$ ldapsearch -ZZ -h ldap.myexample.org 'uid=test'
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
        additional info: SASL(-1): generic failure: GSSAPI Error:  Miscellaneous failure (see text) (Matching credential (ldap/[email protected]) not found)
$ ldapsearch -h ldap.dmz-int.example.org 'uid=test'
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
        additional info: SASL(-1): generic failure: GSSAPI Error:  Miscellaneous failure (see text) (Matching credential (ldap/[email protected]) not found)

And now SASL doesn't work. Do I need an extra SPN in the server keytab? Do I need some dns fixes? Why the proxy query looks for the: ldap/[email protected] principal and not ldap/[email protected]?

As a reference, follows the haproxy conf file:

$ cat /etc/haproxy/haproxy.cfg
global
        log /dev/log    local0
#       log /dev/log    local1 notice
        chroot /var/lib/haproxy
        stats socket /run/haproxy/admin.sock mode 660 level admin
        stats timeout 30s
        user haproxy
        group haproxy
        daemon

        # Default SSL material locations
        ca-base /etc/ssl/certs
        crt-base /etc/ssl/private

        # Default ciphers to use on SSL-enabled listening sockets.
        # For more information, see ciphers(1SSL). This list is from:
        #  https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/
        ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS
        ssl-default-bind-options no-sslv3

# LDAP and LDAP/STARTTLS
frontend ldap_service_front
  log           global
  mode                  tcp
  bind                  *:389
  description           LDAP Service
  option                socket-stats
  option                tcpka
  option                tcplog
  timeout client        10s
  default_backend       ldap_service_back

backend ldap_service_back
  log           global
  server                ldap-1 b1.myexample.org:389 check fall 1 rise 1 inter 2s
  server                ldap-2 b2.myexample.org:389 check fall 1 rise 1 inter 2s
  mode                  tcp
  balance               leastconn
  option                tcpka
  option                ldap-check
  timeout server        10s
  timeout connect       1s

You'll want ignore_acceptor_hostname = true in either [libdefaults] or the appropriate subsection of [appdefaults].

ignore_acceptor_hostname
When accepting GSSAPI or krb5 security contexts for host-based service principals, ignore any hostname passed by the calling application, and allow clients to authenticate to any service principal in the keytab matching the service name and realm name (if given). This option can improve the administrative flexibility of server applications on multihomed hosts, but could compromise the security of virtual hosting environments.
The default value is false. New in release 1.10.