domain group and local group API needed

[Luke Kenneth Casson Leighton]

On Thu, 29 Oct 1998, Jeremy Allison wrote:

> Luke Kenneth Casson Leighton wrote:
> > 
> > 
> > that would confuse the issue.  a user's groups is a list of RIDs.  those
> > RIDs can be either local groups or domain groups.  a name of "domain group
> > file" would imply that it is not possible to have users in local groups.
> > 
> > plus, if we name it "domain group file" then we really need "smb password
> > file" to be renamed "domain password file".
> > 
> > plus, in the case of when you are a member of a domain, this option still
> > has relevance
> > 
> > in this case:
> > 
> > - the smb passwd file becomes a list of local accounts
> > - the smb group file can contain only local groups (no domain groups).
> > 
> 
> But that is the purpose of the UNIX /etc/group file. You
> do not need another group file in the "member of a domain"
> case.

ok, then we have two password database API implementations, already :-)

1) private/smbgroup
2) /etc/group

i now have one "semi" working, it's cool :)  i had to fudge srv_lsa.c's
lookupnames code...
 
> Remember, in the case of a Samba server which is a member
> of a domain, the UNIX /etc/group file (or whatever remote
> queried equivalent) specifies what groups a particular
> user is in. It is this group list that is used by Samba
> to setgroups() to when Samba becomes the UNIX uid for
> that user. It is this group that defines the access
> permissions for smbd on behalf of that user. All the
> groups in that list are, by definition, groups *local*
> to that UNIX server.
> 
> Samba servers that are members of a domain can have
> no concept of "Domain" groups - such a thing simply
> doesn't exist in UNIX.

that is absolutely correct: the concept does not exist on unix.
_however_, that has nothing to do with us letting samba administrators
split "unix" groups up into two categories:

- unix groups which, through samba and the use of the "map domaingroup
file" parameter tell NT wkstas that the unix group looks like, to the NT
wksta, as if it is a "domain group".

this, as i think you are going point out below, is only possible when
samba is in "PDC" mode not "member of domain" mode.

- unix groups which, through samba and the use of the "map localgroup
file" parameter tell NT wkstas that the unix group looks like, to the NT
wksta, as if it is a "local group".  this can even fool NT workstations
into thinking that the unix group is in a totally different NT domain.

this option can be used in both PDC and member modes, and is in fact the
only option available in "member" mode.

BOTH these categories map onto REAL, LOCAL, unix groups, and yes, unix
knows absolutely nothing about what a local group or a domain group is,
doesn't care, doesn't matter, is completely irrelevant etc etc and _still_
doesn't affect the fact that we can fool NT machines into thinking that
local and/or domain groups exist.

> The original idea of the "groupname map" code was
> to allow the UNIX /etc/groups database to be the
> master group file for a system. 

ah.

there are actually two sets of functionality required, with two categories
in each:

- unix to nt group-fooling-code ( :-) )

the two categories are: local groups and domain groups.  in each category,
the mapping required is:

local_unix_group	DOMAIN_NAME\group name

that means that, for any given local group or domain group, in any given
domain, you can fool NT machines into thinking that such a concept exists,
and the unix security model still stands up.


i have modified smbd/groupname.c to be able to do the above.

- SAM database groups

the two categories, again, are: local groups and domain groups.

in the local group category, the entries in each local group are:
SID	DOMAIN_NAME\group name	sid_name_use

in the domain group category, the entries are:
USER rid	group name

this is completely independent of the above "group-fooling" system.


i have to do some more thinking, ok, about what the issues are.  get a
clear picture of the components etc.