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, [email protected] 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/[email protected] > > To get more details you can use > > > KRB5_TRACE=/dev/stdout kvno ldap/[email protected] > > > 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 [email protected] <mailto:[email protected]> 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.
_______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
