removing BUILTIN from winbind nested groups ?

Gerald (Jerry) Carter jerry at samba.org
Thu Jun 16 18:15:44 GMT 2005


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

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.

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.

(2) make 'enable net groupmap' and 'winbind nested groups'
mutually exclusive.  The former would be a new smb.conf option.
This means that winbindd no longer has to store stick its
fingers in the passdb backend.  It also means that you can
have replicated nested groups.

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

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.

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.

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.

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

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


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.

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?

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




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

iD8DBQFCscHQIR7qMdg1EfYRAgRAAJwJ6aeM3A2ihA1XC9IdgTAIVE00JQCgjoy1
5AkmrwWU22kwXiA7qcMWIro=
=W2+r
-----END PGP SIGNATURE-----


More information about the samba-technical mailing list