[Samba] User Group SID behavior has changed from 21b to 23c

[Gerald (Jerry) Carter]

-----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-----