diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/Samba-HOWTO-Collection/TOSHARG-Group-Mapping.xml | 112 | ||||
| -rw-r--r-- | docs/Samba-HOWTO-Collection/TOSHARG-TheNetCommand.xml | 74 |
2 files changed, 118 insertions, 68 deletions
diff --git a/docs/Samba-HOWTO-Collection/TOSHARG-Group-Mapping.xml b/docs/Samba-HOWTO-Collection/TOSHARG-Group-Mapping.xml index 50a33da2c6..c64347c58b 100644 --- a/docs/Samba-HOWTO-Collection/TOSHARG-Group-Mapping.xml +++ b/docs/Samba-HOWTO-Collection/TOSHARG-Group-Mapping.xml @@ -92,8 +92,6 @@ UNIX/Linux group, an attempt that will of course fail. </para> - - <para> <indexterm><primary>GID</primary></indexterm> <indexterm><primary>SID</primary></indexterm> @@ -220,6 +218,105 @@ </sect2> <sect2> + <title>Nested Groups: Adding Windows Domain Groups to Windows Local Groups</title> + + <indexterm><primary>groups</primary><secondary>nested</secondary></indexterm> + + <para> + This functionality is known as <constant>nested groups</constant> and was first added to + Samba-3.0.3. + </para> + + <para> + All Microsoft Windows products since the release of Windows NT 3.10 support the use of nested groups. + Many Windows network administrators depend on this capability becasue it greatly simplifies security + administration. + </para> + + <para> + 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. + </para> + + <para> + 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. + </para> + + <para> + Unravelling 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 <constant>Account Unknown</constant> 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. + </para> + + <para> + 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 + builtin + local group <constant>Administrators</constant> 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 + <constant>Domain Admins</constant> 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 adminitrative + privileges on each domain member. + </para> + + <para> + 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 + <filename>/etc/group</filename>. 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 + <filename>/etc/group</filename> entries on demand by obtaining user and group information from the Domain + Controller that the Samba server is a member of. + </para> + <para> + In effect, Samba supplements the <filename>/etc/group</filename> data via the dynamic + <command>libnss_winbind</command> mechanism. Beginning with Samba-3.0.3 this facility is used to provide + local groups in the same manner as Windows does it. It works by expanding the local groups on the + fly as they are accessed. For example, the <constant>Domain Users</constant> group of the domain is made + a member of the local group <constant>demo</constant>. Whenever Samba needs to resolve membership of the + <constant>demo</constant> local (alias) group winbind asks the DC 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 <constant>demo</constant>. + </para> + + <para> + To enable the use of nested groups, <command>winbindd</command> must be used together 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 <command>net rpc group</command>. Creating the local group + <constant>demo</constant> is achieved by executing: + <screen> + &rootprompt; net rpc group add demo -L -Uroot%not24get + </screen> + 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 priviliges. Adding and removing + group + members can be done via the <constant>addmem</constant> and <constant>delmem</constant> subcommands of + <command>net rpc group</command> command. For example addition of <quote>DOM\Domain Users</quote> to the + local + group <constant>demo</constant> would be done by executing: + <screen> + net rpc group addmem demo "DOM\Domain Users" + </screen> + Having completed these two steps the execution of <command>getent group demo</command> will show demo + members of the global <constant>Domain Users</constant> group as members of the group + <constant>demo</constant>. 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 + <constant>demo</constant>. + </para> + + </sect2> + + <sect2> <title>Important Administrative Information</title> <para> @@ -632,17 +729,6 @@ manually before putting them into active service. </sect2> <sect2> - <title>Adding MS Windows Groups to MS Windows Groups Fails</title> - - <indexterm><primary>groups</primary><secondary>nested</secondary></indexterm> - - <para> - Samba-3 does not support nested groups from the MS Windows control environment. - </para> - - </sect2> - - <sect2> <title>Adding <emphasis>Domain Users</emphasis> to the <emphasis>Power Users</emphasis> Group</title> <para><quote> diff --git a/docs/Samba-HOWTO-Collection/TOSHARG-TheNetCommand.xml b/docs/Samba-HOWTO-Collection/TOSHARG-TheNetCommand.xml index 83d41797d7..64694b4706 100644 --- a/docs/Samba-HOWTO-Collection/TOSHARG-TheNetCommand.xml +++ b/docs/Samba-HOWTO-Collection/TOSHARG-TheNetCommand.xml @@ -265,65 +265,29 @@ SupportEngrs (S-1-5-21-72630-4128915-11681869-3007) -> SupportEngrs <title>Nested Group Support</title> <para> + It is possible in Windows (and now in Samba also) to great a local group that has members (contains) + domain users and domain global groups. Creation of the local group <constant>demo</constant> is + achieved by executing: <screen> -Windows supports the concept of nested groups to ease -administration. You can create a so-called local group on -any machine and add users and global (domain) groups from -any trusted SAM to it. This way you might be able to reduce -the amount of ACL entries you have to set on any file or -directory. Another prominent example is the use of administrative -privileges on workstations that are domain members. Administrative -privileges are given to all members of the builtin local group -Administrators on each workstation. To make sure that all -domain administrators also have full rights on any workstation, -upon domain join the Domain Admins group is added to the local -Administrators group. Thus anybody logged into the domain as -member of the Domain Admins group is also granted local admin -privileges on each workstation. - -Unix does not support the concept of nested groups, and thus Samba -has for a long time not supported them either. The problem is that -you would have to put unix groups as auxiliary members of a group -into /etc/group which is not possible. Since Samba 2.2 winbind is -the daemon that can provide /etc/group entries on demand by asking -the Domain Controller of the domain Samba is a member of on the fly. -So Samba since that time has control over the /etc/group file 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 does it. It works by expanding the local groups on the -fly while being accessed. So when you put for example the Domain -Users group of your domain as a member of the local alias "all", -whenever asking for the members of "all" winbind asks the DC -for all 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 group "all". - -To be able to use nested groups, you need to run winbindd and -nss_winbind. Creation and administration of the local groups -is done best via the Windows User Manager for Domains or its -Samba equivalent, the utility "net rpc group". Creating the -local group "all" can be done by - -net rpc group add all -L - -where the -L switch denotes that you want to create a local group. -Please add -S and -U switches for accessing the correct host via a -user with root priviliges as needed. Adding and removing group -members can be done via the addmem and delmem subcommands of "net -rpc group". For example adding "DOM\Domain Users" to the local -group "all" would be done by - -net rpc group addmem all "DOM\Domain Users" - -Having done these two steps you will find that "getent group all" -will show all members of the global Domain Users group as members -of the group "all". Certainly 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 "all". +&rootprompt; net rpc group add demo -L -Uroot%not24get </screen> + The -L switch means create a local group. Use the -S argument to direct the operation to a particular + server. The parameters to the -U argument should be for a user who has appropriate administrative right + and privileges on the machine. </para> + <para> + Addition and removal of group members can be achieved using the <constant>addmem</constant> and + <constant>delmem</constant> subcommands of <command>net rpc group</command> command. For example, + addition of <quote>DOM\Domain Users</quote> to the local group <constant>demo</constant> would be + done by executing: +<screen> +&rootprompt; net rpc group addmem demo "DOM\Domain Users" -Uroot%not24get +</screen> + </para> + + + </sect3> </sect2> |