[Samba] Samba4, idmap.ldb & ID_TYPE_BOTH

Davor Vusir davortvusir at gmail.com
Sat Feb 21 06:15:05 MST 2015


Rowland Penny skrev den 2015-02-21 10:35:
> On 20/02/15 21:27, Davor Vusir wrote:
>>
>> 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
>>
>
> I am now beginning to think along the same lines, to me a user is a 
> single entity and a group is a collection of entities, so how can a 
> group also be a user?? and how can a user also be a group??
>
> Would one of the devs care to comment on why this was done? Andrew 
> Bartlett for instance.
>
> The use of 'ID_TYPE_BOTH' cannot be right, can it?
>
> Take the example of a *USER* I created on my test DC:
>
> If I run 'getent passwd nfs-user' I get this:
>
> EXAMPLE\nfs-user:*:3000040:10000::/home/EXAMPLE/nfs-user:/bin/bash
>
> And if I look it the record for '3000040' in idmap.ldb, I find this:
>
> dn: CN=S-1-5-21-2025076216-3455336656-3842161122-1117
> cn: S-1-5-21-2025076216-3455336656-3842161122-1117
> objectClass: sidMap
> objectSid: S-1-5-21-2025076216-3455336656-3842161122-1117
> type: ID_TYPE_BOTH
> xidNumber: 3000040
> distinguishedName: CN=S-1-5-21-2025076216-3455336656-3842161122-1117
>
> If I now look at the record in AD for 'nfs-user', I find these 
> objectclasses:
>
> objectClass: top
> objectClass: person
> objectClass: organizationalPerson
> objectClass: user
>
> I know the user is a user, AD knows that the user is a user but samba 
> seems to think that it is a user and a group *WHY?*
>
> Rowland
>
>
Found this: 
http://samba.2283325.n4.nabble.com/Why-are-we-allocating-ID-TYPE-BOTH-on-a-user-or-machine-SID-type-td4655183.html

/Davor


More information about the samba mailing list