[Samba] Samba 4 permissions error

[Jason Voorhees]

Hello guys.

I have a Zentyal 4.2 server which runs Samba 4.3.5 and ACLs for every
share. It's currently working fine, no isssues, everyone can access
their folders without problems.

I've built a Samba 4.3.5 server in a different host which is not a
Zentyal server. I've configured this 2nd server as DC. Once a day I
run a script to synchronize all shares from my Zentyal to this Samba
4.3.5 server using rsync -aAHS.

I can see that all ACLs and permissions are correctly replicated to
the destination server but I'm unable to access any shares there.

When using a username for testing, I'm able to access a share on the
origin server but I can't do it in the destination server. However, if
I login with this user at the OS Linux (sudo su - username) I can
access the UNIX directory without issues.

It's strange how UNIX ACLs and permissions allow this username to
access a certain directory but Samba doesn't even if the configuration
of this share is exactly the same in both the origin and destination
Samba server.

This is a portion of the log I see when my username tries to access a
share on the destiation server:

[2016/04/25 10:42:33.861169, 3] ../source3/smbd/process.c:1490(switch_message)
switch message SMBtrans2 (pid 10685) conn 0x55dc388d81b0
[2016/04/25 10:42:33.861237, 3]
../source3/smbd/service.c:198(set_current_service)
chdir (/home/samba/shares/Central) failed, reason: Permission denied
[2016/04/25 10:42:33.861279, 3] ../source3/smbd/error.c:82(error_packet_set)
NT error packet at ../source3/smbd/process.c(1609) cmd=50
(SMBtrans2) NT_STATUS_ACCESS_DENIED
[2016/04/25 10:42:37.766316, 3] ../source3/smbd/process.c:1880(process_smb)


OK, I know I haven't provided any extra info about my Samba
configuration files or any other useful information. But as there's a
lot of info I could share with all of you I'd like to know which info
you might need to troubleshoot this.

I hope someone can point me to some solution or procedure for fixing
this problem.

Thanks in advance

--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba

[Jason Voorhees]

Hello guys, any idea, someone? :(

[Rowland penny]

OK, you have two DCs, on one, your user can access a share, you
basically copy the shares to another DC (with all the same permissions
etc) and your user cannot access the share on the second DC.

How is AD set up ? are you using uidNumber & gidNumber attributes (you
will have added them manually) or are you using the xidNumbers created
automatically by Samba4.

If you have modified the smb.conf on the second DC, can you post this.
Can you post the smb.conf from your zential machine.

Rowland

[Jason Voorhees]

> OK, you have two DCs, on one, your user can access a share, you basically
> copy the shares to another DC (with all the same permissions etc) and your
> user cannot access the share on the second DC.
>
> How is AD set up ? are you using uidNumber & gidNumber attributes (you will
> have added them manually) or are you using the xidNumbers created
> automatically by Samba4.

I'm not pretty sure about the difference, but I believe it's the 2nd
alternative. I guess you could check it from my configuration shown
lines below.

>
> If you have modified the smb.conf on the second DC, can you post this.
> Can you post the smb.conf from your zential machine.

This is the content of my Zentyal's Samba configuration:

[global]
workgroup = agn
realm = REALM.COM.PE
netbios name = fileserver
server string = Linux Active Directory
server role = dc
server role check:inhibit = yes
server services = -dns -winbindd +winbind
server signing = auto
dsdb:schema update allowed = yes
drs:max object sync = 1200
idmap_ldb:use rfc2307 = yes
interfaces = lo,eth0,eth0:0,eth0:0
bind interfaces only = yes
log level = 3
log file = /var/log/samba/samba.log
max log size = 100000
include = /etc/samba/shares.conf
[netlogon]
path = /var/lib/samba/sysvol/agn.com.pe/scripts
browseable = no
read only = yes
[sysvol]
path = /var/lib/samba/sysvol
read only = no

Here the contents of /etc/samba/shares.conf:

[homes]
comment = Directorios de usuario
path = /home/%S
read only = no
browseable = no
create mask = 0611
directory mask = 0711
vfs objects = acl_xattr full_audit recycle
full_audit:success = connect opendir disconnect unlink mkdir rmdir
open rename
full_audit:failure = connect opendir disconnect unlink mkdir rmdir
open rename
recycle: directory_mode = 0700
recycle: inherit_nt_acl = Yes
recycle: excludedir = /tmp|/var/tmp
recycle: versions = Yes
recycle: keeptree = Yes
recycle: repository = RecycleBin

[agnofi]
comment = primer compartido
path = /home/samba/shares/agnofi
browseable = Yes
read only = No
force create mode = 0660
force directory mode = 0660
vfs objects = acl_xattr full_audit recycle
acl_xattr:ignore system acls = yes
full_audit:success = connect opendir disconnect unlink mkdir rmdir
open rename
full_audit:failure = connect opendir disconnect unlink mkdir rmdir
open rename
recycle: directory_mode = 0700
recycle: inherit_nt_acl = Yes
recycle: excludedir = /tmp|/var/tmp
recycle: versions = Yes
recycle: keeptree = Yes
recycle: repository = RecycleBin

There a lot of other additional shares but all of them have the same
configuration except for the path.

This is the configuration for my 2nd Samba DC:

[global]
workgroup = AGN
realm = realm.com.pe
netbios name = FILESERVERSJL
server role = active directory domain controller
log file = /var/log/samba.log
log level = 3
include = /etc/samba/shares.conf
server services = -dns -winbindd +winbind
server signing = auto
dsdb:schema update allowed = yes
drs:max object sync = 1200
idmap_ldb:use rfc2307 = yes
[netlogon]
path = /usr/local/samba-4.3.5/var/locks/sysvol/agn.com.pe/scripts
read only = No
[sysvol]
path = /usr/local/samba-4.3.5/var/locks/sysvol
read only = No

The contents of the /etc/samba/shares.conf is exactly the same as in
Zentyal's server because I copy this file using rsync.

Hope this helps. Thanks a lot for your help.

[Rowland penny]

No, I cannot tell what type of UIDs you are using from your smb.conf
files, but I can make an educated guess, you are probably using
'xidNumber' attributes stored in 'idmap.ldb'.

Now there is an interesting fact about xidNumber attributes, there is a
very good chance a user will get a different number on each DC and this
could well be your problem.
It is further compounded (in my opinion) by the fact that zentyal
appears to have turned of the better 'winbindd', in favour of the
'winbind' built into the 'samba' deamon.

If you want to be 100% certain that your users have the same UID on
every Unix machine, you need to use 'uidNumber' attributes. You also
need to use 'gidNumber' attributes for the groups.

Have a look here, please read the entire page:
https://wiki.samba.org/index.php/Idmap_config_ad

You will undoubtedly have further questions, but lets deal with them
once you have read the wiki page.

Rowland

[Mueller]

This is a normal behaviour if you are using several dcs. Users und groups do have another gid/uid on each server
until you fix it manually. This was a hard experiennce and work even fo rme which I suggest that this should be
the next goal for the samba 4 developers to solve and fix it in an easy way for the admins.
In my opinion, if I run several dcs in a domain this should be done between the dcs automatically without intervention.

Greetings
Daniel

EDV Daniel Müller

Leitung EDV
Tropenklinik Paul-Lechler-Krankenhaus
Paul-Lechler-Str. 24
72076 Tübingen
Tel.: 07071/206-463, Fax: 07071/206-499
eMail: mue...@tropenklinik.de
Internet: www.tropenklinik.de




-----Ursprüngliche Nachricht-----
Von: Rowland penny [mailto:rpe...@samba.org]
Gesendet: Mittwoch, 27. April 2016 21:17
An: sa...@lists.samba.org
Betreff: Re: [Samba] Samba 4 permissions error

[Rowland penny]

On 28/04/16 07:31, Mueller wrote:
> This is a normal behaviour if you are using several dcs. Users und groups do have another gid/uid on each server
> until you fix it manually. This was a hard experiennce and work even fo rme which I suggest that this should be
> the next goal for the samba 4 developers to solve and fix it in an easy way for the admins.
> In my opinion, if I run several dcs in a domain this should be done between the dcs automatically without intervention.
>
> Greetings
> Daniel
>
> EDV Daniel Müller
>
>
>

It isn't really a problem until you start copying files between DCs by
means other than Samba ones. It is very similar to using the 'rid'
backend i.e. Samba creates the UID , but with one big difference, the
'rid' backend calculates the UID from the users RID, this way, the user
should get the same UID wherever the 'rid' backend is used. With
idmap.ldb, the user just gets the next UID available i.e. first come,
first served.

In my opinion, the 'Well known SIDs' need to be allocated fixed IDs and
then winbind usage brought into line with the way a 'domain member' works.

[Rowland penny]

On 28/04/16 18:03, Jason Voorhees wrote:

> On Thu, Apr 28, 2016 at 2:13 AM, Rowland penny <rpe...@samba.org> wrote:
>> On 28/04/16 07:31, Mueller wrote:
>>> This is a normal behaviour if you are using several dcs. Users und groups
>>> do have another gid/uid on each server
>>> until you fix it manually. This was a hard experiennce and work even fo
>>> rme which I suggest that this should be
>>> the next goal for the samba 4 developers to solve and fix it in an easy
>>> way for the admins.
>>> In my opinion, if I run several dcs in a domain this should be done
>>> between the dcs automatically without intervention.
>>>
>>> Greetings
>>> Daniel
>>>
>>> EDV Daniel Müller
>>>
>>>
>>>
>> It isn't really a problem until you start copying files between DCs by means
>> other than Samba ones. It is very similar to using the 'rid' backend i.e.
>> Samba creates the UID , but with one big difference, the 'rid' backend
>> calculates the UID from the users RID, this way, the user should get the
>> same UID wherever the 'rid' backend is used. With idmap.ldb, the user just
>> gets the next UID available i.e. first come, first served.
>>
>> In my opinion, the 'Well known SIDs' need to be allocated fixed IDs and then
>> winbind usage brought into line with the way a 'domain member' works.
>>

> Now I can barely understand what the problem might be. I'll take a
> look at the wiki page to better understand what's wrong and how to fix
> it.
>
> I'll be back... Have a nice day :)

The fix is fairly simple, you need to copy idmap.ldb from the first DC
to the second and then keep them in sync.

[Jason Voorhees]

On Thu, Apr 28, 2016 at 2:13 AM, Rowland penny <rpe...@samba.org> wrote:

> On 28/04/16 07:31, Mueller wrote:
>>
>> This is a normal behaviour if you are using several dcs. Users und groups
>> do have another gid/uid on each server
>> until you fix it manually. This was a hard experiennce and work even fo
>> rme which I suggest that this should be
>> the next goal for the samba 4 developers to solve and fix it in an easy
>> way for the admins.
>> In my opinion, if I run several dcs in a domain this should be done
>> between the dcs automatically without intervention.
>>
>> Greetings
>> Daniel
>>
>> EDV Daniel Müller
>>
>>
>>
>
> It isn't really a problem until you start copying files between DCs by means
> other than Samba ones. It is very similar to using the 'rid' backend i.e.
> Samba creates the UID , but with one big difference, the 'rid' backend
> calculates the UID from the users RID, this way, the user should get the
> same UID wherever the 'rid' backend is used. With idmap.ldb, the user just
> gets the next UID available i.e. first come, first served.
>
> In my opinion, the 'Well known SIDs' need to be allocated fixed IDs and then
> winbind usage brought into line with the way a 'domain member' works.
>

Now I can barely understand what the problem might be. I'll take a
look at the wiki page to better understand what's wrong and how to fix
it.

I'll be back... Have a nice day :)

[Sketch]

On Thu, 28 Apr 2016, Jason Voorhees wrote:

> Now I can barely understand what the problem might be. I'll take a
> look at the wiki page to better understand what's wrong and how to fix
> it.

I believe this is the part you're looking for, which explains the problem
and gives the solution:

https://wiki.samba.org/index.php/Join_an_additional_Samba_DC_to_an_existing_Active_Directory#GID_mappings_of_built-in_groups

[Jason Voorhees]

Hey guys, thanks for your time.

Unfortunately, I've been busy so I wasn't able to test it again. Just
today I started to read, investigate and test all this stuff you
suggested me. I don't fully understand yet how uidNumbers and
xidNumbers work, all I know is that Zentyal is using the old winbind
daemon instead of the new winbindd. There are many concepts that I
don't know how they relate to each other, but this is what I've
tested:

1. On the 2nd. DC, I've remounted the filesystem with acl and xattr options.
2. On the 2nd. DC, I've disabled apparmor.
3. From the 1st DC, I've modified my rsync script to also include the
X option to synchronize extented attributes too.
4. I've backed up idmap.ldb from 1st. DC using "tdbbackup -s bak
idmap.ldb" and copied to 2nd. DC as idmap.ldb. Then I ran "samba-tool
ntacl sysvolreset" on the 2nd DC and restarted Samba.
5. I've copied the original idmap.ldb file from 1st to 2nd DC, ran
"samba-tool ntacl sysvolreset" on 2nd DC and restarted Samba again.
6. I've synchronized the sysvol share from 1st to 2nd DC using rsync
-aAHSX, ran "samba-tool ntacl sysvolreset" on 2nd DC and restarted
Samba again.


I've tried to access one of my shares on the 2nd DC but I always got
the same error "NT_STATUS_ACCESS_DENIED listing \*". So in the middle
of the night (02:00 am) and giving up just for today...

The only "strange" thing I notice is this:

If I connect to a certain share in the 1st DC I see a log like this:

127.0.0.1 (ipv4:127.0.0.1:55282) connect to service Central
initially as user AGN\cchavarrias (uid=2502, gid=2513) (pid 26854)

But on the 2nd DC the log look like this:

__1 (ipv6:::1:33880) connect to service Central initially as user
AGN\cchavarrias (uid=2502, gid=100) (pid 8708)

On the 1st DC, "cchavarria" user is using GID 2513 (domain users group
from Samba) but on the 2nd DC is using GID 100 (default group from
OS). If I run the "id" command on both DCs, the information is the
same:

On DC 1:
# id cchavarrias
uid=2502(cchavarrias) gid=2513(domain users) groups=2513(domain
users),2512(domain admins),3124(usuarios)

On DC 2:
# id cchavarrias
uid=2502(cchavarrias) gid=2513(domain users) groups=2513(domain
users),3124(usuarios),2512(domain admins)

I wonder if the fact that GID 100 is being used on the 2nd DC is
causing any problems due to ACLs not granted to group with GID 100.
However, cchavarrias user has full permissions through ACLs in both
DCs for every share.


P.S.: By using ldbsearch over idmap.ldb I noticed that xidNumber
attribute is the same for cchavarrias user in both, 1st and 2nd DC, so
I guess xidNumbers match correctly. Am I right?

[Rowland penny]

If you only connect windows machines to a Samba AD DC for
authentication, then you do not need to bother about 'xidNumber',
'uidNumber' and 'gidNumber' attributes, it is only when you want to
store any user data on the DC (or domain member) that you need to
consider these.

Samba uses various different ways of mapping windows users to Unix, but
the main two are 'rid' and 'ad' (note I am talking about using winbindd
here). On the DC, the 'rid' backend is different to using it on a domain
member, a DC uses 'xidNumber' attributes stored in idmap.ldb, these
'xidNumber' attributes seem to be allocated on a first come basis, hence
you can get different numbers on different DCs. Using the 'rid' backend
on a domain member maps RIDs to 'uidNumber' & 'gidNumber' using a
calculation, this way you will always get the same ID on different
computers.
Back to the DC, a few users and groups are always mapped to the same ID,
Administrator and 'Domain Users' for instance, using 'winbind' or
'winbindd' should make no difference to this, but using 'winbindd'
brings advantages over using 'winbind'.
If you use the 'ad' backend, you can 'fix' the ID numbers of users &
groups, but you may have to clear caches and/or remove 'xidNumber'
attributes from idmap.ldb

As there are differences between the way 'winbind' and 'winbindd' work,
I wouldn't use one on a DC and the other on a second DC, I would use the
same one on both DCs and I would probably use 'winbindd' on both.

Samba (partially because of the above) does not recommend using a DC as
a fileserver, but can if you so wish, it is your DC.

Rowland