SASL-авторизация для LDAP за HAPROXY с несоответствием имен

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
4
задан 7 September 2016 в 09:27
1 ответ

Вам понадобится ignore_acceptor_hostname = true либо в [libdefaults] , либо в соответствующем подразделе [appdefaults] .

ignore_acceptor_hostname
При принятии контекстов безопасности GSSAPI или krb5 для участников службы на основе хоста игнорируйте любое имя хоста, передаваемое вызывающим приложением, и разрешайте клиентам аутентифицироваться для любого субъекта-службы в ключевой таблице, совпадающей с именем службы и именем области (если дано). Этот вариант может улучшить административную гибкость серверных приложений на многосетевых хостах, но может поставить под угрозу безопасность сред виртуального хостинга.
Значение по умолчанию неверно. Новое в версии 1.10.

2
ответ дан 3 December 2019 в 03:55

Теги

Похожие вопросы