diff options
Diffstat (limited to 'docs/Samba3-HOWTO')
-rw-r--r-- | docs/Samba3-HOWTO/TOSHARG-BDC.xml | 12 | ||||
-rw-r--r-- | docs/Samba3-HOWTO/TOSHARG-Portability.xml | 3 | ||||
-rw-r--r-- | docs/Samba3-HOWTO/TOSHARG-RightsAndPriviliges.xml | 43 | ||||
-rw-r--r-- | docs/Samba3-HOWTO/TOSHARG-TheNetCommand.xml | 78 |
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&type=collections&max=50&language=en&queryKey5=112960;rev=14&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> |