attachment
smb.conf

attachment
sssd.conf

SSSD currently support Kerberos authentication (NTLM might become available sometime but not in the nead future).

For Kerberos a client has to ask the AD DC for a service ticket for a given service. For file share access the service principal typical looks like cifs/fully.qualified.domain.name@AD.REALM. The fully.qualified.domain.name is the host name you enter when connection to the share. The client will then add the 'cifs/ prefix and the realm and ask the AD DC for a ticket. The AD DC search the servicePrincipalName attributes for a match. If no matching principal is found the client will fall back to NTLM authentication.

It looks like Windows 7 does not use the alias name you entered directly but canonicalize it first and then asks the DC. You can check this by calling calling 'klist' at the command prompt of the Windows 7 client after connecting to the share. In the output you should see a cifs/... principal with the actual host name and not with the alias name. It looks like this behavior causes issues with the Internet Explorer see e.g. https://social.technet.microsoft.com/Forums/windows/en-US/f649df36-a61b-4d23-a0c6-818dc2eff923/ie8-on-windows-7-kerberos-cname-bug?forum=w7itpronetworking . May guess because of this the behavior was changed in newer Windows releases. Unfortunately I have no idea if this configurable on the Windows side.

You can try to add servicePrincipalNames which contains the alias names to the host object of the SSSD client as well. This should allow the client to request for tickets with the alias name as well. On the SSSD client you should add matching entries to the keytab used by samba as well. 'net ads keytab add ...' can be used for this. Please make a copy of the existing keytab before so that you can recover it if anything goes wrong.

HTH

bye,
Sumit

Hi, I was able to solve it on the linux side using your suggestions, adding the principals with net ads keytab add, and then doing the same with stspn -a on the domain controller.

What I am perplexed about is that I wasn't able to get any understanding of what was happening looking at both sssd and samba logs with level 10. There is no "kerberos authentication failed, falling back to ntlm" anywhere, but it just logs the failing ntlm authentication. As sssd is managing the kerberos settings (as opposed to krb5.conf in /etc), I would expect sssd to be logging kerberos trace somewhere (maybe krb5_child.log?) but that is empty as well. Or should I refer to KRB5_TRACE variable? Also why is sssd falling back to ntlm if it does not support it?

Thanks for your help

You cannot see anything in the logs because the decisions are done on the Windows client. The client will ask the DC for a service ticket, if this fails it will fall back to NTLM authentication and only at this point it will start a connection to the Linux fileserver. So the only message you can see is the one from the description saying that NTLMSSP authentication is used by the client.

cc: => sbose

Fields changed

resolution: => invalid
status: new => closed

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/4261

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.