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

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.

On 18/04/16 17:48, Ian Collier wrote:
> 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?
nslcd relies on uidNumber & gidNumber attributes, so if they don't 
exist, as far as Unix is concerned the user or group doesn't exist.
>
> 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.
Can you give us an example of one of these Unix uids
>
> 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?
Problem might be that the GID the group is getting from somewhere isn't 
the one that is expected i.e. if the group exists in /etc/group and has 
the gid '1234' and the group in AD is being given '5678', then
the group
in AD isn't the same group as the one in /etc/group, even if they have 
the same name.
> 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.
What this seems to do, is to use the groups in /etc/group rather than 
AD, I have never used it myself, so don't know if it is a good idea or 
not. I think your problem with user access is down to the same problem 
as the group one above, your users in AD are being given a different uid 
to the users in /etc/passwd
>> 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?
You really only need to use Samba for windows users, Unix users can just 
be created in /etc/passwd on the Unix machine, but as you say, which 
need to be in /etc/passwd and which ones need to be in AD ?

Normal practise with an AD domain is to store all users and groups in 
AD, then give the users that actually need to log into the machine, all 
the Unix attributes and the windows ones just a uidNumber, you would 
also need to give Domain Users a gidNumber. You could then use nlscd, 
sssd or winbind to make the users known to the Unix OS.

The bottom line is that all users & groups need to be know to the Unix 
OS, i.e. 'getent passwd auser' needs to show the info for
'auser':

auser:*:11107:10513:A User:/home/auser:/bin/bash

And 'getent group Domain\ Users' should also show the info for the
group:

domain users:x:10513:

I know this doesn't really help with your problem, it worked before the 
update, but didn't after. Have you tried adding ' ldap server require 
strong auth =  no' to the global part of smb.conf ?, this seems to have 
worked for some people.

Rowland

>
> Ian Collier.
>

On Mon, Apr 18, 2016 at 06:56:48PM +0100, Rowland penny
wrote:
> >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?
> nslcd relies on uidNumber & gidNumber attributes, so if they don't
exist, as
> far as Unix is concerned the user or group doesn't exist.
The LDAP server that nslcd consults is our Unix auth server, not the
Windows AD.  This does have uid and group numbers.
> >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.
> Can you give us an example of one of these Unix uids
It goes like this...

 $ egrep jdoe /etc/passwd
 [no reply]
 $ getent passwd jdoe
 jdoe:*:10282:1013:John Doe:/users/jdoe:/bin/bash
 $ wbinfo -n jdoe
 S-1-5-21-1124797105-2089471174-1157203260-4073 SID_USER (1)
 $ wbinfo -s S-1-5-21-1124797105-2089471174-1157203260-4073
 DOM\jdoe 1
 $ wbinfo -S S-1-5-21-1124797105-2089471174-1157203260-4073
 10282

As an aside, jdoe can't actually log into the server because for logins
it's only set up with passwords in the local /etc/shadow file.  But jdoe
does obviously have a password in the Windows domain and Samba is allowing
jdoe to connect using his Windows AD credentials.  As far as the CentOS
server is concerned, the accounts (although they can't log in) exist and
can own files, etc.  All is working correctly on that side.
> >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?
> 
> Problem might be that the GID the group is getting from somewhere isn't
the
> one that is expected i.e. if the group exists in /etc/group and has the gid
> '1234' and the group in AD is being given '5678', then the
group in AD isn't
> the same group as the one in /etc/group, even if they have the same name.
The group doesn't exist at all in AD.  All group information is coming
from the Unix LDAP server.  But still "force group =" works.  I
understand
that without this, Samba is trying to use AD groups and ignoring the
Unix ones (although that's not what it did before we started Winbind),
and that's what the following is meant to solve...
> >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.
> What this seems to do, is to use the groups in /etc/group rather than AD, I
> have never used it myself, so don't know if it is a good idea or not. I
> think your problem with user access is down to the same problem as the
group
> one above, your users in AD are being given a different uid to the users in
> /etc/passwd
Odd then that it works for groups but not for the uid itself.
What the documentation seems to imply is that

 - this is equivalent to a map file containing "X = X" for all X
 - the map is used, after ADS has authenticated a user, to translate
   the AD username into the Unix username that should be used for this user.

That seems to be what we want, but it's not working for private files
owned by the user on a Windows client.  (It works fine if the client
is GNU/Linux using either smbclient or mount.cifs.)
> I know this doesn't really help with your problem, it worked before the
> update, but didn't after. Have you tried adding ' ldap server
require strong
> auth =  no' to the global part of smb.conf ?, this seems to have worked
for
> some people.
I can try that, but Samba isn't acting as a LDAP server here as far as I
know.

Ian Collier.