Volker.Lendecke at SerNet.DE
Sun Mar 12 15:05:45 GMT 2006
On Fri, Mar 10, 2006 at 08:21:56AM -0600, Gerald (Jerry) Carter wrote:
> 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.
Yes, that's my idea.
> > 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.
True. But for for the 'restrict anonymous' stuff s-1-5-11
seems more appropriate for me. But I'm fine with some
defaults for BUILTIN\Users.
> > 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
I meant that the human administrator of the box should have
full control over who is member of S-1-5-32-544, I don't
want any magic memberships :-)
> 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.
Full ack :-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20060312/33cffd36/attachment.bin
More information about the samba-technical