From 8f8a9f01909ba29e2b781310baeeaaddc3f15f0d Mon Sep 17 00:00:00 2001 From: "Gerald W. Carter" Date: Tue, 22 Apr 2008 10:09:40 -0500 Subject: Moving docs tree to docs-xml to make room for generated docs in the release tarball. (This used to be commit 9f672c26d63955f613088489c6efbdc08b5b2d14) --- docs-xml/Samba3-HOWTO/TOSHARG-Group-Mapping.xml | 920 ++++++++++++++++++++++++ 1 file changed, 920 insertions(+) create mode 100644 docs-xml/Samba3-HOWTO/TOSHARG-Group-Mapping.xml (limited to 'docs-xml/Samba3-HOWTO/TOSHARG-Group-Mapping.xml') diff --git a/docs-xml/Samba3-HOWTO/TOSHARG-Group-Mapping.xml b/docs-xml/Samba3-HOWTO/TOSHARG-Group-Mapping.xml new file mode 100644 index 0000000000..337ae3d794 --- /dev/null +++ b/docs-xml/Samba3-HOWTO/TOSHARG-Group-Mapping.xml @@ -0,0 +1,920 @@ + + + + + &author.jht; + + Jean FrançoisMicouleau + + &author.jerry; + +Group Mapping: MS Windows and UNIX + + + +groupsmapping +SID +associations +UNIX groups +groupmap +net + Starting with Samba-3, new group mapping functionality is available to create associations + between Windows group SIDs and UNIX group GIDs. The groupmap subcommand + included with the &net; tool can be used to manage these associations. + + + +group mapping +domain groups + The new facility for mapping NT groups to UNIX system groups allows the administrator to decide + which NT domain groups are to be exposed to MS Windows clients. Only those NT groups that map + to a UNIX group that has a value other than the default (-1) will be exposed + in group selection lists in tools that access domain users and groups. + + + + + domain admin group +Windows group + The domain admin group parameter has been removed in Samba-3 and should no longer + be specified in &smb.conf;. In Samba-2.2.x, this parameter was used to give the listed users membership in the + Domain Admins Windows group, which gave local admin rights on their workstations + (in default configurations). + + + + +Features and Benefits + + + Samba allows the administrator to create MS Windows NT4/200x group accounts and to + arbitrarily associate them with UNIX/Linux group accounts. + + + + UID + GID + idmap uid +MMC +winbindd +ID range +group accounts + Group accounts can be managed using the MS Windows NT4 or MS Windows 200x/XP Professional MMC tools. + Appropriate interface scripts should be provided in &smb.conf; if it is desired that UNIX/Linux system + accounts should be automatically created when these tools are used. In the absence of these scripts, and + so long as winbindd is running, Samba group accounts that are created using these + tools will be allocated UNIX UIDs and GIDs from the ID range specified by the + / + parameters in the &smb.conf; file. + + +
+ IDMAP: Group SID-to-GID Resolution. + idmap-sid2gid +
+ +
+ IDMAP: GID Resolution to Matching SID. + idmap-gid2sid +
+ + + IDMAP +SID-to-GID +netgroupmap +group mappings + In both cases, when winbindd is not running, only locally resolvable groups can be recognized. Please refer to + IDMAP: Group SID-to-GID Resolution and IDMAP: GID Resolution to Matching SID. The net groupmap is + used to establish UNIX group to NT SID mappings as shown in IDMAP: storing + group mappings. + + +
+ IDMAP Storing Group Mappings. + idmap-store-gid2sid +
+ + + groupadd + groupdel +shadow utilities +groupmod + Administrators should be aware that where &smb.conf; group interface scripts make + direct calls to the UNIX/Linux system tools (the shadow utilities, groupadd, + groupdel, and groupmod), the resulting UNIX/Linux group names will be subject + to any limits imposed by these tools. If the tool does not allow uppercase characters + or space characters, then the creation of an MS Windows NT4/200x-style group of + Engineering Managers will attempt to create an identically named + UNIX/Linux group, an attempt that will of course fail. + + + + GID + SID + There are several possible workarounds for the operating system tools limitation. One + method is to use a script that generates a name for the UNIX/Linux system group that + fits the operating system limits and that then just passes the UNIX/Linux group ID (GID) + back to the calling Samba interface. This will provide a dynamic workaround solution. + + + +netgroupmap + Another workaround is to manually create a UNIX/Linux group, then manually create the + MS Windows NT4/200x group on the Samba server, and then use the net groupmap + tool to connect the two to each other. + + + + + +Discussion + + +Windows NT4/200x +group privileges + When you install MS Windows NT4/200x on a computer, the installation + program creates default users and groups, notably the Administrators group, + and gives that group privileges necessary to perform essential system tasks, + such as the ability to change the date and time or to kill (or close) any process running on the + local machine. + + + + Administrator + The Administrator user is a member of the Administrators group, and thus inherits + Administrators group privileges. If a joe user is created to be a member of the + Administrators group, joe has exactly the same rights as the user + Administrator. + + + +domain member +Domain Admins +inherits rights +PDC + When an MS Windows NT4/200x/XP machine is made a domain member, the Domain Admins group of the + PDC is added to the local Administrators group of the workstation. Every member of the + Domain Admins group inherits the rights of the local Administrators group when + logging on the workstation. + + + +Domain Admins +PDC + The following steps describe how to make Samba PDC users members of the Domain Admins group. + + + + + Create a UNIX group (usually in /etc/group); let's call it domadm. + + + +/etc/group + Add to this group the users that must be Administrators. For example, + if you want joe, john, and mary to be administrators, + your entry in /etc/group will look like this: + + + + domadm:x:502:joe,john,mary + + + + + Map this domadm group to the Domain Admins group by executing the command: + + + + +&rootprompt;net groupmap add ntgroup="Domain Admins" unixgroup=domadm rid=512 type=d + + + + + Domain Admins group + The quotes around Domain Admins are necessary due to the space in the group name. + Also make sure to leave no white space surrounding the equal character (=). + + + + + Now joe, john, and mary are domain administrators. + + + + groupsdomain + It is possible to map any arbitrary UNIX group to any Windows NT4/200x group as well as + to make any UNIX group a Windows domain group. For example, if you wanted to include a + UNIX group (e.g., acct) in an ACL on a local file or printer on a Domain Member machine, + you would flag that group as a domain group by running the following on the Samba PDC: + + + + +&rootprompt;net groupmap add rid=1000 ntgroup="Accounting" unixgroup=acct type=d + + The ntgroup value must be in quotes if it contains space characters to prevent + the space from being interpreted as a command delimiter. + + + +RID +assigned RID + Be aware that the RID parameter is an unsigned 32-bit integer that should + normally start at 1000. However, this RID must not overlap with any RID assigned + to a user. Verification for this is done differently depending on the passdb backend + you are using. Future versions of the tools may perform the verification automatically, + but for now the burden is on you. + + + + Warning: User Private Group Problems + + +group accounts +Red Hat Linux +private groups + Windows does not permit user and group accounts to have the same name. + This has serious implications for all sites that use private group accounts. + A private group account is an administrative practice whereby users are each + given their own group account. Red Hat Linux, as well as several free distributions + of Linux, by default create private groups. + + + +UNIX/Linux group +Windows group + When mapping a UNIX/Linux group to a Windows group account, all conflict can + be avoided by assuring that the Windows domain group name does not overlap + with any user account name. + + + + + + Nested Groups: Adding Windows Domain Groups to Windows Local Groups + + groupsnested + + +nested groups + This functionality is known as nested groups and was first added to + Samba-3.0.3. + + + +nested groups + All MS Windows products since the release of Windows NT 3.10 support the use of nested groups. + Many Windows network administrators depend on this capability because it greatly simplifies security + administration. + + + +nested group +group membership +domain security +domain member server +local groups +domain global groups +domain global users + The nested group architecture was designed with the premise that day-to-day user and group membership + management should be performed on the domain security database. The application of group security + should be implemented on domain member servers using only local groups. On the domain member server, + all file system security controls are then limited to use of the local groups, which will contain + domain global groups and domain global users. + + + +individual domain user +domain group settings +Account Unknown + You may ask, What are the benefits of this arrangement? The answer is obvious to those who have plumbed + the dark depths of Windows networking architecture. Consider for a moment a server on which are stored + 200,000 files, each with individual domain user and domain group settings. The company that owns the + file server is bought by another company, resulting in the server being moved to another location, and then + it is made a member of a different domain. Who would you think now owns all the files and directories? + Answer: Account Unknown. + + + +directory access control +local groups +ACL +Account Unknown + Unraveling the file ownership mess is an unenviable administrative task that can be avoided simply + by using local groups to control all file and directory access control. In this case, only the members + of the local groups will have been lost. The files and directories in the storage subsystem will still + be owned by the local groups. The same goes for all ACLs on them. It is administratively much simpler + to delete the Account Unknown membership entries inside local groups with appropriate + entries for domain global groups in the new domain that the server has been made a member of. + + + +nested groups +administrative privileges +domain member workstations +domain member servers +member machine +full rights +Domain Admins +local administrative privileges + Another prominent example of the use of nested groups involves implementation of administrative privileges + on domain member workstations and servers. Administrative privileges are given to all members of the + built-in local group Administrators on each domain member machine. To ensure that all domain + administrators have full rights on the member server or workstation, on joining the domain, the + Domain Admins group is added to the local Administrators group. Thus everyone who is + logged into the domain as a member of the Domain Admins group is also granted local administrative + privileges on each domain member. + + + +nested groups +auxiliary members +/etc/group +winbind + UNIX/Linux has no concept of support for nested groups, and thus Samba has for a long time not supported + them either. The problem is that you would have to enter UNIX groups as auxiliary members of a group in + /etc/group. This does not work because it was not a design requirement at the time + the UNIX file system security model was implemented. Since Samba-2.2, the winbind daemon can provide + /etc/group entries on demand by obtaining user and group information from the domain + controller that the Samba server is a member of. + + + +/etc/group +libnss_winbind +local groups +Domain Users +alias group + In effect, Samba supplements the /etc/group data via the dynamic + libnss_winbind mechanism. Beginning with Samba-3.0.3, this facility is used to provide + local groups in the same manner as Windows. It works by expanding the local groups on the + fly as they are accessed. For example, the Domain Users group of the domain is made + a member of the local group demo. Whenever Samba needs to resolve membership of the + demo local (alias) group, winbind asks the domain controller for demo members of the Domain Users + group. By definition, it can only contain user objects, which can then be faked to be member of the + UNIX/Linux group demo. + + + +nested groups +winbindd +NSS +winbind +local groups +Domain User Manager +netrpcgroup + To enable the use of nested groups, winbindd must be used with NSS winbind. + Creation and administration of the local groups is done best via the Windows Domain User Manager or its + Samba equivalent, the utility net rpc group. Creating the local group + demo is achieved by executing: + + &rootprompt; net rpc group add demo -L -Uroot%not24get + +addmem +delmem + Here the -L switch means that you want to create a local group. It may be necessary to add -S and -U + switches for accessing the correct host with appropriate user or root privileges. Adding and removing + group members can be done via the addmem and delmem subcommands of + net rpc group command. For example, addition of DOM\Domain Users to the + local group demo is done by executing: + + net rpc group addmem demo "DOM\Domain Users" + +getent group demo +trusted domain +foreign domain +local access permissions + Having completed these two steps, the execution of getent group demo will show demo + members of the global Domain Users group as members of the group + demo. This also works with any local or domain user. In case the domain DOM trusts + another domain, it is also possible to add global users and groups of the trusted domain as members of + demo. The users from the foreign domain who are members of the group that has been + added to the demo group now have the same local access permissions as local domain + users have. + + + + + + Important Administrative Information + + + Administrative rights are necessary in two specific forms: + + + + For Samba-3 domain controllers and domain member servers/clients. + To manage domain member Windows workstations. + + + +rights and privileges +domain member client +group account + Versions of Samba up to and including 3.0.10 do not provide a means for assigning rights and privileges + that are necessary for system administration tasks from a Windows domain member client machine, so + domain administration tasks such as adding, deleting, and changing user and group account information, and + managing workstation domain membership accounts, can be handled by any account other than root. + + + +privilege management +delegated +Administrator + Samba-3.0.11 introduced a new privilege management interface (see User Rights and Privileges) + that permits these tasks to be delegated to non-root (i.e., accounts other than the equivalent of the + MS Windows Administrator) accounts. + + + +mapped +Domain Admins + Administrative tasks on a Windows domain member workstation can be done by anyone who is a member of the + Domain Admins group. This group can be mapped to any convenient UNIX group. + + + + Applicable Only to Versions Earlier than 3.0.11 + + +privilege + Administrative tasks on UNIX/Linux systems, such as adding users or groups, requires + root-level privilege. The addition of a Windows client to a Samba domain involves the + addition of a user account for the Windows client. + + + +system security +privileges + Many UNIX administrators continue to request that the Samba Team make it possible to add Windows workstations, or + the ability to add, delete, or modify user accounts, without requiring root privileges. + Such a request violates every understanding of basic UNIX system security. + + + +privileges +/etc/passwd +Domain Server Manager +Domain User Manager +manage share-level ACL +share-level ACLs + There is no safe way to provide access on a UNIX/Linux system without providing + root-level privileges. Provision of root privileges can be done + either by logging on to the Domain as the user root or by permitting particular users to + use a UNIX account that has a UID=0 in the /etc/passwd database. Users of such accounts + can use tools like the NT4 Domain User Manager and the NT4 Domain Server Manager to manage user and group + accounts as well as domain member server and client accounts. This level of privilege is also needed to manage + share-level ACLs. + + + + + + + + Default Users, Groups, and Relative Identifiers + + + Relative IdentifierRID + RID +Windows NT4/200x/XP +well-known RID +domain groups +tdbsam +LDAP +NT groups + When first installed, Windows NT4/200x/XP are preconfigured with certain user, group, and + alias entities. Each has a well-known RID. These must be preserved for continued + integrity of operation. Samba must be provisioned with certain essential domain groups that require + the appropriate RID value. When Samba-3 is configured to use tdbsam, the essential + domain groups are automatically created. It is the LDAP administrator's responsibility to create + (provision) the default NT groups. + + + +default users +default groups +default aliases +RID + Each essential domain group must be assigned its respective well-known RID. The default users, groups, + aliases, and RIDs are shown in Well-Known User Default RIDs. + + + +passdb backend +LDAP +ldapsam +domain groups +RID + It is the administrator's responsibility to create the essential domain groups and to assign each + its default RID. + + + +domain groups +RID + It is permissible to create any domain group that may be necessary; just make certain that the essential + domain groups (well known) have been created and assigned their default RIDs. Other groups you create may + be assigned any arbitrary RID you care to use. + + + + Be sure to map each domain group to a UNIX system group. That is the only way to ensure that the group + will be available for use as an NT domain group. + + + + + Well-Known User Default RIDs + + + + + + + + Well-Known Entity + RID + Type + Essential + + + + + Domain Administrator + 500 + User + No + + + Domain Guest + 501 + User + No + + + Domain KRBTGT + 502 + User + No + + + Domain Admins + 512 + Group + Yes + + + Domain Users + 513 + Group + Yes + + + Domain Guests + 514 + Group + Yes + + + Domain Computers + 515 + Group + No + + + Domain Controllers + 516 + Group + No + + + Domain Certificate Admins + 517 + Group + No + + + Domain Schema Admins + 518 + Group + No + + + Domain Enterprise Admins + 519 + Group + No + + + Domain Policy Admins + 520 + Group + No + + + Builtin Admins + 544 + Alias + No + + + Builtin users + 545 + Alias + No + + + Builtin Guests + 546 + Alias + No + + + Builtin Power Users + 547 + Alias + No + + + Builtin Account Operators + 548 + Alias + No + + + Builtin System Operators + 549 + Alias + No + + + Builtin Print Operators + 550 + Alias + No + + + Builtin Backup Operators + 551 + Alias + No + + + Builtin Replicator + 552 + Alias + No + + + Builtin RAS Servers + 553 + Alias + No + + + +
+ + + + + + Example Configuration + + +netgroupmaplist + You can list the various groups in the mapping database by executing + net groupmap list. Here is an example: + + + +netgroupmap + +&rootprompt; net groupmap list +Domain Admins (S-1-5-21-2547222302-1596225915-2414751004-512) -> domadmin +Domain Users (S-1-5-21-2547222302-1596225915-2414751004-513) -> domuser +Domain Guests (S-1-5-21-2547222302-1596225915-2414751004-514) -> domguest + + + + + For complete details on net groupmap, refer to the net(8) man page. + + + + + + + +Configuration Scripts + + + Everyone needs tools. Some of us like to create our own, others prefer to use canned tools + (i.e., prepared by someone else for general use). + + + + Sample &smb.conf; Add Group Script + + + smbgrpadd.sh + groupadd limitations + smbgrpadd.sh +/etc/group +groupadd + A script to create complying group names for use by the Samba group interfaces + is provided in smbgrpadd.sh. This script + adds a temporary entry in the /etc/group file and then renames + it to the desired name. This is an example of a method to get around operating + system maintenance tool limitations such as those present in some version of the + groupadd tool. + +smbgrpadd.sh + +#!/bin/bash + +# Add the group using normal system groupadd tool. +groupadd smbtmpgrp00 + +thegid=`cat /etc/group | grep ^smbtmpgrp00 | cut -d ":" -f3` + +# Now change the name to what we want for the MS Windows networking end +cp /etc/group /etc/group.bak +cat /etc/group.bak | sed "s/^smbtmpgrp00/$1/g" > /etc/group +rm /etc/group.bak + +# Now return the GID as would normally happen. +echo $thegid +exit 0 + + + + + + The &smb.conf; entry for the above script shown in the configuration of + &smb.conf; for the add group Script demonstrates how it may be used. + + +Configuration of &smb.conf; for the add group Script + + +/path_to_tool/smbgrpadd.sh "%g" + + + + + + + + Script to Configure Group Mapping + + +initGroups.sh + In our example we have created a UNIX/Linux group called ntadmin. + Our script will create the additional groups Orks, Elves, and Gnomes. + It is a good idea to save this shell script for later use just in case you ever need to rebuild your mapping database. + For the sake of convenience we elect to save this script as a file called initGroups.sh. + This script is given in intGroups.sh. +initGroups.sh + +Script to Set Group Mapping + +#!/bin/bash + +net groupmap add ntgroup="Domain Admins" unixgroup=ntadmin rid=512 type=d +net groupmap add ntgroup="Domain Users" unixgroup=users rid=513 type=d +net groupmap add ntgroup="Domain Guests" unixgroup=nobody rid=514 type=d + +groupadd Orks +groupadd Elves +groupadd Gnomes + +net groupmap add ntgroup="Orks" unixgroup=Orks type=d +net groupmap add ntgroup="Elves" unixgroup=Elves type=d +net groupmap add ntgroup="Gnomes" unixgroup=Gnomes type=d + + + + + + Of course it is expected that the administrator will modify this to suit local needs. + For information regarding the use of the net groupmap tool please + refer to the man page. + + + + Versions of Samba-3 prior to 3.0.23 automatically create default group mapping for the + Domain Admins, Domain Users and Domain Guests Windows + groups, but do not map them to UNIX GIDs. This was a cause of administrative confusion and + trouble. Commencing with Samba-3.0.23 this annomaly has been fixed - thus all Windows groups + must now be manually and explicitly created and mapped to a valid UNIX GID by the Samba + administrator. + + + + + + + +Common Errors + + +At this time there are many little surprises for the unwary administrator. In a real sense +it is imperative that every step of automated control scripts be carefully tested +manually before putting it into active service. + + + + Adding Groups Fails + + +groupadd + This is a common problem when the groupadd is called directly + by the Samba interface script for the in + the &smb.conf; file. + + + +uppercase character +space character + The most common cause of failure is an attempt to add an MS Windows group account + that has an uppercase character and/or a space character in it. + + + +groupadd + There are three possible workarounds. First, use only group names that comply + with the limitations of the UNIX/Linux groupadd system tool. + Second, it involves the use of the script mentioned earlier in this chapter, and + third is the option is to manually create a UNIX/Linux group account that can substitute + for the MS Windows group name, then use the procedure listed above to map that group + to the MS Windows group. + + + + + + Adding Domain Users to the Workstation Power Users Group + + + What must I do to add domain users to the Power Users group? + + + +Domain Users group + The Power Users group is a group that is local to each Windows 200x/XP Professional workstation. + You cannot add the Domain Users group to the Power Users group automatically, it must be done on + each workstation by logging in as the local workstation administrator and + then using the following procedure: + + + + + Click Start -> Control Panel -> Users and Passwords. + + + + Click the Advanced tab. + + + + Click the Advanced button. + + + + Click Groups. + + + + Double-click Power Users. This will launch the panel to add users or groups + to the local machine Power Users group. + + + + Click the Add button. + + + + Select the domain from which the Domain Users group is to be added. + + + + Double-click the Domain Users group. + + + + Click the OK button. If a logon box is presented during this process, + please remember to enter the connect as DOMAIN\UserName, that is, for the + domain MIDEARTH and the user root enter + MIDEARTH\root. + + + + + + + -- cgit