Another update.

(This used to be commit 820417a1678048c61e2cb47cf301a5ffd60e1b9f)

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>