[Samba] Samba4, idmap.ldb & ID_TYPE_BOTH
Rowland Penny
rowlandpenny at googlemail.com
Sat Feb 21 08:44:41 MST 2015
On 21/02/15 13:15, Davor Vusir wrote:
>
> 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
Interesting, even Jeremy Allinson wondered why a user could also be a
group, the thread never actually said what files the group actually
owned. Personally I have never known of a group owning files, they allow
access to files, but actually owning files??
I am still wondering how a user can be a group, as far as I understand,
a group is a group whether it is a linux group or a windows group, the
same goes for users.
I have found a small problem, which I believe is a bug. I found it after
I ran 'samba-tool ntacl sysvolcheck' and got this:
samba-tool ntacl sysvolcheck
ERROR(<class 'samba.provision.ProvisioningError'>): uncaught exception -
ProvisioningError: DB ACL on GPO directory
/var/lib/samba/sysvol/example.com/Policies/{6AC1786C-016F-11D2-945F-00C04FB984F9}
O:LAG:DAD:P(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;EA)(A;OICIIO;0x001f01ff;;;CO)(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;SY)(A;OICI;0x001200a9;;;AU)(A;OICI;0x001200a9;;;ED)
does not match expected value
O:DAG:DAD:P(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;EA)(A;OICIIO;0x001f01ff;;;CO)(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;SY)(A;OICI;0x001200a9;;;AU)(A;OICI;0x001200a9;;;ED)
from GPO object
File "/usr/lib/python2.7/dist-packages/samba/netcmd/__init__.py",
line 175, in _run
return self.run(*args, **kwargs)
File "/usr/lib/python2.7/dist-packages/samba/netcmd/ntacl.py", line
249, in run
lp)
File "/usr/lib/python2.7/dist-packages/samba/provision/__init__.py",
line 1726, in checksysvolacl
direct_db_access)
File "/usr/lib/python2.7/dist-packages/samba/provision/__init__.py",
line 1677, in check_gpos_acl
domainsid, direct_db_access)
The difference is here: 'O:LAG:DAD:P(A' , this is expected to be
'O:DAG:DAD:P(A'.
If I run 'getent passwd Administrator' on the DC, I get this:
EXAMPLE\Administrator:*:3000078:10000::/home/EXAMPLE/Administrator:/bin/bash
'getent passwd EXAMPLE\Administrator' returns nothing
Both getent variants return nothing when run on a member server.
The 'samba-tool ntacl sysvolcheck' error is telling me that the owner is
'local Administrator' and it is expected to be the 'domain
Administrator' (or is that Domain Administrators, a group ?)
I am now beginning to think that Administrator shouldn't have either an
'xidNumber' or a 'uidNumber', I think that by giving Administrator
either, you are turning it into a local Unix user.
I would point out that whilst 'samba-tool ntacl sysvolcheck' errors out,
'samba-tool ntacl sysvolreset' seems to work without error.
More information about the samba
mailing list