Hi Le 09/06/2016 à 20:42, Rowland penny a écrit :> On 08/06/16 15:34, mathias dufresne wrote: >> Hi all, >> >> [snip] >> And we get issue with Linux ACLs: they are not the same because some >> BUILTIN users and/or groups do not have same id mapping on all DC. >> >> How to force all DC to get same id mapping? >> >> Using "acl_xattr:ignore system acls = yes", are Linux ACLs still >> important >> or are we supposed to use Windows ACLs only into stored into some Samba >> file? In that case, which file(s)?They're stored in each file xattr as an obscure base64 encoded value BUT in all cases unix permissions applies when accessing through samba. So disabling ACLs means that you've to set the properties correctly to allow "samba" unix users to access files (there's no clear doc on that…)> OK, first you do not need this on a DC: 'winbind nss info = rfc2307' > > Secondly, your different id mappings for BUILTIN users & groups is a > well known problem. The id's are stored in 'idmap.ldb' as 'xidNumber' > attributes and seem to be given on a first come basis, only problem > is, the groups etc don't connect in the same order on every DC.Wasn't this supposed to be solved in 4.2? https://wiki.samba.org/index.php/Join_an_additional_Samba_DC_to_an_existing_Active_Directory#GID_mappings_of_built-in_groups The wiki seems to say that Builtin xID are now replicated but there is no clear upgrade path (if you've mixed 4.1 & 4.2 DC which mapping will be stored in 4.2 winbind? What happens when you upgrade the 4.1 to 4.2?)> > To get the same ID's on every DC, you will have to copy idmap.ldb from > the first DC to every other DC, run 'net cache flush' and then keep > 'idmap.ldb' in sync. >Regards
On 10/06/16 07:52, Sébastien Le Ray wrote:> Hi > > > Le 09/06/2016 à 20:42, Rowland penny a écrit : >> On 08/06/16 15:34, mathias dufresne wrote: >>> Hi all, >>> >>> [snip] >>> And we get issue with Linux ACLs: they are not the same because some >>> BUILTIN users and/or groups do not have same id mapping on all DC. >>> >>> How to force all DC to get same id mapping? >>> >>> Using "acl_xattr:ignore system acls = yes", are Linux ACLs still >>> important >>> or are we supposed to use Windows ACLs only into stored into some Samba >>> file? In that case, which file(s)? > > They're stored in each file xattr as an obscure base64 encoded value > BUT in all cases unix permissions applies when accessing through > samba. So disabling ACLs means that you've to set the properties > correctly to allow "samba" unix users to access files (there's no > clear doc on that…) > >> OK, first you do not need this on a DC: 'winbind nss info = rfc2307' >> >> Secondly, your different id mappings for BUILTIN users & groups is a >> well known problem. The id's are stored in 'idmap.ldb' as 'xidNumber' >> attributes and seem to be given on a first come basis, only problem >> is, the groups etc don't connect in the same order on every DC. > > Wasn't this supposed to be solved in 4.2? > https://wiki.samba.org/index.php/Join_an_additional_Samba_DC_to_an_existing_Active_Directory#GID_mappings_of_built-in_groups > > The wiki seems to say that Builtin xID are now replicated but there is > no clear upgrade path (if you've mixed 4.1 & 4.2 DC which mapping will > be stored in 4.2 winbind? What happens when you upgrade the 4.1 to 4.2?)Well, it is and it isn't, yes winbindd will display the user & group names for sysvol, but sysvol still isn't replicated between DCs. I think this means that when you sync sysvol manually, you will get the ID's from the first DC applied to sysvol on the second DC and if there is a difference in ID numbers between the DC's, you will either just get a number or, even worse, a wrong name returned. I could be wrong, but I still think you need to keep idmap.ldb in sync on all DCs, if you are syncing sysvol. Rowland> >> >> To get the same ID's on every DC, you will have to copy idmap.ldb >> from the first DC to every other DC, run 'net cache flush' and then >> keep 'idmap.ldb' in sync. >> > Regards
Le 10/06/2016 à 09:26, Rowland penny a écrit :> On 10/06/16 07:52, Sébastien Le Ray wrote: >> Hi >> >> Wasn't this supposed to be solved in 4.2? >> https://wiki.samba.org/index.php/Join_an_additional_Samba_DC_to_an_existing_Active_Directory#GID_mappings_of_built-in_groups >> >> The wiki seems to say that Builtin xID are now replicated but there >> is no clear upgrade path (if you've mixed 4.1 & 4.2 DC which mapping >> will be stored in 4.2 winbind? What happens when you upgrade the 4.1 >> to 4.2?) > > Well, it is and it isn't, yes winbindd will display the user & group > names for sysvol, but sysvol still isn't replicated between DCs. I > think this means that when you sync sysvol manually, you will get the > ID's from the first DC applied to sysvol on the second DC and if there > is a difference in ID numbers between the DC's, you will either just > get a number or, even worse, a wrong name returned. > > I could be wrong, but I still think you need to keep idmap.ldb in sync > on all DCs, if you are syncing sysvol.OK got it, the main difference is that ids => name mapping /is active/ on DC. So you can avoid idmap.ldb syncing if you don't use --numeric-ids in your rsync command… as long as receiving DC "knows" the group (name will be resolved to ID so id mismatch doesn't matter). I think the wiki could be updated to completly remove the 4.2 statement if my assumption is correct because if receiving DC never "saw" the BUILTIN group owning a file it'll still be mapped to the same id as the sender… which let us in a inconsistent state
Thank you all for these replies. 2016-06-10 9:26 GMT+02:00 Rowland penny <rpenny at samba.org>:> On 10/06/16 07:52, Sébastien Le Ray wrote: > >> Hi >> >> >> Le 09/06/2016 à 20:42, Rowland penny a écrit : >> >>> On 08/06/16 15:34, mathias dufresne wrote: >>> >>>> Hi all, >>>> >>>> [snip] >>>> And we get issue with Linux ACLs: they are not the same because some >>>> BUILTIN users and/or groups do not have same id mapping on all DC. >>>> >>>> How to force all DC to get same id mapping? >>>> >>>> Using "acl_xattr:ignore system acls = yes", are Linux ACLs still >>>> important >>>> or are we supposed to use Windows ACLs only into stored into some Samba >>>> file? In that case, which file(s)? >>>> >>> >> They're stored in each file xattr as an obscure base64 encoded value >> BUT in all cases unix permissions applies when accessing through samba. >> So disabling ACLs means that you've to set the properties correctly to >> allow "samba" unix users to access files (there's no clear doc on that…) >> >> OK, first you do not need this on a DC: 'winbind nss info = rfc2307' >>> >>> Secondly, your different id mappings for BUILTIN users & groups is a >>> well known problem. The id's are stored in 'idmap.ldb' as 'xidNumber' >>> attributes and seem to be given on a first come basis, only problem is, the >>> groups etc don't connect in the same order on every DC. >>> >> >> Wasn't this supposed to be solved in 4.2? >> >> https://wiki.samba.org/index.php/Join_an_additional_Samba_DC_to_an_existing_Active_Directory#GID_mappings_of_built-in_groups >> The wiki seems to say that Builtin xID are now replicated but there is no >> clear upgrade path (if you've mixed 4.1 & 4.2 DC which mapping will be >> stored in 4.2 winbind? What happens when you upgrade the 4.1 to 4.2?) >> > > Well, it is and it isn't, yes winbindd will display the user & group names > for sysvol, but sysvol still isn't replicated between DCs. I think this > means that when you sync sysvol manually, you will get the ID's from the > first DC applied to sysvol on the second DC and if there is a difference in > ID numbers between the DC's, you will either just get a number or, even > worse, a wrong name returned. > > I could be wrong, but I still think you need to keep idmap.ldb in sync on > all DCs, if you are syncing sysvol. >At least here you were right: without syncing idmap.ldb followed by "net cache flush" Sysvol rights were an awful mess and so GPO were retrieved once on really too few (tests are done for now with around 20 DCs which makes that kind of issue showing really quickly/often). I'm about to add xidNumber to any users and groups in BUILTIN and Users directories (in LDAP tree) to avoid as often as possible that idmap process. I should come back to tell how things went.> > Rowland > > >> >>> To get the same ID's on every DC, you will have to copy idmap.ldb from >>> the first DC to every other DC, run 'net cache flush' and then keep >>> 'idmap.ldb' in sync. >>> >>> Regards >> > > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba >
Hi all, Following this thread with interest, as we are also having some issues with GPO (they work on and off, unpredictably) We checked iddap.ldb on the DCs and noticed differences between DCs. We would like to ask some questions: On 10-6-2016 9:26, Rowland penny wrote:> Well, it is and it isn't, yes winbindd will display the user & group > names for sysvol, but sysvol still isn't replicated between DCs. I think > this means that when you sync sysvol manually, you will get the ID's > from the first DC applied to sysvol on the second DC and if there is a > difference in ID numbers between the DC's, you will either just get a > number or, even worse, a wrong name returned. > > I could be wrong, but I still think you need to keep idmap.ldb in sync > on all DCs, if you are syncing sysvol.We are on sernet-samba-4.4.4 on the DCs, and "winbindd -D" is running on DCs. We understand we need to keep idmap.ldb in sync. We did this in the past, but it seems they have gotten out of sync again. One question: HOW OFTEN do we need to do manually sync the imap.ldb files? After each and every regular user addition/deletion? We are currently on sernet-4.4.4 on the 3 DCs, but on our fileserver we are still on samba 4.2.11 and sssd. Would that last bit have any impact on the GPO situation..? (i don't think so, because GPOs are on the DCs and not on the fileserver..?) Since our idmap.ldb differs per DC, HOW to choose which one to copy to the other DCs? Choosing wrongly will probably have major implications..? Sorry to ask so many questions, hopefully someone will answer. Best regards, MJ