New Unix user and group domain

[Gerald (Jerry) Carter]

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

Volker Lendecke wrote:

> On Tue, Feb 21, 2006 at 09:40:10PM -0600, Gerald (Jerry) Carter wrote:

>> (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).
> 
> You think we can get away with that? This is certainly
> easiest.

I do.  We are really only worrying about upgraded DCs.
There are a lot of them, but I do not think them to be
the majority of the server install base.

The more I think about it, the upgraded DC scenario
really falls into 2 categories.

(a) migrated domains, and
(b) pure-blood Samba domains.

The first is obvious a problem.  The second is a problem when
allowing the admin to manually associated a RID with a group.
So we should disallow that except for well known RIDs below
1000.

> 
>> Now for those servers that will be adversely affected
>> we have to careful;y explain the scenarios and let the
>> administrator decide.
> 
> Fine with that.
> 
>> 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 could imagine doing the auto-mapping based on the RID
> allocator forever. When a users somehow becomes member of a
> newly created unix group, this is not reflected in the token
> we send back in the info3 struct. For these cases I could
> imagine doing the mapping on the fly.

How about this configuration:

* In all configurations default to 513 as the user's primary
     group in the ansence of a valid gid_to_sid() result in
     the server's SAM domain).

* 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

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

* Samba domain migrated from Windows DC - Use existing group
     mappings (should have been established by the 'net rpc
     vampire' proicess)..  Unmapped groups are shown in the
     S-1-22-2 domain.

This is not so insurmountable.  It allows us to choose and all
or none solution.


>> 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.
> 
> Nothing so far. I want to give the admin the possibility to
> live without 'add user script' and friends if
> ldapsam:trusted=edit or so. These scripts have given me so
> much headache in particular with LDAP that I want another
> option.

ok.  I see the advantage.  As lonbg as the default still falls
back to external scripts, then I'll go along.

> 
>> 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?
> 
> pdb_rid_algorithm() is true for smbpasswd and false for
> tdbsam and ldapsam. smbpasswd will always live with the
> uid*2+1000 thing, the others will have a RID allocator.
> 
> Now that we don't have stacked passdb modules anymore, this
> could be changed to a simple comparison on "passdb backend".

A (BOOL)fn() is fine.  It's better to keep it in the API as hard
coded checks of names are bound to bit rot.








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

iD8DBQFD/0Z2IR7qMdg1EfYRArtXAKDIp5FIOL4JO2UV8vMYKfv3mt5c/wCfaNpJ
GYjdEcx+j4+X2PVPtykaOF0=
=DUh5
-----END PGP SIGNATURE-----