5

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
Improve this question
2
  • Can you post your proxy config? Commented Sep 6, 2016 at 17:07
  • sure! I did right now. Commented Sep 7, 2016 at 6:28

1 Answer 1

Reset to default
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.

Improve this answer
2
  • 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/[email protected]) unknown) Commented Sep 7, 2016 at 6:29
  • Looks like a cross-realm failure. You seem to have a ticket for [email protected] 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/[email protected] or map, via dns or [domain_realm], the server into UNIMORE.IT. Commented Sep 7, 2016 at 17:49

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.