removing BUILTIN from winbind nested groups ?

[Volker Lendecke]

Hi, Jerry!

Hi, Jerry!

You might want to read the last few paragraphs of this mail first... :-)

On Thu, Jun 16, 2005 at 01:15:44PM -0500, Gerald (Jerry) Carter wrote:
> 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.

To be honest, I don't really understand in enough detail what you want to
achieve.

> (1) move support for BUILTIN groups internally to smbd.  Create
> default memberships in the builtin groups.

By default memberships you mean they are not changeable or are fixed based on
our server role?

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

What does it mean to have 'enable net groupmap = no'? Does "net groupmap" mean
only the mapping of global group sids to unix ids and vice versa? Or do you
mean with 'enable net groupmap = no' to disable the legacy and wrong way to
overload the groupmap object with nested groups?

If we find another representation for nested groups, we still need to put them
into passdb for DC replication via LDAP.

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

Hmm. I don't get that one. There's only two types of groups: SID_NAME_DOM_GRP
and SID_NAME_ALIAS. I'm still really puzzled where SID_NAME_WKN_GRP came from,
I have never seen this on the wire.

vlendec at delphin:~> rpcclient w2003dc -U vl%asdf -W w2k3ad -c 'lookupsids s-1-5-32-544'
S-1-5-32-544 VORDEFINIERT\Administratoren (4)

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

winbind nested groups != domain groups

Domain local groups need to be supported. Even if they are not too important
for pure Unix shops, dropping nested groups on DCs would kill a big share of
all migration scenarios. Nested groups in a pure NT environment are not
exported to members, but they are shared between the DCs. And when admins need
domain wide nested groups, they install another BDC instead of a member.

They are relevant in two calls: SamLogon type 6, we don't do that in our
netlogon server and we get away with it as NT does not do that either. But XP
tends to do the lookup_useraliases with the list of sids in the info3 struct
right after the samlogon, so domain local groups are faked by XP in a NT
domain.

> The admin can however, manipulate the membership of the
> Domain Admins group so the BUILTIN\Administrator concept
> still works.

Ack.

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

Again, I don't really see what you mean with 'net groupmap' in this context.

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

You have to decide: Is LOCAL_SAM_SID-SAMBA_ADMIN_RID a nested group or not? 

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

I fully agree that this needs fixing.

> 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 just wondered where your problem really is and what you need the
LOCAL_SAM_SID-SAMBA_ADMIN_RID for.

If you remove expansion of BUILTIN from winbind, nss would not see it
anymore. Fine. We could make BUILTIN a smbd only thing and have these
correctly expanded somewhere in make_server_info. winbind would take care of
aliases in LOCAL_SAM_SID. When the token as seen by winbind (or without
winbind, the token as seen by nss and algorithmic mapping) is finished, the
last thing for smbd to add is the SIDs from BUILTIN memberships. As they don't
show up in nss anymore, we don't have to do the sid2gid for those, they just
augment the nt part of the token.

This way root can freely add any SID to BUILTIN\Administrators and your
security descriptor perfectly applies, even without winbind around.

What am I missing??

Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20050617/b2c44d9a/attachment.bin