[Samba] Cannot browse mode 0700 directories from Windows with security=ads
rpenny at samba.org
Fri Apr 15 22:43:03 UTC 2016
On 15/04/16 22:09, Ian Collier wrote:
> rpenny at samba.org writes:
>> If your computer is joined to an AD domain, is running Samba with 'security
>> = ADS' and winbindd is running, the line in /etc/nsswitch should be 'passwd:
>> files winbind' (the group line should be 'group: files winbind')
>> Your users should not be in /etc/passwd, they should only be in AD (as
>> should your groups)
> Sorry but we certainly won't be doing this. The group memberships
> we want to obey are Unix groups, not AD groups. We have whole labs
> full of machines running sssd and we're not about to make Winbind the
> primary authentication system on those machines. We're sharing Unix
> files owned by Unix users, *but* the people accessing these files are
> generally on Windows so we want the AD authentication they already have
> on their client Windows system to allow them into the Samba server.
> This was all working until earlier this week.
>>> OK I will look at that in detail later, but it mentions putting winbind
>>> in nsswitch.conf which I don't think we want to do.
>> Oh you do, you really do, If not, either run 'sssd' (which will do what
>> running winbind does) and replace 'ldap' in /etc/nsswitch.conf with 'sss',
>> or turn Samba off.
> "Turn Samba off" is not helpful, and the only reason why we started Winbind
> on this server this week is that the Badlock patches broke our previous
> Winbind-less configuration and the answer from Samba to this appears to
> be that running Winbind is the only way to fix this in the short term.
Sorry if you thought what I said was not helpful and I can understand
your frustration, it worked, you upgraded and now it doesn't.
Lets see if I can describe how it is supposed to work:
You run smbd, this gives you fileserving capabilities but you need
users & groups. The users & groups in /etc/passwd and /etc/group are
unknown to Samba, so you need to make them known to Samba. You can do
this in few ways, but when you use 'security = ADS' , it is usually done
by getting them from AD. You can do this with sssd or by running
winbind, or by using nlscd. The first two ways can be done without
modifying AD, but the last would require you to add uidNumber &
Now we come to the way you had it working, you seemed to be running a
hybrid standalone/domain member, but it worked for you before.
> I am certainly willing to consider starting up sssd if you think it
> will help - but it's done this way because we have a conflict between
> the Kerberos realm that sssd wants and the one that Windows AD wants.
> But as I say, "getent" works perfectly well to retrieve the password
> and group files, so I'm not sure what benefit sssd would bring.
No I wouldn't bother with sssd if you were not using it before, I
mistakenly thought you were.
> What we need is a translation between the Unix usernames on the server
> and the (identical) usernames in the Windows AD domain, which works so
> that your Unix group memberships will allow you to access files that
> have group permissions. Certain online resources gave me the impression
> that "username map script = /bin/echo" does this; but that fixes one
> problem and introduces another.
I think I see what you are doing here, you have groups on the Unix
machine that do not exist in AD and you have users that are members of
these groups and are in /etc/passwd and AD. The users have the same
password everywhere. I think the way it worked before is that because
you didn't run winbind, the AD users connected to the machine, and
because the users were in /etc/passwd, they connected. Something that
was tightened up in the CVE updates is now no longer allowing this.
Have you tried setting up the machine as a standalone server instead ?
commenting the 'security' line in smb.conf will do this. The only
downside to this would that you would have to keep the passwords in sync
and add all the users to Samba on the standalone machine with 'smbpasswd
Perhaps you could try this in a VM first.
> Ian Collier.
More information about the samba