Hi Sumit,

we are using the des3 stuff because of legacy systems. As we use heimdal (not MIT), there is no kvno. But what I can tell so far that the whole Kerberos infrastructure is working thru NAT as expected. I can get a ticket on the host itself. If I manually enable GSSAPI for sshd, I can successfully log on the server using Kerberos. So the NAT issue seems not to be related to Kerberos, with my limited knowledge of sssd internals I assume that it is a problem with SASL using GSSAPI as its bind mechanism. I suspect that e.g. sshd is using GSSAPI directly and thus the problem does not appear there. Is there any way to either debug SASL itself or to configure it in a way to respect the NAT environment?


Cheers,
Steffen


On Mon, Mar 06, 2017 at 04:28:04PM +0100, knauf@patronas.com wrote:
Hello,

thanks for your response, but i get the same error.......

/etc/openldap/ldap.conf:
 
-----------------------------------
TLS_CACERT     PATH
URI ldap://NAT_IP
BASE ou=ldap,dc=patronas,dc=de
TLS_REQCERT allow
SASL_MECH GSSAPI
SASL_NOCANON on
-----------------------------------


relevant part of /etc/krb5.conf

-----------------------------------
[libdefaults]
 dns_canonicalize_hostname = false
 rdns = false
 forwardable = true
 default_realm = PATRONAS.DE
      default_etypes = des3-cbc-sha1
      default_etypes_des = des-cbc-crc
      default_tgs_enctypes = des3-cbc-sha1
      default_tkt_enctypes = des3-cbc-sha1

 dns_lookup_realm = false
 dns_lookup_kdc = false
-----------------------------------

ldapsearch fails, too.
The debug Output of ldapsearch:

-----------------------------------

ldap_create
ldap_sasl_interactive_bind: user selected: GSSAPI
ldap_int_sasl_bind: GSSAPI
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP NAT_IP:389
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying NAT_IP:389
ldap_pvt_connect: fd: 3 tm: -1 async: 0
attempting to connect:
connect success
ldap_int_sasl_open: host=NAT_IP
SASL/GSSAPI authentication started
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 (No
credentials found with supported encryption types (filename: /tmp/krb5cc_0))
But now there is a different error than the original 'Server not found
in Kerberos database'.

Your krb5.conf only allows des3-cbc-sha1. Is there a reason for this?

Please check with 'klist -e /tmp/krb5cc_0' if the credential cache has
des3-cdc-sha1 keys or not.

You can simulate the Kerberos steps SSSD does by calling:

    kinit -k

and
On 06.03.2017 18:08, Sumit Bose wrote:
    kvno ldap/REAL_HOSTNAME@KERBEROS.REALM

To get more details you can use

  
    KRB5_TRACE=/dev/stdout kvno ldap/REAL_HOSTNAME@KERBEROS.REALM


HTH

bye,
Sumit

-----------------------------------



--

Steffen Knauf

PATRONAS

PATRONAS Financial Systems GmbH
Schnewlinstr. 4
79098 Freiburg

fon +49 (0)761 400688-0
fax +49 (0)761 400688-50

knauf@patronas.com
http://www.patronas.com

commercial register: Amtsgericht Freiburg, HRB 7212
executive board: Heribert Steuer, Carsten Osswald

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.