[Samba] Samba4, idmap.ldb & ID_TYPE_BOTH
Rowland Penny
rowlandpenny at googlemail.com
Sat Feb 21 02:35:16 MST 2015
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
More information about the samba
mailing list