On Tue, Mar 07, 2017 at 06:03:34PM +0100, [email protected] wrote: > 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
With heimdal you can try kgetcred instead of kvno. > 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? According to the latest error message '(No credentials found with supported encryption types (filename: /tmp/krb5cc_0))' there is no issue with NAT anymore after disabling the canonicalization. Have you checked the encryption types of the TGT in the credential cache with 'klist -e'? Can you remove the encryption type related options from krb5.conf for testing to see if it works when the encryption types are not restricted? HTH bye, Sumit > > > 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] _______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
