removing BUILTIN from winbind nested groups ?

[John H Terpstra]

On Thursday 16 June 2005 12:15, Gerald (Jerry) Carter wrote:
> Volker Lendecke wrote:
> > What you want as far as I can tell is to have a static security
> > descriptor giving S-1-5-32-544 (BUILTIN\Administrators) a
> > special right. BUILTIN\Administrators is a local group
> > that can have for example DOMAIN\"Domain Admins" as a member.
>
> Correct.
>
> > We came to the conclusion that for any kind of nested groups
> > winbind is mandatory, so one way to solve this is to force
> > winbind always. We could make smbd fork winbind if it's not
> > there.

This sounds like a good option if it fits all other architectural constraints.

>
> Before we go there, I have some solid details on how to simplify
> this feature (groups in general, not just nested groups) some.
> If you don't like it or find a flaw I missed, then we can revisit
> the winbindd-always-on idea.
>
> (1) move support for BUILTIN groups internally to smbd.  Create
> default memberships in the builtin groups.

I like this possibility. It makes perfect sense to me, and will simplify 
documentation of how Samba does group handling.

>
> (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?

> 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?

>
> (3) restrict the 'net groupmap' and 'winbind nested groups'
> to working with the SID for our own SID (just like with do
> with user accounts).  This means that we don't allow an
> admin to define the group type but infer it based on the
> server's role.

Understood. Makes sense.

>
> The example of BUILTIN\Administrators make it easy to talk
> about. I propose that we automatically add 2 groups here
> at runtime (in memory). First create a new well know RID
> for 'Samba Admins'.  Say 900.  Always add
> LOCAL_SAM_SID-SAMBA_ADMIN_RID to the Administrators group.
> Then, if we are a domain controller or member server,  we
> add 'DOMAIN\Domain Admins' as well.

OK. No objection.

> Any BUILTIN groups the user was a member of (including due to
> group nesting) would be added to the user's NT_TOKEN at session
> setup time.

OK.

>
> Here's how this plays out for each of the three cases we are
> concerned about.
>
> Cases:
>
> * 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?

> The admin can however, manipulate the membership of the
> Domain Admins group so the BUILTIN\Administrator concept
> still works.
>
> * Member Server
>
> This works just like a Windows member server.  Domain Admins
> are in the administrator group. You just can't remove them.

That is not a problem.

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

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

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

	c) Automap all UNIX groups to Windows groups

Let smbd handle all of this. No need for Windbind.

In fact, my thinking is: If winbind is run we are not standalone.

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

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

>
> And if you've gotten this far....more coffee...*quick*

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

- John T.