On Wed, Mar 08, 2017 at 04:28:05PM +0100, [email protected] wrote: > 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?
I'm sorry, but I'm not aware of any switches to enable some debugging in the SASL library. But I'm wondering if NAT_IP is a placeholder for the IP address. This cannot work. The SASL bind needs the real fully qualified name of the LDAP server, i.e. the name which was used to register the LDAP server with the KDC or an alias name if alias names are configured for the LDAP server in the KDC. Without the name it is not possible to get a Kerberos service ticket for the LDAP server. If you cannot use the real name because the corresponding IP address is not properly routed in the NATed environment I would suggest to add an alias in the KDC with a name which resolves to NAT_IP. HTH bye, Sumit > > > 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] _______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
