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(a)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(a)KERBEROS.REALM
To get more details you can use
KRB5_TRACE=/dev/stdout kvno ldap/REAL_HOSTNAME(a)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(a)patronas.com <mailto: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.