On Sun, May 28, 2017 at 1:38 AM, Rowland Penny via samba
On Sat, 27 May 2017 21:45:29 -0700
Steve Dainard via samba <samba(a)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)
> 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
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.
> To unsubscribe from this list go to the following URL and read the
> instructions: https://lists.samba.org/mailman/options/samba