domain group and local group API needed
Luke Kenneth Casson Leighton
lkcl at switchboard.net
Fri Oct 30 16:28:28 GMT 1998
long, involved, important response.
On Fri, 30 Oct 1998, Kyle McDonald wrote:
> Hi all.
> I may be about to open my mouth and insert my foot, but here
> it goes anyway.
> I thought I might be a good judge on what the "average user"
> might interpret these options to mean - considering I am
> very new to this whole SAMBA thing...
> so here's my two cents:
> It seems(from my reading so far) that these are the desired
> functionality, even if these are not the current names:
> local user map =
> domain user map =
you also need "trust domain user map =".
you can "combine" these by extending "map username" functionality to:
DOMAIN_NAME\user = unix_usr
WKSTA_NAME\user = unix_usr2
TRUSTED_DOM\user = unix_usr3
TRUSTED_DOM2\user = unix_usr4
> local group map =
> domain group map =
you also need, in the same way:
trusted dom,ain local group map =
trusted domain domain group map =
workstation local group map =
YOU CANNOT HAVE: workstation domain group map = - the workstation SAM does
not support domain groups, try running MUSRMGR.EXE and tell me if you
ever see a domain group or anythin other than local users :-)
and again, all these can be "combined" into a local goup map and domain
group map by allowing
DOMAIN_NAME\local_group = unix_group1
WKSTA_NAME\local_group = unix_group2
and by allowing
DOMAIN_NAME\domain_group = unix_group5
TRUSTED_DOM\domain_group = unix_group6
and by *disallowing*
WKSTA_NAME\domain_group = unix_group7
> These all seem straight forward so far. they seem to cover all
> of the mapping options needed.
yes, they do, as far as i can make out.
> As for the files, It seems that the desired functionality
> would include: (again some of these may exist, some may not)
> local user file =
> domain user file =
in the case where samba = PDC, these are the same.
in the case where samba = domain-member ("security = domain"), the "local
user map" = private/smbpasswd, with usernames in private/smbpasswd being
verified against /etc/passwd. the "domain user map" = _the pdc's domain
users_ being verified against /etc/passwd. and, what is important is that
this situation need not change.
can anyone, however, spot the mistake in the "security = domain" case?
that when accessing a "domain" user or a when accessing a "local" user
(which are equivalent to logging in to the "domain" and logging into the
"workstation" respectively), it is possible that the may be mapped to the
same entry in /etc/passwd, if there exists and acount DOMAIN_NAME\fred and
this is a mistake, and i hope to rectify it by extending the "map
username" functionality to be able to specify DOMAIN_NAME\fred = fred2.
yes, it's horrible: it's also the same problem as with trusted domains.
> local group file =
> domain group file =
i _think_.... i _think_ you can only add "rids" to a user.
theeerreforrre... you only need "group file = private/smbgroup".
see, what it means is that if you want a user to belong to another
domain's group(s), you must create a "local group"; add the foriegn group
to the "local group" and then add the local group to the user's groups.
_now_ i finally understand why the SAM database calls these "Aliases",
vecause you have to have "aliases" for foriegn groups in order to add
users to those forieng groups (indirectly).
now. if we allow people to put users into arbitrary groups in /etc/group,
some of those groups are going to be mapped to "foriegn" groups, whether
they be domain, local, trusted domain, workstation groups etc etc. this
will be a potential source of configuration mistakes.
however, if we get people to put entries in private/smbgroup, and say "you
will put NT names in here not unix names", then there is less temptation
to put TRUSTED_DOMAIN\group_name in private/smbgroup, and we can detect
this easily and point out in log file messages that this is a problem.
explaining in log file messages that "hey, you put someone in a unix
group, and that unix group is actually mapped to a
TRUSTED_DOMAIN\group_name and i'm sorry, you can't do that, you must only
put users into groups that i can map to a rid of your own domain"...
you get the picture? using unix /etc/group there is a level of
indirection that you cannot really explain in a simple manner, because
/etc/group could potentially be used to map hundreds of different groups
across many different domains: private/smbgroup should be used to map
hundreds of different groups across only _one_ domain: the one that the
samba server is responsible for.
i'm not saying that we shouldn't do it, i'm just saying that if we do,
it's going to create us a configuration nightmare (my user can't join a
group in another domain, i've tried adding it to /etc/group and it doesn't
work: what am i doing wrong?)
> Considering that all users have to be in both the unix passwd
> file and the smbpasswd file, I think it might be good to
> follow the same logic with having all the groups in both
> the unix group file and an smbgroup file.
yes. well, actually, all users in smbpasswd have to be in the unix
passwd, but not vice-versa. the same should apply to smbgroup and grou.
> The confusing part will be when the smbgroup file puts a user
> in one set of groups which map to one set of unix groups, and
> the unix group file puts the user into another (possibly
> overlapping) set of unix groups.
this will be a configuration error, and i will have to detect it and throw
a log message.
> But I do see the point of letting an administrator get all
> of the functionality of a real NT server.
particularly as i intend to have "USRMGR.EXE" manage all this, so if you
can use "USRMGR.EXE" and you can live with having some errors thrown up if
you haven't got your /etc/group and "map local group" and "map domain
group" parameters set up...
oh, in "appliance" mode, those errors would not occur, by the way.
> The last question remaining seems to be do you really need
> to make the local and domain distinctions in each of these
yes, very much so (except for PDC mode, in which "local user file ==
domain user file").
> In the case of the user and group files, might it not be
> possible to add a field which specified if the user (or group)
> was for the domain or only the local machine?
um... with respect to user files, i think i covered this: if you are a
PDC, there _Are_ no local machine users; if you are not a PDC, you are
_not_ responsible for the domain users, the PDC is, you are only
responsible for local users, so there is no problem.
i think the same logic applies to the local group files and also to the
domain group files: you simply aren't responsible for anyone elses'
accounts except your own.
please, please please bear in mind that there are two totally separate
- creating a SAM database (users,groups - domain and local), whether it's
local-machine-sam or a domain-sam
- mapping arbitratry DOMAIN_NAME\rid (or SID-rid) stuff into the UNIX
> In the case of the user and group maps, I'm not sure you even
> need this distinction.
i think you are confusing the two issues i just mentioned above.
> Can't a unix group only map to one
correct, and it's a configuration error if you use "local domain map=" and
"domain map =" to produce a non-monotonic mapping.
> does it matter (during the mapping) if that group
> is local or domain?
yes. if you want to avoid massive configuration problems.
> I think (and I might be wrong) that you can't have a local
> users or group with the same name as a domain user or group -
absolutely correct. the namespace must be unique, in a particular
- local groups
- domain groups
i just tried it out: i tried adding a group with the same name as a user,
the same name as a local group etc etc: it failed.
> and if if you can, I don't know if it makes much sense to do
it certainly does not, i agree.
> Therefore you should be able to map a unix user or group
> to a SMB user or group with out specifying wether it is local
> or domain...
this does not follow
> Let the new field, or which ever file it is found
> in determine that.
however, this does :-)
> This would leave you with:
> user map =
> group map =
> user file =
> group file =
this works if you have the "field" you propose.
> ( and I might suggest using db instead of file )
this is something else under consideration.
> Now, I could be totally off my rocker. and maybe I've missed
> a totally important idea in here somewhere, but This is my
> novice view point of how I would expect these settings to work.
you're pretty much on the mark, and you made me think of a couple of valid
points. so, thanks.
More information about the samba-technical