[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