SASL auth to LDAP behind HAPROXY with name mismatches

Question

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         b1$@MYEXAMPLE.ORG
  7  aes128-cts-hmac-sha1-96  b1$@MYEXAMPLE.ORG
  7  aes256-cts-hmac-sha1-96  b1$@MYEXAMPLE.ORG
  7  arcfour-hmac-md5         host/b1.dmz-int.example.org@MYEXAMPLE.ORG
  7  aes128-cts-hmac-sha1-96  host/b1.dmz-int.example.org@MYEXAMPLE.ORG
  7  aes256-cts-hmac-sha1-96  host/b1.dmz-int.example.org@MYEXAMPLE.ORG
  7  arcfour-hmac-md5         ldap/b1.dmz-int.example.org@MYEXAMPLE.ORG
  7  aes128-cts-hmac-sha1-96  ldap/b1.dmz-int.example.org@MYEXAMPLE.ORG
  7  aes256-cts-hmac-sha1-96  ldap/b1.dmz-int.example.org@MYEXAMPLE.ORG
  7  arcfour-hmac-md5         ldap/ldap.dmz-int.example.org@MYEXAMPLE.ORG
  7  aes128-cts-hmac-sha1-96  ldap/ldap.dmz-int.example.org@MYEXAMPLE.ORG
  7  aes256-cts-hmac-sha1-96  ldap/ldap.dmz-int.example.org@MYEXAMPLE.ORG
  7  arcfour-hmac-md5         ldap/ldap.unimore.it@MYEXAMPLE.ORG
  7  aes128-cts-hmac-sha1-96  ldap/ldap.unimore.it@MYEXAMPLE.ORG
  7  aes256-cts-hmac-sha1-96  ldap/ldap.unimore.it@MYEXAMPLE.ORG

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: user@MYEXAMPLE.ORG
SASL SSF: 56
SASL data security layer installed.
[...]
$ ldapsearch -ZZ -h ldap2.myexample.org 'uid=test'
SASL/GSSAPI authentication started
SASL username: user@MYEXAMPLE.ORG
SASL SSF: 56
SASL data security layer installed.
[...]
$ klist
Credentials cache: FILE:/tmp/krb5cc_1000
    Principal: user@MYEXAMPLE.ORG

Issued                Expires               Principal
Sep  6 09:03:35 2016  Sep  6 19:03:32 2016  krbtgt/MYEXAMPLE.ORG@MYEXAMPLE.ORG
Sep  6 09:03:39 2016  Sep  6 19:03:32 2016  ldap/b1.dmz-int.example.org@MYEXAMPLE.ORG

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/ldap.dmz-int.example.org@DMZ-INT.EXAMPLE.ORG) 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/ldap.dmz-int.example.org@DMZ-INT.EXAMPLE.ORG) 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/ldap.dmz-int.example.org@DMZ-INT.EXAMPLE.ORG principal and not ldap/ldap.dmz-int.example.org@MYEXAMPLE.ORG?

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

Can you post your proxy config? – GregL Sep 06 '16 at 17:07 — GregL, Sep 06 '16 at 17:07

score 3 · Answer 1 · answered Sep 07 '16 at 03:46

3

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.

answered Sep 07 '16 at 03:46

84104

12,905
6
45
76

we are quite close! But now it complains about the krbtgt: `ldapwhoami -ZZ -h ldap.unimore.it SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Miscellaneous failure (see text (Server (krbtgt/DMZ-INT.UNIMO.IT@UNIMORE.IT) unknown)` – 473183469 Sep 07 '16 at 06:29
Looks like a cross-realm failure. You seem to have a ticket for principal@UNIMORE.IT and the client you're using thinks the service/server you're trying to reach belongs to a different realm, i.e. DMZ-INT.UNIMO.IT. You'll either want to setup the missing cross-realm principal krbtgt/DMZ-INT.UNIMO.IT@UNIMORE.IT or map, via dns or `[domain_realm]`, the server into UNIMORE.IT. – 84104 Sep 07 '16 at 17:49

SASL auth to LDAP behind HAPROXY with name mismatches

1 Answers1