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? greets Steffen > 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 _______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
