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 >
On Sat, 2015-02-21 at 21:37 +0000, Rowland Penny wrote:> 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;OICII don't recall exactly which ACL on which file, but yes, an instance of a group owning a file does exist in sysvol. That group is deliberately left as having an ID assigned in idmap.ldb, not mapped to a system group (if that is ever a good idea is another thread), for this reason.> 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?In Windows, a SID is a SID, and there is no need to translate it to anything else for access checking.> > - 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?At the large scale, everything that can happen, will happen, and it will generate a support call. Better not to have situations where random network issues can change the on-disk behaviour. A group can't authenticate, but a user is of course members of groups, and groups can be assigned ownership of files.> > 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.You can, for instance, change the owner of a file to a group. 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 22/02/15 01:02, Andrew Bartlett wrote:> On Sat, 2015-02-21 at 21:37 +0000, Rowland Penny wrote: >> 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 > I don't recall exactly which ACL on which file, but yes, an instance of > a group owning a file does exist in sysvol. That group is deliberately > left as having an ID assigned in idmap.ldb, not mapped to a system group > (if that is ever a good idea is another thread), for this reason.OK Andrew, I have examined every file and directory under sysvol on my second DC and cannot find anything that is not owned by 'Administrator' (this shows as 'root' on the DC). This setup is exactly the same as when I joined it to the other DC, I have not changed anything. Can you please try and remember what the file is that must belong to a group? or does anybody else know what this file is? If I can find out what this file is, I can investigate it to try and understand why it must be owned by a group, an idea I am struggling to understand. Rowland> >> 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? > In Windows, a SID is a SID, and there is no need to translate it to > anything else for access checking. > >>> - 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? > At the large scale, everything that can happen, will happen, and it will > generate a support call. Better not to have situations where random > network issues can change the on-disk behaviour. A group can't > authenticate, but a user is of course members of groups, and groups can > be assigned ownership of files. > >>> 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. > You can, for instance, change the owner of a file to a group. > > Andrew Bartlett >
On 22/02/15 01:02, Andrew Bartlett wrote:> On Sat, 2015-02-21 at 21:37 +0000, Rowland Penny wrote: >> 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 > I don't recall exactly which ACL on which file, but yes, an instance of > a group owning a file does exist in sysvol. That group is deliberately > left as having an ID assigned in idmap.ldb, not mapped to a system group > (if that is ever a good idea is another thread), for this reason. > >> 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? > In Windows, a SID is a SID, and there is no need to translate it to > anything else for access checking. > >>> - 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? > At the large scale, everything that can happen, will happen, and it will > generate a support call. Better not to have situations where random > network issues can change the on-disk behaviour. A group can't > authenticate, but a user is of course members of groups, and groups can > be assigned ownership of files. > >>> 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. > You can, for instance, change the owner of a file to a group. > > Andrew Bartlett >OK, I have found out what files/directories are owned by a group in sysvol, *all* of them, at least on a windows 2008r2 server they are. However on a samba4 server, only the GPOs under the Policies dir do, they belong to the 'Domain Administrators' group, the problem is that on the windows server they belong to the 'Administrators' group. On the windows server you can change the ownership to Administrator and as only the GPOs belong to a group and the groups access settings come from the ACEs, is it possible that if the ownership of all files and directories in sysvol was changed to 'Administrator' everything would work just the same?? Rowland