More Updates.

(This used to be commit 6fba7bc2c89b584278b0f888b7620b5206624e4b)

4 files changed, 123 insertions, 13 deletions

diff --git a/docs/Samba3-HOWTO/TOSHARG-BDC.xml b/docs/Samba3-HOWTO/TOSHARG-BDC.xml
index 2d601af1b4..353683478c 100644
--- a/docs/Samba3-HOWTO/TOSHARG-BDC.xml
+++ b/docs/Samba3-HOWTO/TOSHARG-BDC.xml
@@ -19,12 +19,12 @@ with configuring a Samba domain controller as described in <link linkend="samba-
 <title>Features and Benefits</title>
 
 <para>
-This is one of the most difficult chapters to summarize. It does not matter what we say here,
-for someone will still draw conclusions and/or approach the Samba Team with expectations
-that are either not yet capable of being delivered or that can be achieved far more
-effectively using a totally different approach. In the event that you should have a persistent
-concern that is not addressed in this book, please email <ulink url="mailto:jht@samba.org">John H. Terpstra</ulink>
-clearly setting out your requirements and/or question, and we will do our best to provide a solution.
+This is one of the most difficult chapters to summarize. It does not matter what we say here, for someone will
+still draw conclusions and/or approach the Samba Team with expectations that are either not yet capable of
+being delivered or that can be achieved far more effectively using a totally different approach. In the event
+that you should have a persistent concern that is not addressed in this book, please email <ulink
+url="mailto:jht@samba.org">John H. Terpstra</ulink> clearly setting out your requirements and/or question, and
+we will do our best to provide a solution.
 </para>
 
 <para>
diff --git a/docs/Samba3-HOWTO/TOSHARG-Portability.xml b/docs/Samba3-HOWTO/TOSHARG-Portability.xml
index 28f32702e0..d70dba1a9e 100644
--- a/docs/Samba3-HOWTO/TOSHARG-Portability.xml
+++ b/docs/Samba3-HOWTO/TOSHARG-Portability.xml
@@ -233,7 +233,8 @@ and rebuild Samba.
 <title>Winbind on Solaris 9</title>
 <para>
 Nsswitch on Solaris 9 refuses to use the Winbind NSS module. This behavior
-is fixed by Sun in patch <ulink url="http://sunsolve.sun.com/pub-cgi/findPatch.pl?patchId=112960;rev=14">112960-14</ulink>.
+is fixed by Sun in patch <ulink
+url="http://sunsolve.sun.com/search/advsearch.do?collection=PATCH&amp;type=collections&amp;max=50&amp;language=en&amp;queryKey5=112960;rev=14&amp;toDocument=yes">112960-14</ulink>.
 </para>
 </sect2>
 </sect1>
diff --git a/docs/Samba3-HOWTO/TOSHARG-RightsAndPriviliges.xml b/docs/Samba3-HOWTO/TOSHARG-RightsAndPriviliges.xml
index 3a87fcd64c..15a963943b 100644
--- a/docs/Samba3-HOWTO/TOSHARG-RightsAndPriviliges.xml
+++ b/docs/Samba3-HOWTO/TOSHARG-RightsAndPriviliges.xml
@@ -278,11 +278,50 @@ or domain. Under UNIX/Linux the equivalent is UID=0 (the root account).
 </para></note>
 
 <para>
-Commencing with Samba version 3.0.11 it is possible to operate without an Administrator account
+Releases of Samba version 3.0.11 and later make it possible to operate without an Administrator account
 providing equivalent rights and privileges have been established for a Windows user or a Windows
-group account.
+group account. 
 </para>
 
 </sect1>
 
+<sect1>
+<title>Common Errors</title>
+
+	<sect2>
+	<title>What Rights and Privileges Will Permit Windows Client Administration?</title>
+
+	<para>
+	When a Windows NT4 (or later) client joins a domain, the domain global <literal>Domain Admins</literal> group
+	is added to the membership of the local <literal>Administrators</literal> group on the client. Any user who is
+	a member of the domain global <literal>Domain Admins</literal> group will have administrative rights on the
+	Windows client.
+	</para>
+
+	<para>
+	This is often not the most desirable solution because it means that the user will have administrative
+	rights and privileges on domain servers also. The <literal>Power Users</literal> group on Windows client
+	workstations permits local administration of the workstation alone. Any domain global user or domain global
+	group can be added to the membership of the local workstation group <literal>Power Users</literal>.
+	</para>
+
+	<para>
+	See <link linkend="nestedgrpmgmgt">Nested Group Support</link> for an example of how to add domain users
+	and groups to a local group that is on a Windows workstation. The use of the <command>net</command>
+	command permits this to be done from the Samba server.
+	</para>
+
+	<para>
+	Another way this can be done is to log onto the Windows workstation as the user
+	<literal>Administrator</literal>, then open a <command>cmd</command> shell, then execute:
+<screen>
+c:\ net localgroup administrators /add <userinput>domain_name\entity</userinput>
+</screen>
+	where <literal>entity</literal> is either a domain user or a domain group account name.
+	</para>
+
+	</sect2>
+
+</sect1>
+
 </chapter>
diff --git a/docs/Samba3-HOWTO/TOSHARG-TheNetCommand.xml b/docs/Samba3-HOWTO/TOSHARG-TheNetCommand.xml
index 2b73a06392..7231bdaf21 100644
--- a/docs/Samba3-HOWTO/TOSHARG-TheNetCommand.xml
+++ b/docs/Samba3-HOWTO/TOSHARG-TheNetCommand.xml
@@ -224,8 +224,8 @@ SupportEngrs (S-1-5-21-72630-4128915-11681869-3007) -> SupportEngrs
 	</para>
 
 	<para>
-	The operations that are permitted include: <constant>add</constant>, <constant>modify</constant>, and <constant>delete</constant>. An example
-	of each operation is shown here.
+	The operations that are permitted include: <constant>add</constant>, <constant>modify</constant>,
+	and <constant>delete</constant>. An example of each operation is shown here.
 	</para>
 
 	<para>
@@ -296,7 +296,7 @@ SupportEngrs (S-1-5-21-72630-4128915-11681869-3007) -> SupportEngrs
 
 	</sect2>
 
-	<sect2>
+	<sect2 id="grpmemshipchg">
 	<title>Manipulating Group Memberships</title>
 
 	<para>
@@ -409,7 +409,7 @@ MIDEARTH\vlendecke
 
 	</sect2>
 
-	<sect2>
+	<sect2 id="nestedgrpmgmgt">
 	<title>Nested Group Support</title>
 
 	<para>
@@ -452,6 +452,9 @@ DOM\jht
 </screen>
 	</para>
 
+	<sect3>
+	<title>Managing Nest Groups on Workstations from the Samba Server</title>
+
 	<para>
 	Windows network administrators often ask on the Samba mailing list how it is possible to grant everyone
 	administrative rights on their own workstation. This is of course a very bad practice, but commonly done
@@ -462,6 +465,73 @@ DOM\jht
 </screen>
 	</para>
 
+	<para>
+	This can be scripted, and can therefore be performed as a user logs onto the domain from a Windows
+	workstation. Here is a simple example that shows how this can be done.
+	</para>
+
+	<procedure>
+	<title>Automating User Addition to the Workstation Power Users Group</title>
+
+		<step><para>
+		Create the script shown in <link linkend="autopoweruserscript"></link> and locate it in
+		the directory <filename>/etc/samba/scripts</filename>, named as <filename>autopoweruser.sh</filename>.
+		</para></step>
+
+<example id="autopoweruserscript">
+<title>Script to Auto-add Domain Users to Workstation Power Users Group</title>
+<procedure>
+#!/bin/bash
+
+/usr/bin/net rpc group addmem "Power Users"  "DOMAIN_NAME\$1" -UAdministrator%secret -S $2
+
+exit 0
+</procedure>
+</example>
+
+		<step><para>
+		Set the permissions on this script to permit it to be executed as part of the logon process:
+<screen>
+&rootprompt; chown root:root /etc/samba/autopoweruser.sh
+&rootprompt; chmod 755 /etc/samba/autopoweruser.sh
+</screen>
+		</para></step>
+
+		<step><para>
+		Modify the &smb.conf; file so the <literal>NETLOGON</literal> stanza contains the parameters
+		shown in <link linkend="magicnetlogon">the Netlogon Example smb.conf file</link>.
+		</para></step>
+
+<example id="magicnetlogon">
+<title>A Magic Netlogon Share</title>
+<smbconfblock>
+<smbconfsection name="[netlogon]"/>
+<smbconfoption name="comment">Netlogon Share</smbconfoption>
+<smbconfoption name="path">/var/lib/samba/netlogon</smbconfoption>
+<smbconfoption name="root preexec">/etc/samba/scripts/autopoweruser.sh %U %m</smbconfoption>
+<smbconfoption name="read only">Yes</smbconfoption>
+<smbconfoption name="guest ok">Yes</smbconfoption>
+</smbconfblock>
+</example>
+
+		<step><para>
+		Ensure that every Windows workstation Adminsitrator account has the same password that you
+		have used in the script shown in <link linkend="magicnetlogon">the Netlogon Example smb.conf
+		file</link>
+		</para></step>
+
+</procedure>
+
+	<para>
+	This script will be executed every time a user logs onto the network. Therefore every user will
+	have local Windows workstation management rights. This could of course be assigned using a group,
+	in which case there is little justification for the use of this procedure. The key justification
+	for the use of this method is that it will guarantee that all users have appropriate rights on
+	the workstation.
+	</para>
+
+	</sect3>
+
 	</sect2>
 
 	</sect1>