-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mario,
> So do I get it right, that Samba set the primaryGroupSID > to the "Domain Users" SID, if the users primary unix > group is not mapped to nt group and even if the > user is not member of it? And only if the users primary > group is mapped, this one is assigned to his samba > account as primaryGroupSID? Yes. But let me clarify that this is not some flippant decision our own part. Windows requires that the users primaryGroupSID matches the same domain as the user's SID. Therefore Windows assigns the rid 513 as the primary group to all accounts that that do not have a valid group which can be assigned. For example, if you have a freshly installed Windows XP client, the local Administrator has a primary group RID of 513 even though no such group really exists on the box. When the client OS is first installed the only groups available are in the BUILTIN domain. Now the problems with mapping users and groups on Unix to a Windows domain model is that you are mapping two 32-bit number ranges into one. Samba introduced a RID algorithm in the 2.0 release to handle this. But the RID algorithm is not flexible enough to handle things like migrated domains. The only way to real deal with that is persistent RID allocation. So once you start introducing RID allocation, you either have to map all users and group (not just ones in Samba's passdb) to a valid SID or assign the unmapped ones a SID that is guaranteed not to conflict with the RID allocator. Hence the new S-1-22-1-{1,2} domains. The problem with the primaryGroupSID attribute is that it is too difficult to guarantee that is properly reflects the real unix primary group. It will get out of sync. So we decided to honor the Unix group membership in all cases since this is what you would really expect anyways. So when you start honoring the real Unix primary group, you run the chance that the real primary group is in the the S-1-22-2 domain. But Windows won't allow this. Hence you have to have some RID that is guaranteed to always be available as the user's primary group. We choose 513 since this is what Windows does. There was several weeks worth of discussion about this and it was a fairly early change during the 3.0.23 development cycle. > So, if I have given the Domain Users richts not to all > my users. And I got a user who is not member of a mapped > group. His primary group rid is 513 and he is allowed > to log on to a workstation. > > And I have given some special permissions to a folder > for the Domain Users group. Then my user is able to > gain the permissions the users of the Domain Users group > have which he is not intended to have. > > I hope it's not really working that way... Yup. And if this was a problem for you, it would have been really good to know during the 6 months of development between 3.0.22 and 3.0.23 or even the 2 months between 3.0.23 and 3.0.23c. You can fix the situation by manually running 'net groupmap unixgroup=foo' for the user's real primary group and it will automatically be reported by pdbedit. This was also outlined in the release notes. cheers, jerry ===================================================================== Samba ------- http://www.samba.org Centeris ----------- http://www.centeris.com "What man is a man who does not make the world better?" --Balian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE/d74IR7qMdg1EfYRAp4pAJ42ssaXlU6pY1D8BvJrlTGwdLs2egCdEW/2 BCSFeARIBr//3ES2mi3+Kb8= =5Zxq -----END PGP SIGNATURE----- -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba