[Samba] Re: Group membership

[Gémes Géza]

Hi,

I've read it a few times, however for the special case I would like to 
implement:
members of the adm group (mapped to Domain Admins, but that is not 
important for what I ask) act as root globaly, as such they can 
manipulate user and group databases (what I intend is to allow them is 
joining machines to the domain, and I will eventualy broke Windows user 
and group manipulating functionality specifying some invalid add user, 
add group etc. scripts), but have normal user privileges when they 
connect to any share.
So my question is will this work if I specify
[global]
...........
admin users = root, at adm
...........
[share]
...........
admin users = root
...........
?

Thanks in advance

Geza Gemes

>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
>>    
>>
>
>  
>