Do you have cyrus-sasl2-gssapi installed?

Hi,

can you try to check if SASL/GSSAPI works independently of SSSD?. For this please call

kinit -k  'MACY$@DOMAIN'
ldapsearch -Y GSSAPI  -H ldap://ad.dc.dns.name -b 'dc=domain' -s base

bye,
Sumit

Hi abbra and sbose,

I don't have cyrus-sasl2-gssapi installed.

I have tried

kinit -k  'MACY$@DOMAIN'
ldapsearch -Y GSSAPI  -H ldap://ad.dc.dns.name -b 'dc=domain' -s base

but I get

kinit: krb5_get_init_creds: Already tried ENC-TS-info, looping

and

ldap_sasl_interactive_bind_s: Unknown authentication method (-6)
        additional info: SASL(-4): no mechanism available: No worthy mechs found

What can be the problem? Does my samba4 server not understand SASL?

Best regards,
Ronny

Please install cyrus-sasl2-gssapi package.

ldapsearch and SSSD are using CyrusSASL for SASL implementation. If you have no actual SASL plugin to support a specific authentication method, it will not be available to the application.

Samba, on its side, does have own SASL implementation and it doesn't need CyrusSASL framework.

@abbra

Thanks, by installing the cyrus-sasl-gssapi-2.1.27 package, the above error disappeared.

Now though, I am getting a different error:

(Tue Jan 22 13:31:27 2019) [sssd[be[domain]]] [sasl_bind_send] (0x0100): Executing sasl bind mech: gssapi, user: MACY$
(Tue Jan 22 13:31:28 2019) [sssd[be[domain]]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-2)[Local error]
(Tue Jan 22 13:31:28 2019) [sssd[be[domain]]] [sasl_bind_send] (0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI Error:  Miscellaneous failure (see text).DE (Server (ldap/adserver@DOMAIN) unknow)]
(Tue Jan 22 13:31:28 2019) [sssd[be[domain]]] [child_sig_handler] (0x1000): Waiting for child [64955].
(Tue Jan 22 13:31:28 2019) [sssd[be[domain]]] [child_sig_handler] (0x0100): child [64955] finished successfully.
(Tue Jan 22 13:31:28 2019) [sssd[be[domain]] [fo_set_port_status] (0x0100): Marking port 389 of server 'adserver' as 'not working'

Do you know what's wrong here, too?

Best regards,
Ronny

You seem to have applied too much of filtering when removing your production details so I will have to guess:

(Tue Jan 22 13:31:28 2019) [sssd[be[domain]]] [sasl_bind_send] (0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI Error: Miscellaneous failure (see text).DE (Server (ldap/adserver@DOMAIN) unknow)]

It is a response from your KDC (Samba DC?) saying that it doesn't know Kerberos principal ldap/adserver. If your 'adserver' is not a fully-qualified domain name, that's might be a problem.

Since in the sssd.conf sample you provided there is no specification for AD DC (ad_server option is missing), I guess SSSD will try to do a discovery based on DNS SRV records. If your DNS SRV record for ldap has non-fully-qualified domain name, that might be the problem.

See https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html#troubleshooting-general-sssd-be-problems for many possible issues but I think your DNS SRV record not being in sync with the name of the server as Samba DC thinks it should be named (in fqdn) is a real issue.

Again, logs you provide seem to be edited too much.

Hi @abbra

thanks for your information.

Actually, I am using a fully qualified domain name for the samba DC servers and DNS SRV records should be fine. I just removed it in the log output.
I don't want to set set the ad_server option statically, rather than I want auto-discovery of the Samba DC's.

Any other ideas what could be wrong than the SRV records?

Best regards,
Ronny

Ok, can you please show more details about your Samba AD setup?

I'd like to get following output. Let's say addc is a computer name ('addc$'), not a fully-qualified one. Please provide an output of

samba-tool computer show addc
samba-tool spn list addc\$

Hopefully, it will produce something reasonable -- I'm not sure if version with dollar sign will work or not (I don't have a working Samba AD DC right now to check).

Ok,

samba-tool computer show addc

seems not to work in FreeBSD samba, since the command samba-tool computer is not found.

samba-tool spn list addc$

produces:

[root@addc ~]# samba-tool spn list addc$
addc$
User CN=addc,OU=Domain Controllers,DC=domain,DC=de has the following servicePrincipalName:
         HOST/addc
         HOST/addc.domain
         GC/addc.domain/domain
         E3514235-4B06-11D1-AB04-00C04FC2DCD2/e28b80f1-b6a3-4c99-ac8a-13d8be8393d5/domain
         HOST/addc.domain/WORKGROUP
         ldap/addc.domain/WORKGROUP
         ldap/addc.domain
         HOST/addc.domain/domain
         ldap/addc.domain/domain
         ldap/e28b80f1-b6a3-4c99-ac8a-13d8be8393d5._msdcs.domain
         ldap/addc
         RestrictedKrbHost/addc
         RestrictedKrbHost/addc.domain
         ldap/addc.domain/DomainDnsZones.domain
         ldap/addc.domain/ForestDnsZones.domain

Does this help?

Best regards,
Ronny

ok, so ldap/addc.domain SPN is there which means Samba AD DC should have issued you a ticket to that one.

I suspect you need to debug your kerberos infrastructure independently of SSSD. What Kerberos library do you use on FreeBSD side? Is it Heimdal or MIT?

For Heimdal, https://www.h5l.org/manual/HEAD/info/heimdal/Debugging-Kerberos-problems.html describes how to enable tracing.

For MIT, set KRB5_TRACE=/dev/stderr in the environment before executing 'kinit' or 'kvno' commands and then do:

kinit -k -t /etc/krb5.sssd.keytab 'MACY$'
kvno ldap/addc.domain@DOMAIN

In either case, there will be some tracing information available showing which KDC was contacted and what tickets were obtained and so on. If you can share that output (replacing actual host names with something like addc.domain above and realm with DOMAIN should be fine), we can see where it might fail.

Hi @abbra,

I am using the heimdal Kerberos library.

I have tried to enable tracing to both syslog and file, but don't get any output when running the kinit and kvno commands.

My /etc/krb5.conf looks like:

...
[logging]
        libkrb5 = 0-/SYSLOG:INFO:AUTH
...

But I don't get any kerberos lib logging to /var/log/auth.log.

Any ideas?

Best regards,
Ronny

Sorry, no ideas.

From SSSD point of view, as soon as you get non-failing result from kvno ldap/addc.domain@DOMAIN, it should start working. This is not really an SSSD problem.

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/4908

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.