removing BUILTIN from winbind nested groups ?

[Gerald (Jerry) Carter]

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

John H Terpstra wrote:

>> (2) make 'enable net groupmap' and 'winbind nested groups'
>> mutually exclusive.  The former would be a new smb.conf option.
> 
> Agreed. This makes sense also.
> 
>> This means that winbindd no longer has to store stick its
>> fingers in the passdb backend. 
> 
> What do you mean by this? How does Winbind interfere with 
> the passdb backend?   In what way would this be eliminated?

Both smbd and winbindd currently manipulate the
group mapping tables.  I'm proposing that by making
net groupmap mutually exclusive to winbindd nested
groups, winbindd can now simply store it's group
mapping info in its own tdb.

>> It also means that you can have replicated nested groups.
> 
> Where will the nested group info be stored? Right now it is 
> in tdb files - do  you mean it will now go into tdbsam
> or ldapsam? If so, how will this impact  smbpasswd backends?


That should have been 'can not have replicated nested groups'.
Sorry for the confusion.

>> * Samba Domain Controller
>>
>> An admin could use 'net groupmap' to manually create domain
>> groups or use winbind nested groups (also domain groups).
>> We loose the concept of domain local groups.
> 
> OK. If some admin does this, what happens when he then 
> starts winbind? What happens when he then enables 'winbind
> nested groups'? How will this affect an existing configuration?

winbindd will start but will not support 'winbind nested groups'
if (lp_enable_net_groupmap() == True).  By setting 'enable net
groupmap' to yes by default, you maintain backwards compatible
behavior.  And I serious doubt that many if any sites are using
these 2 features together anyways.

Existing mapping from one implementation would be ignored
by the other.

>> You can still configure local groups on the member server using
>> either 'net groupmap' or nested groups (although the winbindd
>> nested group support makes more sense here).
> 
> Please explain that last part of the sentence.

Since winbindd is strongly recommend on member servers,
anyways using winbindd for handling local group membership
is the easier mechanism here.  Although you could manually
map a unix group to a local SID and use that in an ACL
example.  Same thing you can do today.
.
>>* Standalone
>>
>> This was the tricky case for me and is where the
>> LOCAL_SAM_SID-SAMBA_ADMIN_RID group comes in.  The membership
>> in this group can be manipulated either by manually establishing
>> a group mapping or by winbind's nested group feature.  We just
>> automatically create the local group in winbindd.  The net group
>> mapping feature works like unmapped groups do now.
> 
> I am not following your explanation here. Why do we need this?
> 
> The alternative process on a Standalone server is:
> 
> a) Auto-create local groups: Administrators, Power 
> Users, etc.

Just to be a little pedantic, I want to clarify that these
groups will be created in memory only in smbd with hard coded
defaults memberships.

> b) Automatically make the LOCAL_SAM_SID-500 a member of
> the Administrators (local) group and to the Power Users
> (local) group.

You are adding a user not a group.  Since an admin will not
be able to manipulate the membership of built groups, limiting
this to a single user makes no sense.  You need to add a
local group as a member so that the admin can manipulate the
membership of that local group.

> c) Automap all UNIX groups to Windows groups

we do that anyways.

> Let smbd handle all of this. No need for Windbind.
> 
> In fact, my thinking is: If winbind is run we are not 
> standalone.

winbindd can run on standalone servers to provide nested
groups.

>>Example:
>>
>>Here's is how this simplification would help out in the
>>current code.  Currently the check for whether a user is able
>>to grant or revoke privileges is based on membership in
>>the 'Domain Admins' group.  If we  are a member server, then
>>we have to lookup the sid for our domain.  If we are
>>a domain controller, we have to lookup our own sid.  And right
>>now, we fail on standalone servers. None of these checks are
>>hard but they are three different checks.
> 
> Agreed. But I do believe that a domain member, or domain 
> controller should  enforce use of Winbind. Volker's suggestion
> makes sense to me.

Volker's suggestion was to *require* winbindd.  We just fork()
and exec() it ourself.  I'm proposing a way to not require
winbindd.  It would only be required if you wanted nested
groups.  I'm not sure you are following me here.

> 
>>It's the same case for SAMR access checks, printers, svcctl
>>objects, and the upcoming registry checks.
>>
>>My proposal would allow us to simply check for the
>>BUILTIN\Administrators SID in the user's NT_TOKEN regardless
>>of what the server's role was configure to be.
>>
>>So what do you think?
> 
> I am glad this is being explored now - I'd hate to 
> have brand-new  documentation that is wacko-off-the-mark
> when the new books are printed! Unfortunately, there is not
> much time left before publication close-off.

This will not be done before then. Documentation is perpetually
out of date John.  It can be helped unless the code is frozen.

> I much appreciate this being addressed at this time. This 
> whole area has been  a mess since 3.0 shipped.

I don't think is has been a mess as much as it tried to be
too flexible and do too much.






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

iD8DBQFCsdODIR7qMdg1EfYRAvmMAJ9zbIdbAkqJIoLplGiS53qwmhikggCfU+Bf
Um3kMY48Lu9E8/6JWMQOIq0=
=IUrC
-----END PGP SIGNATURE-----