samba - Apr 2016 - Cannot browse mode 0700 directories from Windows with security=ads

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]

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.

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.

Ian Collier.

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.
>

On Fri, Apr 15, 2016 at 11:43:03PM +0100, Rowland penny
wrote:
> 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.
nslcd is running, in fact.  However, the AD server does not have uidNumber
and gidNumber attributes for the users in question.  Maybe this is part
of the problem?

I'm confused as to how it is so nearly working at the moment, however.
There must be some translation going on between the Windows users who
log in and the Unix file permissions.  Indeed, "wbinfo -S" can give me
the Unix uid of a Windows user.

The problem we have is that Unix group permissions are not being respected.
I think that "force group = +groupname" goes most of the way to remedy
this, but it's a hack.  But again, why does that work if the Unix groups
are unknown to Samba?

Advice from elsewhere was to use "username map script = /bin/echo".
Could you explain what that actually does?  As noted in the beginning,
this does actually solve the group access problem but now forbids
people from accessing private files that they own.
> 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'
That is a *really big* downside, to be honest.  The reason for using
security=ads is so that our Windows users can use their existing
credentials to access the service.  Also, our passwd file contains
over a thousand users.  The majority of them won't use Samba, but...
which ones?

Ian Collier.