Hi Antun, Maybe the answer is a bit complex.
The numbers you see are, by design, not stored in LDAP, but in the file idmap.ldb, because UNIX uids are just not part of a standard AD Domain. In theory you could consider to rsync that file, but I don't think that this is a good approach. You might do it manually to fix your situation, but I cannot imagine this to be healthy when samba is up running. The key to consistent ID-mapping across all Linux servers incl. the DCs would be RFC 2307(bis?) attributes, although those have certain issues as well: - found no way to administer them with ADUC from W8, XP does it, although... - XP throws error messages when you try to save RFC2307 attributes, although it sets them correctly - AFAIK there's no automatic numbering management available, use Excel or plain paper and pen... - and, worst of all, POSIX group memberships are at least in part separate from AD group memberships (although it seems that the winbind idmap_ad backend in 3.6 is reading the AD group memberships, nice but really consistent???, if you don't forget to set nesting to something greater than one. Don't even bother to get group memberships look right on the DC). Of course, as it is LDAP you can write a script to search for users/groups without proper POSIX configuration and correct them (and potentially shorten or remap certain group names as they are presented to UNIX). I think many people do that and publish their scripts. If you want, you can have my PHP script. Doesn't take much resources, runs way under a second. Resolves AD nested groups as well. Still, I have some unresolved BUILTIN groups (such as the "local" "Administrators" group and some multi domain related groups or something), but that doesn't seem to harm. I'd recommend to consult the list how to properly add RFC2307 attributes on a running system - or, to be exact, two running systems. I ran into replication issues some months ago when trying this on a test domain, maybe just because I'd configured them on dc1 only, added numbers using ADUC and then reconfigured dc2. Just make sure you do the right thing here. In doubt, I'd sacrifice dc2 as a whole, upgrade dc1 and reinit dc2. Anyway, I don't like replicating the sysvol with rsync, because that has the following issues: - ADUC is usually choosing the DC to work with by certain rules. Of cause you can override it and explicitly connect to your rsync-master-DC. Ugly. - You could use osync instead which nicely tracks deletions and uses rsync for two way replication. But that takes about one minute for only 5 GPOs and nothing else in the sysvol, and if you do such thing every five minutes with cron that is even uglier than manual DC selection. I wonder whether Windows tries around to find a GPO file announced in the DIT, if it don't, GPOs would be a lot less fun (i.e. when testing). Maybe somebody else can tell. Ideal would be glusterfs. Itself it performs very well, but so far I ended up with Samba somehow being incapable to set xattrs or acls, although they're definitely supported. Maybe I just miss something. Cheers. On 9/3/2013 6:12 PM, Antun Horvat wrote: > Isn't there really any way to synchronize ACL ID's on these machines? > By my understanding these id's are pulled from internal LDAP database, > if this is correct why sysvolreset creates different id's on two > different machines that replicate the same database? > > Thanks in advance! > > > -------- Original Message -------- > Subject: Sysvol replication problem > Date: Thu, 29 Aug 2013 15:33:12 +0200 > From: Antun Horvat <antun.hor...@radio101.hr> > To: samba@lists.samba.org > > > > Hello fellow Samba users, > > I have a question that is related to sysvol replication. I have for now > two Samba DC's that are functioning as DNS and Active Directory roles in > my network. > > As samba for now does not support sysvol replication, I am replicating > sysvol shares via rsync with -XAavz attributes as suggested in samba wiki. > > The issue is that getfacl on these two servers return different user ids > and when I replicate these folders > with rsync, the secondary DC is using wrong IDs, and at the end, I can't > access sysvol folder on second dc (via share). > > On FSMO master "getfacl radio101.local" returns: > # file: radio101.local > # owner: root > # group: 3000000 > # flags: -s- > user::rwx > user:root:rwx > group::rwx > group:3000000:rwx > group:3000009:r-x > group:3000033:r-x > group:3000034:rwx > mask::rwx > other::--- > default:user::rwx > default:user:root:rwx > default:group::--- > default:group:3000000:rwx > default:group:3000009:r-x > default:group:3000033:r-x > default:group:3000034:rwx > default:mask::rwx > default:other::--- > > > while on secondary we have (after "ntacl sysvolreset"): > # file: radio101.local/ > # owner: root > # group: 3000000 > # flags: -s- > user::rwx > user:root:rwx > group::rwx > group:3000000:rwx > group:3000012:r-x > group:3000032:r-x > group:3000033:rwx > mask::rwx > other::--- > default:user::rwx > default:user:root:rwx > default:group::--- > default:group:3000000:rwx > default:group:3000012:r-x > default:group:3000032:r-x > default:group:3000033:rwx > default:mask::rwx > default:other::--- > > > What should I do next, > > Thanks for your help. > > >
signature.asc
Description: OpenPGP digital signature
-- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
