[Samba] Re: Group membership

[John H Terpstra]

Folks,

Confusion on the subject of group mapping will continue until users learn to 
partition the problem into digestible chunks.

Windows has an entirely different administrative challenge compared with UNIX.
MS Windows separates the concept of administrative rights so that a local 
machine administrator on a domain member client (DMC) does NOT have any 
administrative rights within the security context of the domain of which that 
DMC is a member. The local DMC Administrator is never provided with 
membership of the Domain Admins group. The local DMC Administrator can 
disjoin a domain, but to join a domain requires the name and password of an 
account that has administrative privilege in the domain (ie: Domain Admin 
membership).

As the Windows client joins that domain to become a DMC, the Domain Admins 
group is added to the list of members of the Local Administrators group on 
the DMC. The Domain Administrator is a member of the Domain Admins group and 
thus gains the ability to administer DMCs.

The addition of DMCs to the domain requires administrator privilege. The 
management of users also requires administrative privilege. The purpose 
behind domain accounts is to provide a centrally managed database of user 
accounts, each with fine granularity of control over user rights and 
privileges. It is anathema to this design to add user accounts on DMCs.
It is unusual and to be discouraged to create Local Group accounts on DMCs, 
given that DMCs are usually simiply disposable work-stations.

The case of a domain member server (DMS) is very different. One should never 
create user accounts on the local DMS - instead all access to a DMS is done 
by users using their domain user account. It is good practice to create Local 
Group accounts on a DMS. Domain users and groups are then made members of the 
Local Groups. File system ACLs can then be set so that such Local Group 
ownership is inherited below certain directories. This is a primary mechanism 
by which file ownership integrity can be maintained when a DMS is disjoined 
from a domain. If this is NOT done, all files and directories that were owned 
by domain users and domain groups will be owned by the "Account Unknown" 
entity following the disjoining of the DMS from the domain.

Now consider the case of UNIX. Every machine is an island! The 'root' user is 
autonomous in scope, and is more like the Local Administrator on a DMC.
The management of user and group accounts requires 'root' privilege.

When you assign you group mappings thin in terms of:
	a) What privilege is needed to perform the task in mind on a DMC
	b) What privilege is needed to do this in the domain security context
	c) What privilege is needed to do this on UNIX

So here is a very simple set of guidelines:

1. If you want a domain user to have local admin rights on a DMC
	- Add this domain user to the local DMC Administrators group
	or add him/her to the local Power Users group.

	PS: There is no Domain Power Users group!

	- Alternately, create a domain group and add that group to the
	Local Administrators group or to the Local Power Users group on
	every DMC. Any user who has membership in this group will then
	have admin rights on DMCs.

2. If you want to give a user admin rights in the domain, make them a member 
of the Domain Admins group.

3. If you want the Domain Admins group to be able to manage your Samba servers 
you must ensure that this group, or its members, somehow maps to the user 
'root' or the group 'root' (GID=0, on some systems this maps to the group 
'wheel').

You can either map "Domain Admins" to the GID=0 group on the UNIX system, or 
as explained below, you can do this using the "admin users" parameter in the 
smb.conf global section.

You have choice in how UNIX admin capability is provided for domain users. 
There are no right or wrong choices - but there are solutions that do or do 
not work. If you fail to think through the chain of rights and privileges as 
a user passes from a DMC to the domain then through to Samba and the UNIX OS 
that hosts it, you will find the result frustrating. But if you can figure 
out the simple steps from one point to another the solution is simple and 
frustration will be avoided.

If someone would care to review the appropriate chapters of the 
Samba-HOWTO-Collection and suggest updates I will be happy to incorporate 
them into the document.

- John T.


On Sunday 17 October 2004 05:29, Gémes Géza wrote:
> Hi everybody,
>
> > Ok, the logic goes like this...
> >
> > If you want to use root for Domain administration purposes it has to
> > be in the Domain user database.
> > If it's a Domain user its primary group should be a Domain group.
> > All Domain groups in Samba are mappings from UNIX groups into SIDs.
> > If mapping for a particular gid is not present it will be created
> > automatically using arithmetic approach.
> >
> > Therefore, if you want your root user to keep its primary gid but to
> > be associated with a Domain group 'Domain Admins' the best approach
> > will be to map this Domain group into UNIX group 'root' instead of
> > creating additional UNIX group 'Domain Admins'.
> >
> > Another approach will be to use some other user to administer your
> > Domain and put it into 'admin users' list in smb.conf then you will be
> > free to choose any primary group for it you like just keep the
> > consistency between gidNumber and sambaPrimaryGroupSID. All users in
> > the 'admin users' list are forced into been root when they access
> > Samba so you will have the same control you would have with root.
>
> Some things to note here:
> admin users is not generally the same as domain admins.
> Members of the domain admin group will have administrator privileges on
> a Windows (NT based) workstation, but no special rights on the Samba
> shares, nor the right to manipulate the users, groups, or machines,
> databases.
> Members of the admin users will be able to act as root to Samba (all
> privileges), but not necessary to be administrators, for the Windows
> workstations, only if they are also members of the Domain Admins group.
>
> I steel have some things not very clear to me: can I have a group added
> to admin users in the global section, while in the share definitions
> specify another admin users (e.g. admin users = root), limiting in this
> way their access to other users data, while giving them the possibility,
> to join machines to the domain?
>
> > I don't know why this is not documented... I don't read documentation
> > that often.. I do know though that Samba team welcomes all suggestions
> > to make documentation better. If you know which part of the
> > documentation got you confused - let them know how to make it more clear.
> >
> > Hope it helps,
> > Igor
>
> Thanks,
>
> Geza

-- 
John H Terpstra
Samba-Team Member
Phone: +1 (650) 580-8668

Author:
The Official Samba-3 HOWTO & Reference Guide, ISBN: 0131453556
Samba-3 by Example, ISBN: 0131472216
Hardening Linux, ISBN: 0072254971
OpenLDAP by Example, ISBN: 0131488732
Other books in production.