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/ 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. Rowland
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
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
On Thu, 2015-02-19 at 17:15 +0000, Rowland Penny wrote:> > 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.It goes like this: - Groups can own files (there are groups like domain administrators that own files in sysvol) - We don't (eg in sidHistory, or when files are migrated, preserving permissions, from a workstation or from a domain that is not trusted) always know if an incoming SID is a user or group. - Working out if an arbitrary SID is a user or group takes time and network operations, which may fail. ID_TYPE_BOTH is both fast and deterministic in this respect. My view is that we should always have mapped SIDs to both a UID and GID, and I understand that in general, we are doing that now in new backends. See for example idmap_rid and idmap_autorid. The only tricky bit is that while a user can be put in an extra group to pick up any permissions assigned to it as a group, a group can't get user-based permissions, so can't obtain the extra rights associated with file ownership. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba
On 21/02/15 19:26, Andrew Bartlett wrote:> On Thu, 2015-02-19 at 17:15 +0000, Rowland Penny wrote: >> 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. > It goes like this: > > - Groups can own files (there are groups like domain administrators > that own files in sysvol)Does domain administrators own the files ? as I posted earlier, trying to reset sysvol is failing for me and the relevant part of the ACL is this: O:LAG:DAD:P(A;OICI This is the start of the ACL and if we expand it for better reading 'O:LA' 'G:DA 'D:P(A;OICI'. The first part is the owner, the second is the group and the third is the start of the ACEs. So the owner (O) is LA which is 'Local Administrator' and the group (G) is DA which is 'Domain Administrators' , as I read it, Domain Administrators doesn't own the files, or am I missing something?> - We don't (eg in sidHistory, or when files are migrated, preserving > permissions, from a workstation or from a domain that is not trusted) > always know if an incoming SID is a user or group.does windows know from the SID what the object is? and if not, what does windows do?> - Working out if an arbitrary SID is a user or group takes time and > network operations, which may fail. ID_TYPE_BOTH is both fast and > deterministic in this respect.And in my opinion (which is worth very little) it is a kludge, also does a group actually try to connect (note, I do not know if this happens, which is why I am asking) and if so how ? a group doesn't have a password so how can it authenticate?> My view is that we should always have mapped SIDs to both a UID and GID, > and I understand that in general, we are doing that now in new backends. > See for example idmap_rid and idmap_autorid. > > The only tricky bit is that while a user can be put in an extra group to > pick up any permissions assigned to it as a group, a group can't get > user-based permissions, so can't obtain the extra rights associated with > file ownership.Again I ask, what file ownership? can you please name a file that a windows group owns, sorry if I am coming across as negative here, but I am struggling to understand just how a group can own files, I am used to files belonging to a user and members of a group being allowed access to them. Rowland> Andrew Bartlett >