Upgrade issue with 3.0.21b->3.0.22

[Volker Lendecke]

On Wed, Feb 08, 2006 at 12:18:38PM -0600, Gerald (Jerry) Carter wrote:
> Right.  But I was talking of 2 different issues.   One is that
> the primaryGroup must be within the same domain as the
> User's SID.  The second is any groups that exist in security
> descriptors which are potentially invalid after the upgrade.

Right now we only fill in the rid parts of the info3 reply,
so all groups we report need to be in the user's domain.

> I'm suggesting that we force the admin to define one
> Unix group as the 'Domain Admins' group and establish
> that mapping.  The alternative is to map *every* unix
> group into the machine SID domain since it is possible
> for any Unix group to be the primary group of a user.
> I suggesting that we just force the Admin to pick one
> and only one that must be mapped.

That's why I'm prosing the automagic on-demand mapping. We
can't map everything, the number-space is too small.

There's two legacy cases: First, the primary group. A script
could make sure that the primary groups of all users are
mapped, and that these settings are sane. The worst case is
two users that have the same nss primary gid, but two
different SIDs mapped. We should plainly refuse to convert
that. It's legacy because smbpasswd -a and the samr create
user call can auto-map the groups or alternatively refuse to
create the users.

The other case are groups popping up in
pdb_default_enum_group_memberships. I think these are the
main reason why the algorithmic fallback still was around.
Here I would say we can automagically add group mappings
based on the RID allocator.

Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20060208/1b376cf4/attachment.bin