if you are not using the latest cvs code and do not intend to, please
ignore this message. if you are following the SAMBA_2_0 tag, not the
main-line branch, please ignore this message. if you are currently not
prepared to move to the new parameters, please stay with the SAMBA_2_0 tag
or with the latest stable release of samba. if you wish to try out the
latest experimental code, please read on...
please be advised that, as mentioned two or more weeks ago, a group
database API has been added. the following (temporary) parameters have
therefore been removed:
"domain admin users"
"domain guest users"
"domain groups"
"domain admin group"
"domain guest group"
and these have been replaced with (ALSO subject to change):
"local group map" - maps SAM aliases in any domain to real unix groups
"domain group map" - maps SAM groups in any domain to real unix groups
note that "any domain" currently means "only the domain the SAMBA
server
is either a member of or responsible for".
the syntax of entries is:
unixgroupname [DOMAIN\]ntgroupname
unixgroupname [DOMAIN\]ntaliasname
where [DOMAIN\] is currently unsupported. if [DOMAIN\] is unspecified,
then the default is either the domain for which the samba server is a
controller (security = user) or the domain of which the samba server is a
member (security = domain).
"smb passgrp file" - extension to smbpasswd, allows users to be
members of
SAM groups and aliases. default name is:
/usr/local/samba/private/smbpassgrp
the syntax of entries is:
username:uid:alias1, alias2, ...:group1, group2, ...:
where:
- username and uid match exactly with the private/smbpasswd file
- groupN is either a rid (NNN or 0xXXX) or a SAM group name (NOT a unix
group name ). these are ONLY supported when samba is a PDC, as when samba
is a member of a domain then the private/smbpasswd and private/smbpassgrp
files actually become a set of _local_ workstation accounts (a local
workstation SAM database). under these circumstances (member of domain),
then "domain groups" simply do not exist in the local SAM, period.
the
only way to get "domain groups" is to use those on the PDC, for which
workstations are NOT responsible, so the issue of making a workstation
responsible for "domain groups" becomes a non-issue. hm. maybe i
should
re-state that, but i'm sure that the ensuing debate will clarify this.
- aliasN is either a SID (e.g S-1-5-20-512, S-1-5-21-x-y-z-1029) or a SAM
alias name (NOT a unix group name)
note that:
- when a user is added to a domain group, they can only be added to a
domain group in the domain, NOT a foriegn domain (that is what aliases are
for).
- when a user is added to a local group (alias), the full SID must be
specified. aliases can then have domain groups from foriegn domains added
to them.
in other words, administrators are advised to become familiar with NT
account management _before_ attempting to set this up. if you become
familiar with SAM administration (because that's what samba is starting to
support) then it will make understanding of how this maps onto UNIX a lot
easier.
