-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, 21 Feb 2006, Gerald (Jerry) Carter wrote:
> Some people might find this discussion about upcoming
> changes in 3.0.22 interesting. It might also be helpful
> to get some feedback from the field on the ramifications
> of the changes.
The formward mail attachment was stripped. The original mail is
http://lists.samba.org/archive/samba-technical/2006-February/045600.html
- ----- forwarded message -------------------------
Volker & those interested in the user/group changes in 3.0.22:
Here's my random thoughts on the name <-> SID <-> uid/gid
mapping work you've been doing. Please correct me if I make
any wrong assumption. This is kind of a summary for me to
help write down the design and issues in one mail.
The crux of the changes is the new uid/gid mapping code. The
S-1-22-1 domain will replace the rid algorithm for users and the
S-1-22-2 domain will be used for groups.
So we have local groups and domain groups. The S-1-22-2
(well known Samba servers) and S-1-5-32 (well known among
Windows and Samba) domains are always local groups. For a
non-DC, the S-1-5-$MACHINE is also a local domain (specific
per Samba installation).
'net groupmap' is used to set explicit mappings for the
S-1-5-$MACHINE domain (which is the same as the domain SID
on a samba DC).
'net rpc sam' will be used as a user/group management shell.
Note that I don't see how this can replace 'net groupmap'
without adding a new rpc pipe or possible the unixinfo pipe
and have commands for associating a SID with a gid.
lookup_sid() and lookup_name() have been re-written to be
a single point of name <-> SID resolution.
When adding a new user we now generate the primary group
RID from the actual Unix primary gid and fallback to 513
in case that Unix group is not resolvable or exists in the
S-1-22-2 domain (see the patch I posted earlier tonight).
I realize that this is not entirely true since we still
have an unfinished mix of RID algorithms, rid allocation,
and the new S-1-22-{1,2} domains.
The main problem that we have is that a group might have
resolved to S-1-5-$MACHINE in 3.0.21 and we now are resolving
it to S-1-22-2 in 3.0.22. This directly affects the user's
token passed back to the client in the net_samlogon() reply
(potentially part of the other_sids field). So therefore
a Windows File server joined to a Samba domain might have
security descriptors with the old group SIDs and now deny
access to a user that should have access. The same situation
could occur if you upgrade the Samba DC and leave Samba
member servers running and older release.
The main problem with the rid algorithms is potential conflicts
with migrated windows domains. There is no prevention for
assigning duplicate rids (and no easy way to tell if you are
using a previously assigned rid).
On a non-DC I think this is a non-issue. Or at least is
ignorable. For a new domain, we don't have any upgrade
issues with group SIDs. So the problem we can focus on
is upgrading a Samba domain.
We have 3 possible solutions on the table to get from where we
are in 3.0.21 to where we want to be in 3.0.22.
(a) have the administrator manually create the explicit
group mapping which matches the SID assigned by 3.0.21,
(b) auto map the groups on behalf of the administrator, or
(c) Ignore the change in group SIDs entirely.
I think that (c) should be the default behavior. For those
people not affected by the security descriptor issue (i.e.
only Samba file servers and running the 3.0.22 or higher on
all servers).
Now for those servers that will be adversely affected
we have to careful;y explain the scenarios and let the
administrator decide.
I do not believe that (b) can reliably work. There are too
many differences between smbpasswd, tdb, and LDAP installations.
And at what point do you stop automapping groups? This
solutions seems only slightly better than what we have now
and actually replies on more persistent storage (so more
places for things to potentially go wrong).
I know you have option (a) but I think it is the best solution
to prevent long term baggage. I think this should be a HOWTO
and a set of tools that helps walk the admin though the upgrade
process. We can refuse to start somehow unless we know that
things have been dealt with somehow.
Additional questions:
1. Why did you move the Unix create user/group calls into
the passdb API? I don't understand what you are trying
to solve there.
2. What is the real meaning of the pdb_rid_algorithm() call?
Which algorithm do you mean? The one used by 3.0.21 or
the new Unix S-1-22- domains?
That's enough for now I think.
cheers, jerry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: For info see http://quantumlab.net/pine_privacy_guard/
iD8DBQFD/GyUIR7qMdg1EfYRAil7AKC6vx6yud9n6XYX9slBWJ6ltEri9gCgkv1Z
ugeg5gYtkn8JbY3p3FXFoj0=MXNR
-----END PGP SIGNATURE-----