[Samba] Cannot browse mode 0700 directories from Windows with security=ads

[Rowland penny]

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.
> [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820981]

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 & 
gidNumber attributes.

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 
-a user'

Perhaps you could try this in a VM first.

Rowland



>
> Ian Collier.
>