On Sun, May 28, 2017 at 1:38 AM, Rowland Penny via samba samba@lists.samba.org wrote:
On Sat, 27 May 2017 21:45:29 -0700 Steve Dainard via samba samba@lists.samba.org wrote:
I'm running samba 4.4.4 on el7. I'm attempting to provide a share auth by Kerberos or for non-kerberos hosts auth by password on Linux or Windows (7) clients.
We have uid/gid/group memberships in AD and typically configure Linux hosts with a kerberos/sssd/ldap configuration which uses attributes from AD, but are not joined to domain.
You have 'security = ADS' in smb.conf and from 'man smb.conf'
SECURITY = ADS
In this mode, Samba will act as a domain member in an ADS realm. To operate in this mode, the machine running Samba will need to have Kerberos installed and configured and Samba will need to be joined to the ADS realm using the net utility.
Right, the host is joined to the domain, via adcli, rather than net.
I need to be able to automate the domain join with salt stack, so I'm stuck using adcli to join the machine as it has a plain-text password option, I then push sssd.conf, /etc/krb5.conf, and /etc/samba/smb.conf to the samba host.
Never heard of 'salt' until now and I don't really understand what it brings to the party ?
In context, makes sure people understand I've used adcli, rather than using the net command and must continue to do so, so that I can automate joining samba servers to the domain.
From what you have posted the default realm is 'AD.LOCALDOMAIN.COM' but your clients are in the dns domain 'dhcp.localdomain.com', I am no kerberos expert, but this wouldn't work with a Samba AD DC.
Right, the server is configured as a member server, not a domain controller. Also this doesn't seem to be a 'kerberos' issue, as my Linux clients who auth via kerberos are able to properly authenticate on a protected share without password prompts, and I see a cifs kerberos ticket on my Linux client. The Linux clients also have fqdn's in the same domain as the samba server, not the ad domain. So it appears it might be Windows implementation that has an issue with clients having a different domain name than the servers. That doesn't explain user/password authentication not working on the Windows client, I'm definitely missing something on this side, I'm thinking NTLM may not work with encrypted passwords although I thought this didn't apply to newer versions of samba. This seems related https://social.technet.microsoft.com/Forums/en-US/8249ad4c-69aa-41ba-8863-8e... I'll give it a run when I'm back in the office.
It sounds like you could replace the salt machine with a Samba AD DC and then you wouldn't have all the problems you are having, but I understand that you want to use salt. The only problem I can see, you have set up smb.conf to connect to an AD DC.
Salt is only for configuration management, it doesn't matter too much in this context. As mentioned, I'm joining the samba server as a member of the domain, not using it as a domain controller, and using it as a DC is not an option.
When I attempt to connect from a domain joined Windows client I get prompted for credentials, and domain credentials do not work. It seems like the id of the user isn't passed through or looked up correctly after Kerberos auth, and the user is labelled as a guest user. Guest users are mapped to bad user in samba config. Here's a bit of logging when the Windows client tries to access a share: https://pastebin.com/pbEqj9ZR
Actually unknown users (i.e. Bad User) are mapped to the Unix user 'nobody', they probably wouldn't be if you were using an AD DC with the windows clients joined to the domain.
Whichever user a bad user is being mapped to, I believe this is at the root of the problem with the Windows client. I think Kerberos is working for the initial auth/handshake, but somehow user id doesn't carry through to match actual permissions on the share. But that this does work for a Linux client machine/user is what is confounding.
The other problem you have here is, sssd has nothing to do with Samba, it is not Samba package, you may get better help from the sssd-users mailing list, mainly because, if you are using sssd, it is this that is doing your authentication.
Yes, I've sent this mail to both lists.
Rowland
-- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
sssd-users@lists.fedorahosted.org
-
Steve Dainard