On Wed, Mar 08, 2017 at 04:28:05PM +0100, knauf(a)patronas.com 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, 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
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org