On Mon, Mar 06, 2017 at 09:27:56AM +0100, knauf(a)patronas.com wrote: > Hello, > > I have a Problem to auth. the identity of a principal to a NAT'ed > Server via gssapi. > Our KDC/LDAP is externally available through a NAT_IP (and NAT_HOSTNAME) > > The Connection to the Server looks fine: > ------------------------------------------ > nc -v NAT_IP 389 > Ncat: Version 6.40 ( http://nmap.org/ncat ) > Ncat: Connected to NAT_IP:389. > ------------------------------------------ > > relevant part of: /etc/sssd/sssd.conf > ------------------------------------------ > [domain/XXXXX.XX] > > ldap_sasl_mech = gssapi > ldap_sasl_authid = host/FQDN_HOST > ldap_sasl_canonicalize = false > ldap_user_principal = userPrincipalName > ldap_krb5_keytab = /etc/krb5.keytab > ldap_krb5_init_creds = true > ldap_krb5_ticket_lifetime = 86400 > sudo_provider = ldap > access_provider = ldap > ldap_access_order = host > ------------------------------------------ > > > After restarting the sssd Daemon, i got the following Error Message > (sssd_DOMAIN.log): > > ------------------------------------------ > [sasl_bind_send] (0x0100): Executing sasl bind mech: gssapi, user: > host/FQDN_HOST > [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-2)[Local error] > [sasl_bind_send] (0x0080): Extended failure message: [SASL(-1): generic > failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide > more information (Server not found in Kerberos database)] > [sdap_cli_connect_recv] (0x0040): Unable to establish connection > [1432158225]: Authentication Failed > [_be_fo_set_port_status] (0x8000): Setting status: PORT_NOT_WORKING. > Called from: src/providers/ldap/sdap_async_connection.c: > sdap_cli_connect_recv: 2048 > [fo_set_port_status] (0x0100): Marking port 389 of server 'NAT_IP' as > 'not working' > [fo_set_port_status] (0x0400): Marking port 389 of duplicate server > 'NAT_IP' as 'not working > ------------------------------------------ > > After spending some time to this Problem, i could limit the Problem to a > DNS reverse lookup Problem during the gssapi authentication. It is in general recommended to disable reverse lookups for Kerberos/GSSAPI/SASL to avoid this kind of issues. On Fedora and RHEL it is disabled by default by setting: rdns = false

in /etc/krb5.conf and SASL_NOCANON on in /etc/openldap/ldap.conf. HTH bye, Sumit > > If i set the following entry into /etc/hosts all works fine, but this > Solution is not practicable for me: > > NAT_IP REAL_HOSTNAME > > > Perhaps you have some clues for me to solve this Problem? > > > Thanks & greets > > Steffen > _______________________________________________ > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org > To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org _______________________________________________ sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org

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))

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.

_______________________________________________ sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org

Hi Sumit, please ignore the second error message. I mixed different problems. Sorry for confusing........... After setting the following options: ------------------------------------ /etc/sssd/sssd.conf: ldap_sasl_canonicalize = false /etc/openldap/ldap.conf SASL_MECH GSSAPI SASL_NOCANON on [libdefaults] rdns = false ------------------------------------ ......i get the same error message: [sasl_bind_send] (0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server not found in Kerberos database)] [sdap_cli_connect_recv] (0x0040): Unable to establish connection [1432158225]: Authentication Failed [_be_fo_set_port_status] (0x8000): Setting status: PORT_NOT_WORKING. Called from: src/providers/ldap/sdap_async_connection.c: sdap_cli_connect_recv: 2048 [fo_set_port_status] (0x0100): Marking port 389 of server 'NAT_IP' as 'not working' [fo_set_port_status] (0x0400): Marking port 389 of duplicate server 'NAT_IP' as 'not working' Is there any way to either debug SASL itself or to configure it in a way to respect the NAT environment within sssd?