BUILTIN\{Administrators,Users}

[Gerald (Jerry) Carter]

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

Finally picking back up on this....

Volker Lendecke wrote:
> On Sat, Feb 25, 2006 at 10:35:30AM -0600, Gerald (Jerry) Carter wrote:
>> My idea is to have 'winbind nested groups = yes'
>> automatically create a mapping for the Administrators
>> and Users BUILTIN groups.  Then we can simply add
>> The corresponding domain groups to the correct BUILTIN
>> group as part of the join process.  We can do the
>> same for a Samba DC.
> 
> "create a mapping" implies that we find a unix-gid for the
> BUILTIN alias. Out of the blue this only works with winbind
> around, that's the only one who can allocate gids. Without
> we just can't map Users and Administrators.

True.

> We have two uses for the BUILTIN groups: One is for our
> internal se_access_check. This only looks at the SIDs in the
> token. The other one is to make use of unix access
> permissions. For the latter one we need a gid, for the
> former we don't.
> 
> The main reason you cite is that you want to make full use
> of security descriptors on registry objects & friends and
> not look at for example geteuid() anymore. Right? For this
> use it is fully sufficient to just add the S-1-5-32-xx to
> the token upon login time, there's no need to actually have
> a mapping. So we could even use that with 'winbind nested
> groups = no', as it happens with your trick to add
> builtin\admins if we're a domain admin.
> 
> What do you think about a policy where if the two BUILTIN
> groups are not explicitly defined as mappings by the admin,
> apply default memberships. I could imagine your domain
> admins group as well as having geteuid()==0 to qualify to be
> in BUILTIN\Administrators.

OK.  Let me summarize.  In the absence of a mapping from
S-1-5-32-544 to a gid, we simply apply a default group
membership which would be 'root' and if we are joined to
or controlling a domain the 'Domain Admins' group also.

If a sysadmin wants to manipulate the group membership,
then winbindd must be running and the SID must resolve to
a gid.  From that point, we ismply use the 'winbind nested
groups' functionality.

> What do you need BUILTIN\Users for? Isn't this more like
> S-1-5-11 (Authenticated Users)? In what security descriptors
> do you have those?

I don't really have a current need for BUILTIN\Users so we
can drop that one.  I was just thinking of a general framework
for the BUILTIN principals.  But the method described could
apply to BUILTIN\Users as well.

> If BUILTIN\Administrators is explicitly mapped, then give
> the admin full control. Irrespective of 'winbind nested
> groups = yes/no' do not look at Domain Administrators or
> geteuid()==0 but strictly follow who's in the group.

I'm not sure I follow that first sentence.  For access checks
on NT security objects (services, registry key, & printers),
I would prefer to just use the NT_USER_TOKEN which means
that it doesn't really matter if Administrators is mapped to
a valid gid or not.

> For legacy reasons I would regard a mapping to gid -1 to not
> exist. In this case we should fall back to the defaults.

Agreed.
> 
>> As a side note regarding nested groups, we need to
>> preface the local group name with "MACHINENAME" due
>> to ambiguity when 'winbind use default domain' is
>> enabled.  This might not be the case when we move the
>> 'default domain' logic into the winbind Unix client
>> code (i.e. wbinfo, ntlm_auth, libnss_winbind.so).
>> Have we done that already?  It's been a while since I
>> looked.
> 
> No, haven't come around yet to do anything about it.

I'll work on fixing this then.  Should be pretty quick.







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

iD8DBQFEEYuEIR7qMdg1EfYRAv26AKDIX+h9lpNCKq3B+67nrLQY577BVgCgwUtG
UQTtp3SKv8reRSYyz6wqaUs=
=ptMx
-----END PGP SIGNATURE-----