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, knauf(a)patronas.com 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