[Samba] Samba4, idmap.ldb & ID_TYPE_BOTH
Davor Vusir
davortvusir at gmail.com
Fri Feb 20 14:27:17 MST 2015
Rowland Penny skrev den 2015-02-19 18:15:
> OK, there is a discussion over on samba-technical about nss_winbind
> and the question about Administrator being mapped to 0 was raised. Now
> I have always thought that it should, but in fairness, I decided to
> see what happens when it isn't, so I removed Administrator from
> idmap.ldb and restarted samba. Before restarting samba, I checked a
> few things, on the DC, getfacl returned this for /var/lib/samba/sysvol/
>
I've followed the thread with serious interest and I have until, some
time ago, thought that the this idmapping was a Sambas way of making
Linux and Samba (as an AD DC) become a domain controller "the
Microsoft/Windows way". With this I mean, when you promote a Windows
server to a domain controller, the server seize to exist and becomes the
Windows domain. Windows OS becomes a vessel for the the domain in some
sense.
The more I have been thinking about this I believe it is the wrong way.
I like it, but it is wrong. Perhaps not do-able.
On Ubuntu DOMAIN\Administrator is mapped to root and DOMAIN\Domain users
is mapped to users (100). But no other domain group or user is mapped to
a corresponding group or user. Why? Because there are no such users or
groups in Linux. I hope I'm wrong. The xidNumbers you list below is, to
me, a clever way to get the AD DC to function but belongs to the AD DC
and can not reach out of the it. Winbind on the AD DC in the 4.0 and 4.1
series can't read neither uid- and gidNumbers nor xidNumbers and winbind
on the file-/printserver can't read xidNumbers. There is a mismatch and
that's probably the main reason for the advice not to use the AD DC as a
combined AD DC and file-/printserver. xidNumbers are local to the AD DC.
Perhaps Samba, both as a AD DC and file-/printserver, should be looked
upon as a virtual guest where Linux OS is the virtual host. Where Samba
utilizes all the techniques that Linux offers.
> getfacl: Removing leading '/' from absolute path names
> # file: var/lib/samba/sysvol/
> # owner: root
> # group: 3000000
> user::rwx
> user:root:rwx
> user:3000000:rwx
> user:3000001:r-x
> user:3000002:rwx
> user:3000003:r-x
> group::rwx
> group:3000000:rwx
> group:3000001:r-x
> group:3000002:rwx
> group:3000003:r-x
> mask::rwx
> other::---
> default:user::rwx
> default:user:root:rwx
> default:user:3000000:rwx
> default:user:3000001:r-x
> default:user:3000002:rwx
> default:user:3000003:r-x
> default:group::---
> default:group:3000000:rwx
> default:group:3000001:r-x
> default:group:3000002:rwx
> default:group:3000003:r-x
> default:mask::rwx
> default:other::---
>
> And the settings as seen from a windows client:
>
> Share permissions: Everyone
>
> Security:
> root
> Authenticated Users
> Server Operators (EXAMPLE\Server Operators)
> SYSTEM
>
> After samba restarted, I went to sysvol permissions on a windows
> client as Administrator, but couldn't change anything, as the 'Add'
> button was greyed out, going to the 'share permissions' tab and adding
> Administrator with full permissions cured this.
>
> Once this was done, getfacl now returns:
>
> getfacl: Removing leading '/' from absolute path names
> # file: var/lib/samba/sysvol/
> # owner: EXAMPLE\134Administrator
> # group: 3000000
> user::rwx
> user:3000000:rwx S-1-5-32-544 Administrators group
> user:3000001:r-x S-1-5-32-549 Server Operators builtin group
> user:3000002:rwx S-1-5-18 Local System account
> user:3000003:r-x S-1-5-11 Authenticated Users group
> user:EXAMPLE\134Administrator:rwx
> group::rwx
> group:3000000:rwx
> group:3000001:r-x
> group:3000002:rwx
> group:3000003:r-x
> mask::rwx
> other::---
> default:user::rwx
> default:user:3000000:rwx
> default:user:3000001:r-x
> default:user:3000002:rwx
> default:user:3000003:r-x
> default:user:EXAMPLE\134Administrator:rwx
> default:group::---
> default:group:3000000:rwx
> default:group:3000001:r-x
> default:group:3000002:rwx
> default:group:3000003:r-x
> default:mask::rwx
> default:other::---
>
> 'root' had been replaced with 'EXAMPLE\134Administrator'
>
> Now this lead me to start thinking, why is a user also a group and
> vice-versa ?
>
> Checking idmap.ldb, I found that the 4 user/groups?? were all
> described as 'ID_TYPE_BOTH', so I altered them to be what they
> actually are i.e. a UID or GID
>
> reset sysvol 'samba-tool ntacl sysvolreset' and getfacl now returns:
>
> getfacl: Removing leading '/' from absolute path names
> # file: var/lib/samba/sysvol/
> # owner: EXAMPLE\134Administrator
> # group: 3000000
> user::rwx
> user:3000002:rwx
> user:EXAMPLE\134Administrator:rwx
> group::rwx
> group:3000000:rwx
> group:3000001:r-x
> group:3000003:r-x
> mask::rwx
> other::---
> default:user::rwx
> default:user:3000002:rwx
> default:user:EXAMPLE\134Administrator:rwx
> default:group::---
> default:group:3000000:rwx
> default:group:3000001:r-x
> default:group:3000003:r-x
> default:mask::rwx
> default:other::---
>
> Which to me is more like what windows expects it to be.
>
> What the numbers mean:
> 3000002 = S-1-5-18 Local System account
> 3000000 = S-1-5-32-544 Administrators group
> 3000001 = S-1-5-32-549 Server Operators builtin group
> 3000003 = S-1-5-11 Authenticated Users group
>
> This all leads me to my questions, why, when it comes to idmap.ldb,
> can a user also be a group and a group can also be a user and why was
> it setup like this in the first place ? , there must be a reason for it.
>
I've seen similar behaviour in Big Iron (enterprise) storage. I think
this is a bug.
/Davor
> Rowland
More information about the samba
mailing list