Seems that each system is making up it own id's. Both the centos and fedora systems have the same idmap settings. idmap uid = 3000000-4000000 idmap gid = 3000000-4000000 samba 3.5.5 winbind and nss on fedora 13 workstation uid=3000000(jonnt) gid=3000004(domain users) groups=3000004(domain users),3000005(domain admins),3000006(denied rodc password replication group),3000007(vpn),3000006(denied rodc password replication group),16777216(BUILTIN+administrators) samba 3.5.5 winbind and nss on centos 5.5 file server uid=3000000(jonnt) gid=3000000(domain users) groups=3000000(domain users),3000001(domain admins),3000002(denied rodc password replication group),3000003(vpn),3000002(denied rodc password replication group) samba 4 DC and file server with nss on centos 5.5 x86_64 uid=3000011(jonnt) gid=100(users) groups=100(users),3000009(Domain Admins),3000015(VPN) Jonn Taylor
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010-10-06 17:35, Taylor, Jonn wrote:> Seems that each system is making up it own id's. Both the centos and > fedora systems have the same idmap settings. > > idmap uid = 3000000-4000000 > idmap gid = 3000000-4000000That means you're not setting an idmap backend, so this defaults to "tdb" on the 3.5 boxes. In turn, this means that all three systems are creating id mappings on an as-needed basis, creating uids and gids in the order of the users/groups that request ids. Unless you use some scheme that keeps the unixids in sync across the network, you'll always be seeing this. Possible solutions include using the "rid" backend to idmap, which will add the sid's RID part to the idmap base. If you only have users coming in from one domain, that should be fine for the 3.5 boxes. The Samba4 idmap implementation is less sophisticated and only knows about the "tdb"-like counting up unixids. Nothing much that can be done about this right now. We're currently investigating the most viable way to fix this. Cheers, Kai - -- Kai Blin Worldforge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkytXbgACgkQEKXX/bF2FpQ1YACdG4f1GRHoWzarY8W5Xw2TEh96 O00An1YSpVBmRzYCePySJHZr0xdw3ua8 =0Bmi -----END PGP SIGNATURE-----
Thank for your replay. I will try the RID stuff and see how it goes. Jonn On 10/07/2010 12:42 AM, Kai Blin wrote:> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 2010-10-06 17:35, Taylor, Jonn wrote: >> Seems that each system is making up it own id's. Both the centos and >> fedora systems have the same idmap settings. >> >> idmap uid = 3000000-4000000 >> idmap gid = 3000000-4000000 > That means you're not setting an idmap backend, so this defaults to > "tdb" on the 3.5 boxes. In turn, this means that all three systems are > creating id mappings on an as-needed basis, creating uids and gids in > the order of the users/groups that request ids. > > Unless you use some scheme that keeps the unixids in sync across the > network, you'll always be seeing this. Possible solutions include using > the "rid" backend to idmap, which will add the sid's RID part to the > idmap base. If you only have users coming in from one domain, that > should be fine for the 3.5 boxes. > > The Samba4 idmap implementation is less sophisticated and only knows > about the "tdb"-like counting up unixids. Nothing much that can be done > about this right now. We're currently investigating the most viable way > to fix this. > > Cheers, > Kai > > - -- > Kai Blin > Worldforge developer http://www.worldforge.org/ > Wine developer http://wiki.winehq.org/KaiBlin > Samba team member http://www.samba.org/samba/team/ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkytXbgACgkQEKXX/bF2FpQ1YACdG4f1GRHoWzarY8W5Xw2TEh96 > O00An1YSpVBmRzYCePySJHZr0xdw3ua8 > =0Bmi > -----END PGP SIGNATURE-----