New Unix user and group domain

[Gerald (Jerry) Carter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Volker Lendecke wrote:
>> * standalone, member server, new Samba domain - don't worry
>>      about the RID algorithm from 3.0.21.  Just use the S-1-22-X
>>      domains
> 
> Also ok for standalone and member. We don't have to present
> to anyone, so why bother.  In our own token s-1-22-2-gid is
> as good as a mapped one.

The  line "on't have to present to anyone" has me
confused.  I'm pretty sure we are saying the same thing.
But we do have to present "Unix group\foo" in ACL
dialogs.  And we return the S-1-2-22-${gid} in the
other_sids portion of the samlogon() reply.

> For a fresh DC we need explicit mappings to RIDs above 1000,
> be they automatic or manual.

ACK.

>> * Upgraded pure-blood Samba DC - no persistent mapping.  Just
>>      continue to use the use the RID algorithm.  Do not allow
>>      manual group mappings above 1000 and do not use a
>>      monotonic RID allocation scheme.
> 
> We have to cope with situations where the admin has messed
> with the group mapping table, we can not rely on nobody
> having done explicit mappings above RID 1000.

You're right.  I forgot about this.

> My plan for Samba upgrades would be to run a script that
> goes through all users in passdb, gets all its groups from
> nss and does an explicit mapping based on the algorithm if
> it's not already there. Then we go through all users and
> groups, looking for the max RID assigned so far and adapt
> the allocator.
> 
> This covers both the migrated as well as the pure but
> messed-with domains.

Sounds right.  SO we upgrade the >= 3.0.21 domain and
then require explicit mappings.

> For new mappings I would like to see a net subcommand to
> take just a unix group, pick a new RID and map it to a
> domain group. Alternatively do that step automatically in
> pdb_enum_group_memberships if some unmapped groups pops up
> from getgroups().

Just to clarify, is this new net subcommand restricted to
Samba DCs?  I ask only because you used the term domain
groups.  Or do you simply mean groups within our SAM domain?

I really would like to avoid automatic persistent mappings.
I would prefer to get some mileage on the new design before
trying to automate it too much.  If we decide that automapping
of groups is necessary, we can attack that problem separately.
My vote is to, at least at first, err on the side of simplicity.

So the final issue is how to manage membership in the BUILTIN
groups.  I'm going to start a new thread for that.





cheers, jerry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEAIYWIR7qMdg1EfYRAuY9AKDwV5FlnnnajF5xQJl/QmvKMLBzngCg2wu7
Jb2XrKpi85Wi/6dbZ6Nif6I=
=9/7u
-----END PGP SIGNATURE-----