<sect1>
<title>Common Errors</title>
-<para>
-I've compiled Samba-3 from the CVS and the two binaries (smbd and nmbd)
-are very large files (40 Mg and 20 Mg). I've the same result with
---enable-shared ?
+<para><quote>
+I'm using gcc 3 and I've compiled Samba-3 from the CVS and the
+binaries are very large files (40 Mb and 20 Mb). I've the same result with
+<option>--enable-shared</option> ?
+</quote>
</para>
<para>
-Answer: Strip the binaries (or dond't compile with -g).
+The dwarf format used by GCC 3 for storing debugging symbols is very inefficient.
+Strip the binaries, don't compile with -g or compile with -gstabs.
</para>
</sect1>
<listitem>
<para>
instead of logging in under the [user, password, domain] dialog,
- press escape.
+ press <guibutton>escape</guibutton>.
</para>
</listitem>
<para>[Exit the registry editor].</para>
</listitem>
- <listitem>
- <para>
- <emphasis>WARNING</emphasis> - before deleting the contents of the
+ <warning>
+ Before deleting the contents of the
directory listed in the ProfilePath (this is likely to be
<filename>c:\windows\profiles\username)</filename>, ask them if they
have any important files stored on their desktop or in their start menu.
system file) user.DAT in their profile directory, as well as the
local "desktop", "nethood", "start menu" and "programs" folders.
</para>
- </listitem>
+ </warning>
<listitem>
<para>
- search for the user's .PWL password-caching file in the c:\windows
+ search for the user's .PWL password-caching file in the <filename>c:\windows</filename>
directory, and delete it.
</para>
</listitem>
<listitem>
<para>
- check the contents of the profile path (see "logon path" described
- above), and delete the user.DAT or user.MAN file for the user,
+ check the contents of the profile path (see <parameter>logon path</parameter> described
+ above), and delete the <filename>user.DAT</filename> or <filename>user.MAN</filename> file for the user,
making a backup if required.
</para>
</listitem>
<para>
If all else fails, increase samba's debug log levels to between 3 and 10,
-and / or run a packet trace program such as ethereal or netmon.exe, and
+and / or run a packet trace program such as ethereal or <command>netmon.exe</command>, and
look for error messages.
</para>
<para>
When a user first logs in to a Windows NT Workstation, the profile
NTuser.DAT is created. The profile location can be now specified
-through the "logon path" parameter.
+through the <parameter>logon path</parameter> parameter.
</para>
<para>
There is a parameter that is now available for use with NT Profiles:
-"logon drive". This should be set to <filename>H:</filename> or any other drive, and
+<parameter>logon drive</parameter>. This should be set to <filename>H:</filename> or any other drive, and
should be used in conjunction with the new "logon home" parameter.
</para>
<para>
In the profile directory, Windows NT4 creates more folders than Windows 9x / Me.
-It creates "Application Data" and others, as well as "Desktop", "Nethood",
-"Start Menu" and "Programs". The profile itself is stored in a file
-NTuser.DAT. Nothing appears to be stored in the .PDS directory, and
+It creates <filename>Application Data</filename> and others, as well as <filename>Desktop</filename>, <filename>Nethood</filename>,
+<filename>Start Menu</filename> and <filename>Programs</filename>. The profile itself is stored in a file
+<filename>NTuser.DAT</filename>. Nothing appears to be stored in the .PDS directory, and
its purpose is currently unknown.
</para>
<para>
-You can use the System Control Panel to copy a local profile onto
+You can use the <application>System Control Panel</application> to copy a local profile onto
a samba server (see NT Help on profiles: it is also capable of firing
-up the correct location in the System Control Panel for you). The
-NT Help file also mentions that renaming NTuser.DAT to NTuser.MAN
+up the correct location in the <application>System Control Panel</application> for you). The
+NT Help file also mentions that renaming <filename>NTuser.DAT</filename> to <filename>NTuser.MAN</filename>
turns a profile into a mandatory one.
</para>
<para>
The case of the profile is significant. The file must be called
-NTuser.DAT or, for a mandatory profile, NTuser.MAN.
+<filename>NTuser.DAT</filename> or, for a mandatory profile, <filename>NTuser.MAN</filename>.
</para>
</sect3>
profile on the MS Windows workstation as follows:
</para>
-<itemizedlist>
- Log on as the LOCAL workstation administrator.
- </para></listitem>
+<procedure>
+ Log on as the <emphasis>LOCAL</emphasis> workstation administrator.
+ </para></step>
- Right click on the 'My Computer' Icon, select 'Properties'
- </para></listitem>
+ Right click on the <guiicon>My Computer</guiicon> Icon, select <guimenuitem>Properties</guimenuitem>
+ </para></step>
- Click on the 'User Profiles' tab
- </para></listitem>
+ Click on the <guilabel>User Profiles</guilabel> tab
+ </para></step>
Select the profile you wish to convert (click on it once)
- </para></listitem>
+ </para></step>
- Click on the button 'Copy To'
- </para></listitem>
+ Click on the button <guibutton>Copy To</guibutton>
+ </para></step>
- In the "Permitted to use" box, click on the 'Change' button.
- </para></listitem>
+ In the <guilabel>Permitted to use</guilabel> box, click on the <guibutton>Change</guibutton> button.
+ </para></step>
Click on the 'Look in" area that lists the machine name, when you click
here it will open up a selection box. Click on the domain to which the
profile must be accessible.
</para>
<note><para>You will need to log on if a logon box opens up. Eg: In the connect
- as: MIDEARTH\root, password: mypassword.</para></note>
- </listitem>
+ as: <replaceable>MIDEARTH</replaceable>\root, password: <replaceable>mypassword</replaceable>.</para></note>
+ </step>
To make the profile capable of being used by anyone select 'Everyone'
- </para></listitem>
+ </para></step>
- Click OK. The Selection box will close.
- </para></listitem>
+ Click <guibutton>OK</guibutton>. The Selection box will close.
+ </para></step>
- Now click on the 'Ok' button to create the profile in the path you
+ Now click on the <guibutton>Ok</guibutton> button to create the profile in the path you
nominated.
- </para></listitem>
-</itemizedlist>
+ </para></step>
+</procedure>
<para>
Done. You now have a profile that can be editted using the samba-3.0.0
-<filename>profiles</filename> tool.
+<command>profiles</command> tool.
</para>
<note>
</note>
<note>
-<itemizedlist>
+<procedure>
This is a security check new to Windows XP (or maybe only
Windows XP service pack 1). It can be disabled via a group policy in
Active Directory. The policy is:</para>
-<para>"Computer Configuration\Administrative Templates\System\User
-Profiles\Do not check for user ownership of Roaming Profile Folders"</para>
+<para><filename>Computer Configuration\Administrative Templates\System\User
+Profiles\Do not check for user ownership of Roaming Profile Folders</filename></para>
-<para>...and it should be set to "Enabled".
+<para>...and it should be set to <constant>Enabled</constant>.
Does the new version of samba have an Active Directory analogue? If so,
then you may be able to set the policy through this.
</para>
same way as a domain group policy):
</para>
-</listitem>
+</step>
On the XP workstation log in with an Administrator account.
-</para></listitem>
-
- <listitem><para>Click: "Start", "Run"</para></listitem>
- <listitem><para>Type: "mmc"</para></listitem>
- <listitem><para>Click: "OK"</para></listitem>
-
- <listitem><para>A Microsoft Management Console should appear.</para></listitem>
- <listitem><para>Click: File, "Add/Remove Snap-in...", "Add"</para></listitem>
- <listitem><para>Double-Click: "Group Policy"</para></listitem>
- <listitem><para>Click: "Finish", "Close"</para></listitem>
- <listitem><para>Click: "OK"</para></listitem>
-
- <listitem><para>In the "Console Root" window:</para></listitem>
- <listitem><para>Expand: "Local Computer Policy", "Computer Configuration",</para></listitem>
- <listitem><para>"Administrative Templates", "System", "User Profiles"</para></listitem>
- <listitem><para>Double-Click: "Do not check for user ownership of Roaming Profile</para></listitem>
- <listitem><para>Folders"</para></listitem>
- <listitem><para>Select: "Enabled"</para></listitem>
- <listitem><para>Click: OK"</para></listitem>
-
- <listitem><para>Close the whole console. You do not need to save the settings (this
+</para></step>
+
+ <step><para>Click: <guimenu>Start</guimenu>, <guimenuitem>Run</guimenuitem></para></step>
+ <step><para>Type: <userinput>mmc</userinput></para></step>
+ <step><para>Click: <guibutton>OK</guibutton></para></step>
+
+ <step><para>A Microsoft Management Console should appear.</para></step>
+ <step><para>Click: <guimenu>File</guimenu>, <guimenuitem>Add/Remove Snap-in...</guimenuitem>, <guimenuitem>Add</guimenuitem></para></step>
+ <step><para>Double-Click: <guiicon>Group Policy</guiicon></para></step>
+ <step><para>Click: <guibutton>Finish</guibutton>, <guibutton>Close</guibutton></para></step>
+ <step><para>Click: <guibutton>OK</guibutton></para></step>
+
+ <step><para>In the "Console Root" window:</para></step>
+ <step><para>Expand: <guiicon>Local Computer Policy</guiicon>, <guiicon>Computer Configuration</guiicon>,
+ <guiicon>Administrative Templates</guiicon>, <guiicon>System</guiicon>, <guiicon>User Profiles</guiicon></para></step>
+ <step><para>Double-Click: <guilabel>Do not check for user ownership of Roaming Profile Folders</guilabel></para></step>
+ <step><para>Select: <guilabel>Enabled</guilabel></para></step>
+ <step><para>Click: <guibutton>OK</guibutton></para></step>
+
+ <step><para>Close the whole console. You do not need to save the settings (this
refers to the console settings rather than the policies you have
- changed).</para></listitem>
+ changed).</para></step>
- <listitem><para>Reboot</para></listitem>
-</itemizedlist>
+ <step><para>Reboot</para></step>
+</procedure>
</note>
</sect3>
</sect2>
<para>
If you then want to share the same Start Menu / Desktop with W9x/Me, you will
need to specify a common location for the profiles. The smb.conf parameters
-that need to be common are <emphasis>logon path</emphasis> and
-<emphasis>logon home</emphasis>.
+that need to be common are <parameter>logon path</parameter> and
+<parameter>logon home</parameter>.
</para>
<para>
-If you have this set up correctly, you will find separate user.DAT and
-NTuser.DAT files in the same profile directory.
+If you have this set up correctly, you will find separate <filename>user.DAT</filename> and
+<filename>NTuser.DAT</filename> files in the same profile directory.
</para>
</sect2>
Here is a quick guide:
</para>
-<itemizedlist>
+<procedure>
-On your NT4 Domain Controller, right click on 'My Computer', then
-select the tab labelled 'User Profiles'.
-</para></listitem>
+On your NT4 Domain Controller, right click on <guiicon>My Computer</guiicon>, then
+select the tab labelled <guilabel>User Profiles</guilabel>.
+</para></step>
Select a user profile you want to migrate and click on it.
</para>
create a group profile. You can give the user 'Everyone' rights to the
profile you copy this to. That is what you need to do, since your samba
domain is not a member of a trust relationship with your NT4 PDC.</para></note>
-</listitem>
+</step>
- <listitem><para>Click the 'Copy To' button.</para></listitem>
+<step><para>Click the <guibutton>Copy To</guibutton> button.</para></step>
- <listitem><para>In the box labelled 'Copy Profile to' add your new path, eg:
- <filename>c:\temp\foobar</filename></para></listitem>
+ <step><para>In the box labelled <guilabel>Copy Profile to</guilabel> add your new path, eg:
+ <filename>c:\temp\foobar</filename></para></step>
- <listitem><para>Click on the button labelled 'Change' in the "Permitted to use" box.</para></listitem>
+ <step><para>Click on the button <guibutton>Change</guibutton> in the <guilabel>Permitted to use</guilabel> box.</para></step>
- <listitem><para>Click on the group 'Everyone' and then click OK. This closes the
- 'chose user' box.</para></listitem>
+ <step><para>Click on the group 'Everyone' and then click <guibutton>OK</guibutton>. This closes the
+ 'choose user' box.</para></step>
- <listitem><para>Now click OK.</para></listitem>
-</itemizedlist>
+ <step><para>Now click <guibutton>OK</guibutton>.</para></step>
+</procedure>
<para>
Follow the above for every profile you need to migrate.
<para>
Windows NT 4.0 stores the local profile information in the registry under
the following key:
-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
+<filename>HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList</filename>
</para>
<para>
</para>
<para>
-For MS Windows 9x / Me it is the User.DAT file that must be renamed to User.MAN to
+For MS Windows 9x / Me it is the <filename>User.DAT</filename> file that must be renamed to <filename>User.MAN</filename> to
affect a mandatory profile.
</para>
</para>
<para>
-The next step is rather important. PLEASE NOTE: Instead of assigning a group profile
+The next step is rather important. <strong>Please note:</strong> Instead of assigning a group profile
to users (ie: Using User Manager) on a "per user" basis, the group itself is assigned
the now modified profile.
</para>
<title>MS Windows 9x/Me</title>
<para>
-To enable default per use profiles in Windows 9x / Me you can either use the Windows 98 System
-Policy Editor or change the registry directly.
+To enable default per use profiles in Windows 9x / Me you can either use the <application>Windows 98 System
+Policy Editor</application> or change the registry directly.
</para>
<para>
-To enable default per user profiles in Windows 9x / Me, launch the System Policy Editor, then
-select File -> Open Registry, then click on the Local Computer icon, click on Windows 98 System,
-select User Profiles, click on the enable box. Do not forget to save the registry changes.
+To enable default per user profiles in Windows 9x / Me, launch the <application>System Policy Editor</application>, then
+select <guimenu>File</guimenu> -> <guimenuitem>Open Registry</guimenuitem>, then click on the
+<guiicon>Local Computer</guiicon> icon, click on <guilabel>Windows 98 System</guilabel>,
+select <guilabel>User Profiles</guilabel>, click on the enable box. Do not forget to save the registry changes.
</para>
<para>
-To modify the registry directly, launch the Registry Editor (regedit.exe), select the hive
+To modify the registry directly, launch the <application>Registry Editor</application> (<command>regedit.exe</command>), select the hive
<filename>HKEY_LOCAL_MACHINE\Network\Logon</filename>. Now add a DWORD type key with the name
"User Profiles", to enable user profiles set the value to 1, to disable user profiles set it to 0.
</para>
On MS Windows NT4 the default user profile is obtained from the location
<filename>%SystemRoot%\Profiles</filename> which in a default installation will translate to
<filename>C:\WinNT\Profiles</filename>. Under this directory on a clean install there will be
-three (3) directories: <filename>Administrator, All Users, Default User</filename>.
+three (3) directories: <filename>Administrator</filename>, <filename>All Users</filename>, <filename>Default User</filename>.
</para>
<para>
the following steps are followed in respect of profile handling:
</para>
-<orderedlist>
- <listitem>
+<procedure>
+ <step>
<para>
The users' account information which is obtained during the logon process contains
the location of the users' desktop profile. The profile path may be local to the
settings in the <filename>All Users</filename> profile in the <filename>%SystemRoot%\Profiles</filename>
location.
</para>
- </listitem>
+ </step>
- <listitem>
+ <step>
<para>
If the user account has a profile path, but at it's location a profile does not exist,
then a new profile is created in the <filename>%SystemRoot%\Profiles\%USERNAME%</filename>
directory from reading the <filename>Default User</filename> profile.
</para>
- </listitem>
+ </step>
- <listitem>
+ <step>
<para>
If the NETLOGON share on the authenticating server (logon server) contains a policy file
(<filename>NTConfig.POL</filename>) then it's contents are applied to the <filename>NTUser.DAT</filename>
which is applied to the <filename>HKEY_CURRENT_USER</filename> part of the registry.
</para>
- </listitem>
+ </step>
- <listitem>
+ <step>
<para>
When the user logs out, if the profile is set to be a roaming profile it will be written
out to the location of the profile. The <filename>NTuser.DAT</filename> file is then
next logon, the effect of the provious <filename>NTConfig.POL</filename> will still be held
in the profile. The effect of this is known as <emphasis>tatooing</emphasis>.
</para>
- </listitem>
-</orderedlist>
+ </step>
+</procedure>
<para>
MS Windows NT4 profiles may be <emphasis>Local</emphasis> or <emphasis>Roaming</emphasis>. A Local profile
</para>
<para>
-<programlisting>
- HKEY_CURRENT_USER
- \Software
- \Microsoft
- \Windows
- \CurrentVersion
- \Explorer
- \User Shell Folders\
-</programlisting>
+<filename>HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\</filename>
</para>
<para>
The above hive key contains a list of automatically managed folders. The default entries are:
</para>
- <para>
- <programlisting>
- Name Default Value
- -------------- -----------------------------------------
- AppData %USERPROFILE%\Application Data
- Desktop %USERPROFILE%\Desktop
- Favorites %USERPROFILE%\Favorites
- NetHood %USERPROFILE%\NetHood
- PrintHood %USERPROFILE%\PrintHood
- Programs %USERPROFILE%\Start Menu\Programs
- Recent %USERPROFILE%\Recent
- SendTo %USERPROFILE%\SendTo
- Start Menu %USERPROFILE%\Start Menu
- Startup %USERPROFILE%\Start Menu\Programs\Startup
- </programlisting>
- </para>
+<para>
+<table frame="all">
+ <title>User Shell Folder registry keys default values</title>
+ <tgroup cols="2">
+ <thead>
+ <row><entry>Name</entry><entry>Default Value</entry></row>
+ </thead>
+ <tbody>
+ <row><entry>AppData</entry><entry>%USERPROFILE%\Application Data</entry></row>
+ <row><entry>Desktop</entry><entry>%USERPROFILE%\Desktop</entry></row>
+ <row><entry>Favorites</entry><entry>%USERPROFILE%\Favorites</entry></row>
+ <row><entry>NetHood</entry><entry>%USERPROFILE%\NetHood</entry></row>
+ <row><entry>PrintHood</entry><entry>%USERPROFILE%\PrintHood</entry></row>
+ <row><entry>Programs</entry><entry>%USERPROFILE%\Start Menu\Programs</entry></row>
+ <row><entry>Recent</entry><entry>%USERPROFILE%\Recent</entry></row>
+ <row><entry>SendTo</entry><entry>%USERPROFILE%\SendTo</entry></row>
+ <row><entry>Start Menu </entry><entry>%USERPROFILE%\Start Menu</entry></row>
+ <row><entry>Startup</entry><entry>%USERPROFILE%\Start Menu\Programs\Startup</entry></row>
+ </tbody>
+ </tgroup>
+</table>
+</para>
<para>
The registry key that contains the location of the default profile settings is:
+</para>
-<programlisting>
- HKEY_LOCAL_MACHINE
- \SOFTWARE
- \Microsoft
- \Windows
- \CurrentVersion
- \Explorer
- \User Shell Folders
-</programlisting>
+<para>
+<filename>HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders</filename>
+</para>
+<para>
The default entries are:
-<programlisting>
- Common Desktop %SystemRoot%\Profiles\All Users\Desktop
- Common Programs %SystemRoot%\Profiles\All Users\Programs
- Common Start Menu %SystemRoot%\Profiles\All Users\Start Menu
- Common Startup %SystemRoot%\Profiles\All Users\Start Menu\Progams\Startup
-</programlisting>
+<table frame="all">
+ <title>Defaults of profile settings registry keys</title>
+ <tgroup cols="2">
+ <tbody>
+ <row><entry>Common Desktop</entry><entry>%SystemRoot%\Profiles\All Users\Desktop</entry></row>
+ <row><entry>Common Programs</entry><entry>%SystemRoot%\Profiles\All Users\Programs</entry></row>
+ <row><entry>Common Start Menu</entry><entry>%SystemRoot%\Profiles\All Users\Start Menu</entry></row>
+ <row><entry>Common Startup</entry><entry>%SystemRoot%\Profiles\All Users\Start Menu\Progams\Startup</entry></row>
+ </tbody>
+ </tgroup>
+</table>
</para>
</sect2>
<note>
<para>
- This path translates, in Samba parlance, to the smb.conf [NETLOGON] share. The directory
+ This path translates, in Samba parlance, to the &smb.conf; <parameter>[NETLOGON]</parameter> share. The directory
should be created at the root of this share and must be called <filename>Default Profile</filename>.
</para>
</note>
</para>
<para>
-<programlisting>
- HKEY_CURRENT_USER
- \Software
- \Microsoft
- \Windows
- \CurrentVersion
- \Explorer
- \User Shell Folders\
-</programlisting>
+<filename>HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\</filename>
</para>
<para>
The above hive key contains a list of automatically managed folders. The default entries are:
</para>
- <para>
- <programlisting>
- Name Default Value
- -------------- -----------------------------------------
- AppData %USERPROFILE%\Application Data
- Cache %USERPROFILE%\Local Settings\Temporary Internet Files
- Cookies %USERPROFILE%\Cookies
- Desktop %USERPROFILE%\Desktop
- Favorites %USERPROFILE%\Favorites
- History %USERPROFILE%\Local Settings\History
- Local AppData %USERPROFILE%\Local Settings\Application Data
- Local Settings %USERPROFILE%\Local Settings
- My Pictures %USERPROFILE%\My Documents\My Pictures
- NetHood %USERPROFILE%\NetHood
- Personal %USERPROFILE%\My Documents
- PrintHood %USERPROFILE%\PrintHood
- Programs %USERPROFILE%\Start Menu\Programs
- Recent %USERPROFILE%\Recent
- SendTo %USERPROFILE%\SendTo
- Start Menu %USERPROFILE%\Start Menu
- Startup %USERPROFILE%\Start Menu\Programs\Startup
- Templates %USERPROFILE%\Templates
- </programlisting>
- </para>
+<para>
+<table frame="all">
+ <title>Defaults of default user profile paths registry keys</title>
+ <tgroup cols="2">
+ <thead><row><entry>Name</entry><entry>Default Value</entry></row></thead>
+ <tbody>
+ <row><entry>AppData</entry><entry>%USERPROFILE%\Application Data</entry></row>
+ <row><entry>Cache</entry><entry>%USERPROFILE%\Local Settings\Temporary Internet Files</entry></row>
+ <row><entry>Cookies</entry><entry>%USERPROFILE%\Cookies</entry></row>
+ <row><entry>Desktop</entry><entry>%USERPROFILE%\Desktop</entry></row>
+ <row><entry>Favorites</entry><entry>%USERPROFILE%\Favorites</entry></row>
+ <row><entry>History</entry><entry>%USERPROFILE%\Local Settings\History</entry></row>
+ <row><entry>Local AppData</entry><entry>%USERPROFILE%\Local Settings\Application Data</entry></row>
+ <row><entry>Local Settings</entry><entry>%USERPROFILE%\Local Settings</entry></row>
+ <row><entry>My Pictures</entry><entry>%USERPROFILE%\My Documents\My Pictures</entry></row>
+ <row><entry>NetHood</entry><entry>%USERPROFILE%\NetHood</entry></row>
+ <row><entry>Personal</entry><entry>%USERPROFILE%\My Documents</entry></row>
+ <row><entry>PrintHood</entry><entry>%USERPROFILE%\PrintHood</entry></row>
+ <row><entry>Programs</entry><entry>%USERPROFILE%\Start Menu\Programs</entry></row>
+ <row><entry>Recent</entry><entry>%USERPROFILE%\Recent</entry></row>
+ <row><entry>SendTo</entry><entry>%USERPROFILE%\SendTo</entry></row>
+ <row><entry>Start Menu</entry><entry>%USERPROFILE%\Start Menu</entry></row>
+ <row><entry>Startup</entry><entry>%USERPROFILE%\Start Menu\Programs\Startup</entry></row>
+ <row><entry>Templates</entry><entry>%USERPROFILE%\Templates</entry></row>
+ </tbody></tgroup></table>
+</para>
<para>
-There is also an entry called "Default" that has no value set. The default entry is of type REG_SZ, all
-the others are of type REG_EXPAND_SZ.
+There is also an entry called "Default" that has no value set. The default entry is of type <constant>REG_SZ</constant>, all
+the others are of type <constant>REG_EXPAND_SZ</constant>.
</para>
<para>
<para>
To set this to a network location you could use the following examples:
+</para>
-<programlisting>
- %LOGONSERVER%\%USERNAME%\Default Folders
-</programlisting>
-
-This would store the folders in the user's home directory under a directory called "Default Folders"
+<para><filename>%LOGONSERVER%\%USERNAME%\Default Folders</filename></para>
+<para>
+This would store the folders in the user's home directory under a directory called <filename>Default Folders</filename>
You could also use:
+</para>
-<programlisting>
- \\SambaServer\FolderShare\%USERNAME%
-</programlisting>
+<para><filename>\\<replaceable>SambaServer</replaceable>\<replaceable>FolderShare</replaceable>\%USERNAME%</filename></para>
-in which case the default folders will be stored in the server named <emphasis>SambaServer</emphasis>
-in the share called <emphasis>FolderShare</emphasis> under a directory that has the name of the MS Windows
+<para>
+ in which case the default folders will be stored in the server named <replaceable>SambaServer</replaceable>
+in the share called <replaceable>FolderShare</replaceable> under a directory that has the name of the MS Windows
user as seen by the Linux/Unix file system.
</para>
A roaming profile will be cached locally unless the following registry key is created:
</para>
-<para>
-<programlisting>
- HKEY_LOCAL_MACHINE\SYSTEM\Software\Microsoft\Windows NT\CurrentVersion\winlogon\
- "DeleteRoamingCache"=dword:00000001
-</programlisting>
+<para><filename>HKEY_LOCAL_MACHINE\SYSTEM\Software\Microsoft\Windows NT\CurrentVersion\winlogon\"DeleteRoamingCache"=dword:00000001</filename></para>
+<para>
In which case, the local cache copy will be deleted on logout.
</para>
</sect2>
be either:
</para>
-<itemizedlist>
- <listitem><para>
- A profile unique to that user
- </para></listitem>
- <listitem><para>
- A mandatory profile (one the user can not change)
- </para></listitem>
- <listitem><para>
- A group profile (really should be mandatory ie:unchangable)
- </para></listitem>
-</itemizedlist>
+<simplelist>
+ <member>A profile unique to that user</member>
+ <member>A mandatory profile (one the user can not change)</member>
+ <member>A group profile (really should be mandatory ie:unchangable)</member>
+</simplelist>
</sect2>
<title>Can NOT use Roaming Profiles</title>
<para>
-<screen>
-> I dont want Roaming profile to be implemented, I just want to give users
-> local profiles only.
+<quote>
+ I dont want Roaming profile to be implemented, I just want to give users
+ local profiles only.
...
-> Please help me I am totally lost with this error from past two days I tried
-> everything and googled around quite a bit but of no help. Please help me.
-
+ Please help me I am totally lost with this error from past two days I tried
+ everything and googled around quite a bit but of no help. Please help me.
+</quote></para>
+<para>
Your choices are:
- 1. Local profiles
- - I know of no registry keys that will allow auto-deletion
- of LOCAL profiles on log out
- 2. Roaming profiles
- - your options here are:
- - can use auto-delete on logout option
- - requires a registry key change on workstation
- a) Personal Roaming profiles
- - should be preserved on a central server
- - workstations 'cache' (store) a local copy
+<!-- FIXME: Write to whole sentences -->
+
+<variablelist>
+ <varlistentry>
+ <term>Local profiles</term>
+ <listitem><para>
+ I know of no registry keys that will allow auto-deletion of LOCAL profiles on log out
+ </para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Roaming profiles</term>
+ <listitem><para>
+ <simplelist>
+ <member>can use auto-delete on logout option</member>
+ <member>requires a registry key change on workstation</member>
+ </simplelist>
+
+ Your choices are:
+
+ <variablelist>
+ <varlistentry>
+ <term>Personal Roaming profiles</term>
+ <listitem><para>
+ - should be preserved on a central server
+ - workstations 'cache' (store) a local copy
- used in case the profile can not be downloaded
at next logon
- b) Group profiles
- - loaded from a cetral place
- c) Mandatory profiles
- - can be personal or group
- - can NOT be changed (except by an administrator
+ </para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Group profiles</term>
+ <listitem><para>- loaded from a cetral place</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Mandatory profiles</term>
+ <listitem><para>
+ - can be personal or group
+ - can NOT be changed (except by an administrator
+ </para></listitem>
+ </varlistentry>
+ </variablelist>
+ </para></listitem>
+ </varlistentry>
+</variablelist>
+</para>
+
+<para>
A WinNT4/2K/XP profile can vary in size from 130KB to off the scale.
Outlook PST files are most often part of the profile and can be many GB in
size. On average (in a well controlled environment) roaming profie size of
undisciplined environment I have seen up to 2GB profiles. Users tend to
complain when it take an hour to log onto a workstation but they harvest
the fuits of folly (and ignorance).
+</para>
+<para>
The point of all the above is to show that roaming profiles and good
controls of how they can be changed as well as good discipline make up for
a problem free site.
+</para>
-PS: Microsoft's answer to the PST problem is to store all email in an MS
+<para>
+Microsoft's answer to the PST problem is to store all email in an MS
Exchange Server back-end. But this is another story ...!
+</para>
+<para>
So, having LOCAL profiles means:
- a) If lots of users user each machine
- - lot's of local disk storage needed for local profiles
- b) Every workstation the user logs into has it's own profile
- - can be very different from machine to machine
+
+<simplelist>
+ <member>If lots of users user each machine - lot's of local disk storage needed for local profiles</member>
+ <member>Every workstation the user logs into has it's own profile - can be very different from machine to machine</member>
+</simplelist>
On the other hand, having roaming profiles means:
- a) The network administrator can control EVERY aspect of user
- profiles
- b) With the use of mandatory profiles - a drastic reduction
- in network management overheads
- c) User unhappiness about not being able to change their profiles
- soon fades as they get used to being able to work reliably
+<simplelist>
+ <member>The network administrator can control EVERY aspect of user profiles</member>
+ <member>With the use of mandatory profiles - a drastic reduction in network management overheads</member>
+ <member>User unhappiness about not being able to change their profiles soon fades as they get used to being able to work reliably</member>
+</simplelist>
-But note:
+</para>
+<para>
I have managed and installed MANY NT/2K networks and have NEVER found one
where users who move from machine to machine are happy with local
profiles. In the long run local profiles bite them.
+</para>
-> When the client tries to logon to the PDC it looks for a profile to download
-> where do I put this default profile.
+</sect2>
+
+<!-- FIXME: Everything below this is a mess. I didn't quite understand it - Jelmer -->
+<sect2>
+ <title>Changing the default profile</title>
+
+<para><quote>
+When the client tries to logon to the PDC it looks for a profile to download
+where do I put this default profile.
+</quote></para>
+
+<para>
Firstly, your samba server need to be configured as a domain controller.
- server = user
- os level = 32 (or more)
- domain logons = Yes
+</para>
- Plus you need to have a NETLOGON share that is world readable.
- It is a good idea to add a logon script to pre-set printer and
- drive connections. There is also a facility for automatically
- synchronizing the workstation time clock with that of the logon
- server (another good thing to do).
+<programlisting>
+ server = user
+ os level = 32 (or more)
+ domain logons = Yes
+</programlisting>
-Note: To invoke auto-deletion of roaming profile from the local
-workstation cache (disk storage) you need to use the Group Policy Editor
-to create a file called NTConfig.POL with the appropriate entries. This
-file needs to be located in the NETLOGON share root directory.
+<para>
+Plus you need to have a <parameter>[netlogon]</parameter> share that is world readable.
+It is a good idea to add a logon script to pre-set printer and
+drive connections. There is also a facility for automatically
+synchronizing the workstation time clock with that of the logon
+server (another good thing to do).
+</para>
+
+<note><para>
+To invoke auto-deletion of roaming profile from the local
+workstation cache (disk storage) you need to use the <application>Group Policy Editor</application>
+to create a file called <filename>NTConfig.POL</filename> with the appropriate entries. This
+file needs to be located in the <parameter>netlogon</parameter> share root directory.</para></note>
+<para>
Oh, of course the windows clients need to be members of the domain.
Workgroup machines do NOT do network logons - so they never see domain
profiles.
+</para>
+<para>
Secondly, for roaming profiles you need:
logon path = \\%N\profiles\%U (with some such path)
logon drive = H: (Z: is the default)
Plus you need a PROFILES share that is world writable.
-</screen>
</para>
</sect2>
does not store the configuration file in any intermediate form, rather, it stores only the
parameter settings, so when SWAT writes the smb.conf file to disk it will write only
those parameters that are at other than the default settings. The result is that all comments
-will be lost from the smb.conf file. Additionally, the parameters will be written back in
+will be lost from the &smb.conf; file. Additionally, the parameters will be written back in
internal ordering.
</para>
<para>
SWAT should be installed to run via the network super daemon. Depending on which system
-your Unix/Linux system has you will have either an <filename>inetd</filename> or
-<filename>xinetd</filename> based system.
+your Unix/Linux system has you will have either an <command>inetd</command> or
+<command>xinetd</command> based system.
</para>
<para>
</para>
<para>
-Both the above examples assume that the <filename>swat</filename> binary has been
+Both the above examples assume that the <command>swat</command> binary has been
located in the <filename>/usr/sbin</filename> directory. In addition to the above
SWAT will use a directory access point from which it will load it's help files
as well as other control information. The default location for this on most Linux
Access to SWAT will prompt for a logon. If you log onto SWAT as any non-root user
the only permission allowed is to view certain aspects of configuration as well as
access to the password change facility. The buttons that will be exposed to the non-root
-user are: <emphasis>HOME, STATUS, VIEW, PASSWORD</emphasis>. The only page that allows
-change capability in this case is <emphasis>PASSWORD</emphasis>.
+user are: <guibutton>HOME</guibutton>, <guibutton>STATUS</guibutton>, <guibutton>VIEW</guibutton>,
+<guibutton>PASSWORD</guibutton>. The only page that allows
+change capability in this case is <guibutton>PASSWORD</guibutton>.
</para>
<para>
-So long as you log onto SWAT as the user <command>root</command> you should obtain
+So long as you log onto SWAT as the user <emphasis>root</emphasis> you should obtain
full change and commit ability. The buttons that will be exposed includes:
-<emphasis>HOME, GLOBALS, SHARES, PRINTERS, WIZARD, STATUS, VIEW, PASSWORD</emphasis>.
+<guibutton>HOME</guibutton>, <guibutton>GLOBALS</guibutton>, <guibutton>SHARES</guibutton>, <guibutton>PRINTERS</guibutton>,
+<guibutton>WIZARD</guibutton>, <guibutton>STATUS</guibutton>, <guibutton>VIEW</guibutton>, <guibutton>PASSWORD</guibutton>.
</para>
</sect2>
Modifications to the swat setup are as following:
</para>
-<itemizedlist>
+<procedure>
install OpenSSL
- </para></listitem>
+ </para></step>
generate certificate and private key
- <programlisting>
- root# /usr/bin/openssl req -new -x509 -days 365 -nodes -config \
- /usr/share/doc/packages/stunnel/stunnel.cnf \
- -out /etc/stunnel/stunnel.pem -keyout /etc/stunnel/stunnel.pem
- </programlisting></para></listitem>
+ <screen>
+&rootprompt;<userinput>/usr/bin/openssl req -new -x509 -days 365 -nodes -config \
+ /usr/share/doc/packages/stunnel/stunnel.cnf \
+ -out /etc/stunnel/stunnel.pem -keyout /etc/stunnel/stunnel.pem</userinput>
+ </screen></para></step>
remove swat-entry from [x]inetd
- </para></listitem>
+ </para></step>
start stunnel
- <programlisting>
- root# stunnel -p /etc/stunnel/stunnel.pem -d 901 \
- -l /usr/local/samba/bin/swat swat
- </programlisting></para></listitem>
-</itemizedlist>
+ <screen>
+&rootprompt;<userinput>stunnel -p /etc/stunnel/stunnel.pem -d 901 \
+ -l /usr/local/samba/bin/swat swat </userinput>
+ </screen></para></step>
+</procedure>
<para>
-afterwards simply contact to swat by using the URL "https://myhost:901", accept the certificate
+afterwards simply contact to swat by using the URL <ulink url="https://myhost:901">https://myhost:901</ulink>, accept the certificate
and the SSL connection is up.
</para>
http://www.ethereal.com</ulink>.
</para>
SWAT can be configured to run in <emphasis>demo</emphasis> mode. This is NOT recommended
as it runs SWAT without authentication and with full administrative ability. ie: Allows
changes to smb.conf as well as general operation with root privilidges. The option that
-creates this ability is the <command>-a</command> flag to swat. DO NOT USE THIS IN ANY
-PRODUCTION ENVIRONMENT - you have been warned!
-</para></note>
+creates this ability is the <option>-a</option> flag to swat. <strong>Do not use this in any
+production environment.</strong>
+</para></warning>
</sect2>
<itemizedlist>
<listitem><para>
- <command>Basic</command> - exposes common configuration options.
+ <emphasis>Basic</emphasis> - exposes common configuration options.
</para></listitem>
<listitem><para>
- <command>Advanced</command> - exposes configuration options needed in more
+ <emphasis>Advanced</emphasis> - exposes configuration options needed in more
complex environments.
</para></listitem>
<listitem><para>
- <command>Developer</command> - exposes configuration options that only the brave
+ <emphasis>Developer</emphasis> - exposes configuration options that only the brave
will want to tamper with.
</para></listitem>
</itemizedlist>
<para>
To switch to other than <emphasis>Basic</emphasis> editing ability click on either the
<emphasis>Advanced</emphasis> or the <emphasis>Developer</emphasis> dial, then click the
-<emphasis>Commit Changes</emphasis> button.
+<guibutton>Commit Changes</guibutton> button.
</para>
<para>
After making any changes to configuration parameters make sure that you click on the
-<emphasis>Commit Changes</emphasis> button before moving to another area otherwise
+<guibutton>Commit Changes</guibutton> button before moving to another area otherwise
your changes will be immediately lost.
</para>
<note><para>
SWAT has context sensitive help. To find out what each parameter is for simply click the
-<command>Help</command> link to the left of the configurartion parameter.
+<guibutton>Help</guibutton> link to the left of the configurartion parameter.
</para></note>
</sect2>
<para>
To affect a currenly configured share, simply click on the pull down button between the
-<emphasis>Choose Share</emphasis> and the <emphasis>Delete Share</emphasis> buttons,
+<guibutton>Choose Share</guibutton> and the <guibutton>Delete Share</guibutton> buttons,
select the share you wish to operate on, then to edit the settings click on the
-<emphasis>Choose Share</emphasis> button, to delete the share simply press the
-<emphasis>Delete Share</emphasis> button.
+<guibutton>Choose Share</guibutton> button, to delete the share simply press the
+<guibutton>Delete Share</guibutton> button.
</para>
<para>
-To create a new share, next to the button labelled <emphasis>Create Share</emphasis> enter
+To create a new share, next to the button labelled <guibutton>Create Share</guibutton> enter
into the text field the name of the share to be created, then click on the
-<emphasis>Create Share</emphasis> button.
+<guibutton>Create Share</guibutton> button.
</para>
</sect2>
<para>
To affect a currenly configured printer, simply click on the pull down button between the
-<emphasis>Choose Printer</emphasis> and the <emphasis>Delete Printer</emphasis> buttons,
+<guibutton>Choose Printer</guibutton> and the <guibutton>Delete Printer</guibutton> buttons,
select the printer you wish to operate on, then to edit the settings click on the
-<emphasis>Choose Printer</emphasis> button, to delete the share simply press the
-<emphasis>Delete Printer</emphasis> button.
+<guibutton>Choose Printer</guibutton> button, to delete the share simply press the
+<guibutton>Delete Printer</guibutton> button.
</para>
<para>
-To create a new printer, next to the button labelled <emphasis>Create Printer</emphasis> enter
+To create a new printer, next to the button labelled <guibutton>Create Printer</guibutton> enter
into the text field the name of the share to be created, then click on the
-<emphasis>Create Printer</emphasis> button.
+<guibutton>Create Printer</guibutton> button.
</para>
</sect2>
</para>
<para>
-The <emphasis>Edit</emphasis> button permits the editing (setting) of the minimal set of
+The <guibutton>Edit</guibutton> button permits the editing (setting) of the minimal set of
options that may be necessary to create a working samba server.
</para>
<para>
The status page serves a limited purpose. Firstly, it allows control of the samba daemons.
-The key daemons that create the samba server environment are: <command> smbd, nmbd, winbindd</command>.
+The key daemons that create the samba server environment are: &smbd;, &nmbd;, &winbindd;.
</para>
<para>
<title>The View Page</title>
<para>
-This page allows the administrator to view the optimised smb.conf file and if you are
+This page allows the administrator to view the optimised &smb.conf; file and if you are
particularly massochistic will permit you also to see all possible global configuration
parameters and their settings.
</para>
<para>
When logged in as a non-root account the user will have to provide the old password as well as
-the new password (twice). When logged in as <command>root</command> only the new password is
+the new password (twice). When logged in as <emphasis>root</emphasis> only the new password is
required.
</para>
<para>
Since version 2.2 Samba officially supports domain logons for all current Windows Clients,
including Windows NT4, 2003 and XP Professional. For samba to be enabled as a PDC some
-parameters in the [global]-section of the smb.conf have to be set:
+parameters in the <parameter>[global]</parameter>-section of the &smb.conf; have to be set:
</para>
<para><programlisting>
</programlisting></para>
<para>
-Several other things like a [homes] and a [netlogon] share also need to be set along with
+Several other things like a <parameter>[homes]</parameter> and a <parameter>[netlogon]</parameter> share also need to be set along with
settings for the profile path, the users home drive, etc.. This will not be covered in this
chapter, for more information please refer to the chapter on Domain Control.
</para>
</para>
<para><programlisting>
-<title>Essential Parameters for BDC Operation</title>
workgroup = SAMBA
domain master = no
domain logons = yes
</programlisting></para>
<para>
-in the [global]-section of the smb.conf of the BDC. This makes the BDC
+in the <parameter>[global]</parameter>-section of the &smb.conf; of the BDC. This makes the BDC
only register the name SAMBA<#1c> with the WINS server. This is no
problem as the name SAMBA<#1c> is a NetBIOS group name that is meant to
be registered by more than one machine. The parameter 'domain master =
networking problems:
</para>
-<itemizedlist>
- <listitem><para>Basic TCP/IP configuration</para></listitem>
- <listitem><para>NetBIOS name resolution</para></listitem>
- <listitem><para>Authentication configuration</para></listitem>
- <listitem><para>User and Group configuration</para></listitem>
- <listitem><para>Basic File and Directory Permission Control in Unix/Linux</para></listitem>
- <listitem><para>Understanding of how MS Windows clients interoperate in a network
- environment</para></listitem>
-</itemizedlist>
+<simplelist>
+ <member>Basic TCP/IP configuration</member>
+ <member>NetBIOS name resolution</member>
+ <member>Authentication configuration</member>
+ <member>User and Group configuration</member>
+ <member>Basic File and Directory Permission Control in Unix/Linux</member>
+ <member>Understanding of how MS Windows clients interoperate in a network
+ environment</member>
+</simplelist>
<para>
Do not be put off, on the surface of it MS Windows networking seems so simple that any fool
inadequate training and preparation. But let's get our first indelible principle out of the
way: <emphasis>It is perfectly OK to make mistakes!</emphasis> In the right place and at
the right time, mistakes are the essence of learning. It is <emphasis>very much</emphasis>
-not Ok to make mistakes that cause loss of productivity and impose an avoidable financial
+not ok to make mistakes that cause loss of productivity and impose an avoidable financial
burden on an organisation.
</para>
there can be multiple back-ends for this including:
</para>
+<!-- FIXME: Doesn't this belong in passdb.xml ? -->
+
<itemizedlist>
<listitem><para>
<emphasis>smbpasswd</emphasis> - the plain ascii file stored used by
New to Samba-3 is the ability to use a back-end database that holds the same type of data as
the NT4 style SAM (Security Account Manager) database (one of the registry files).
The samba-3 SAM can be specified via the smb.conf file parameter
-<emphasis>passwd backend</emphasis> and valid options include
-<emphasis>smbpasswd, tdbsam, ldapsam, nisplussam, xmlsam, mysqlsam, plugin, guest</emphasis>.
+<parameter>passwd backend</parameter> and valid options include
+<emphasis>smbpasswd, tdbsam, ldapsam, nisplussam, xmlsam, mysqlsam, guest</emphasis>.
</para>
<para>
</para>
<itemizedlist>
- <listitem><para>Primary Domain Controller - The one that seeds the domain SAM</para></listitem>
- <listitem><para>Backup Domain Controller - One that obtains a copy of the domain SAM</para></listitem>
- <listitem><para>Domain Member Server - One that has NO copy of the domain SAM, rather it obtains authentication from a Domain Controller for all access controls.</para></listitem>
- <listitem><para>Stand-Alone Server - One that plays NO part is SAM synchronisation, has it's own authentication database and plays no role in Domain security.</para></listitem>
+ <listitem><para><emphasis>Primary Domain Controller</emphasis> - The one that seeds the domain SAM</para></listitem>
+ <listitem><para><emphasis>Backup Domain Controller</emphasis> - One that obtains a copy of the domain SAM</para></listitem>
+ <listitem><para><emphasis>Domain Member Server</emphasis> - One that has NO copy of the domain SAM, rather it obtains authentication from a Domain Controller for all access controls.</para></listitem>
+ <listitem><para><emphasis>Stand-Alone Server</emphasis> - One that plays NO part is SAM synchronisation, has it's own authentication database and plays no role in Domain security.</para></listitem>
</itemizedlist>
<para>
for it's workgroup entry. It is not uncommon for the name WORKGROUP to be used for this. With this
mode of configuration there are NO machine trust accounts and any concept of membership as such
is limited to the fact that all machines appear in the network neighbourhood to be logically
-groupped together. Again, just to be clear: WORKGROUP MODE DOES NOT INVOLVE ANY SECURITY MACHINE
-ACCOUNTS.
+groupped together. Again, just to be clear: <strong>workgroup mode does not involve any security machine
+accounts</strong>.
</para>
<para>
Domain member machines have a machine account in the Domain accounts database. A special procedure
must be followed on each machine to affect Domain membership. This procedure, which can be done
-only by the local machine Adminisistrator account, will create the Domain machine account (if
+only by the local machine Administrator account, will create the Domain machine account (if
if does not exist), and then initializes that account. When the client first logs onto the
Domain it triggers a machine password change.
</para>
NT4 / 200x / XP clients.
</para>
-<orderedlist>
- <listitem><para>
- Configuration of basic TCP/IP and MS Windows Networking
- </para></listitem>
-
- <listitem><para>
- Correct designation of the Server Role (<emphasis>security = user</emphasis>)
- </para></listitem>
-
- <listitem><para>
- Consistent configuration of Name Resolution (See chapter on Browsing and on
- MS Windows network Integration)
- </para></listitem>
-
- <listitem><para>
- Domain logons for Windows NT4 / 200x / XP Professional clients
- </para></listitem>
-
- <listitem><para>
- Configuration of Roaming Profiles or explicit configuration to force local profile usage
- </para></listitem>
-
- <listitem><para>
- Configuration of Network/System Policies
- </para></listitem>
-
- <listitem><para>
- Adding and managing domain user accounts
- </para></listitem>
-
- <listitem><para>
- Configuring MS Windows client machines to become domain members
- </para></listitem>
-</orderedlist>
+<simplelist>
+ <member>Configuration of basic TCP/IP and MS Windows Networking</member>
+ <member>Correct designation of the Server Role (<parameter>security = user</parameter>)</member>
+ <member>Consistent configuration of Name Resolution (See <link linkend="NetworkBrowsing">chapter on Browsing</link> and on
+ <link linkend="integrate-ms-networks">MS Windows network Integration</link>)</member>
+ <member>Domain logons for Windows NT4 / 200x / XP Professional clients</member>
+ <member>Configuration of Roaming Profiles or explicit configuration to force local profile usage</member>
+ <member>Configuration of Network/System Policies</member>
+ <member>Adding and managing domain user accounts</member>
+ <member>Configuring MS Windows client machines to become domain members</member>
+</simplelist>
<para>
The following provisions are required to serve MS Windows 9x / Me Clients:
</para>
-<orderedlist>
- <listitem><para>
- Configuration of basic TCP/IP and MS Windows Networking
- </para></listitem>
-
- <listitem><para>
- Correct designation of the Server Role (<emphasis>security = user</emphasis>)
- </para></listitem>
-
- <listitem><para>
- Network Logon Configuration (Since Windows 9x / XP Home are not technically domain
- members, they do not really particpate in the security aspects of Domain logons as such)
- </para></listitem>
-
- <listitem><para>
- Roaming Profile Configuration
- </para></listitem>
-
- <listitem><para>
- Configuration of System Policy handling
- </para></listitem>
-
- <listitem><para>
- Installation of the Network driver "Client for MS Windows Networks" and configuration
- to log onto the domain
- </para></listitem>
-
- <listitem><para>
- Placing Windows 9x / Me clients in user level security - if it is desired to allow
- all client share access to be controlled according to domain user / group identities.
- </para></listitem>
-
- <listitem><para>
- Adding and managing domain user accounts
- </para></listitem>
-</orderedlist>
+<simplelist>
+ <member>Configuration of basic TCP/IP and MS Windows Networking</member>
+ <member>Correct designation of the Server Role (<parameter>security = user</parameter>)</member>
+ <member>Network Logon Configuration (Since Windows 9x / XP Home are not technically domain
+ members, they do not really particpate in the security aspects of Domain logons as such)</member>
+ <member>Roaming Profile Configuration</member>
+ <member>Configuration of System Policy handling</member>
+ <member>Installation of the Network driver "Client for MS Windows Networks" and configuration
+ to log onto the domain</member>
+ <member>Placing Windows 9x / Me clients in user level security - if it is desired to allow
+ all client share access to be controlled according to domain user / group identities.</member>
+ <member>Adding and managing domain user accounts</member>
+</simplelist>
<note><para>
Roaming Profiles and System/Network policies are advanced network administration topics
<listitem><para>
The server must support domain logons and have a
- <filename>[netlogon]</filename> share
+ <parameter>[netlogon]</parameter> share
</para></listitem>
<listitem><para>
<para>
All Domain Controllers must run the netlogon service (<emphasis>domain logons</emphasis>
-in Samba. One Domain Controller must be configured with <emphasis>domain master = Yes</emphasis>
-(the Primary Domain Controller), on ALL Backup Domain Controllers <emphasis>domain master = No</emphasis>
+in Samba. One Domain Controller must be configured with <parameter>domain master = Yes</parameter>
+(the Primary Domain Controller), on ALL Backup Domain Controllers <parameter>domain master = No</parameter>
must be set.
</para>
<title>Example Configuration</title>
<programlisting>
-<title> A minimal configuration to support Domain Logons</title>
-<para>
[globals]
domain logons = Yes
domain master = (Yes on PDC, No on BDCs)
path = /var/lib/samba/netlogon
guest ok = Yes
browseable = No
-</para>
</programlisting>
</sect3>
a NetLogon request. This is sent to the NetBIOS name DOMAIN<#1c> at the
NetBIOS layer. The client chooses the first response it receives, which
contains the NetBIOS name of the logon server to use in the format of
- \\SERVER.
+ <filename>\\SERVER</filename>.
</para>
</listitem>
<para>
The client then connects to the user's home share and searches for the
user's profile. As it turns out, you can specify the user's home share as
- a sharename and path. For example, \\server\fred\.winprofile.
+ a sharename and path. For example, <filename>\\server\fred\.winprofile</filename>.
If the profiles are found, they are implemented.
</para>
</listitem>
<listitem>
<para>
The client then disconnects from the user's home share, and reconnects to
- the NetLogon share and looks for CONFIG.POL, the policies file. If this is
+ the NetLogon share and looks for <filename>CONFIG.POL</filename>, the policies file. If this is
found, it is read and implemented.
</para>
</listitem>
<para>
Now back to the issue of configuring a Samba DC to use a mode other
-than <emphasis>security = user</emphasis>. If a Samba host is configured to use
+than <parameter>security = user</parameter>. If a Samba host is configured to use
another SMB server or DC in order to validate user connection
requests, then it is a fact that some other machine on the network
-(the <emphasis>password server</emphasis>) knows more about the user than the Samba host.
+(the <parameter>password server</parameter>) knows more about the user than the Samba host.
99% of the time, this other host is a domain controller. Now
-in order to operate in domain mode security, the <emphasis>workgroup</emphasis> parameter
+in order to operate in domain mode security, the <parameter>workgroup</parameter> parameter
must be set to the name of the Windows NT domain (which already
has a domain controller). If the domain does NOT already have a Domain Controller
then you do not yet have a Domain!
<para>
Configuring a Samba box as a DC for a domain that already by definition has a
PDC is asking for trouble. Therefore, you should always configure the Samba DC
-to be the DMB for its domain and set <emphasis>security = user</emphasis>.
+to be the DMB for its domain and set <parameter>security = user</parameter>.
This is the only officially supported mode of operation.
</para>
will remove all network drive connections:
</para>
-<para>
-<prompt>C:\WINNT\></prompt> <command>net use * /d</command>
-</para>
+<screen>
+ <prompt>C:\WINNT\></prompt> <userinput>net use * /d</userinput>
+</screen>
<para>
Further, if the machine is already a 'member of a workgroup' that
<title>The system can not log you on (C000019B)....</title>
<para>I joined the domain successfully but after upgrading
-to a newer version of the Samba code I get the message, "The system
+to a newer version of the Samba code I get the message, <errorname>The system
can not log you on (C000019B), Please try again or consult your
-system administrator" when attempting to logon.
+system administrator</errorname> when attempting to logon.
</para>
<para>
<para>
The reset or change the domain SID you can use the net command as follows:
-<programlisting>
- net getlocalsid 'OLDNAME'
- net setlocalsid 'SID'
-</programlisting>
+<screen>
+<prompt>$ </prompt><userinput>net getlocalsid 'OLDNAME'</userinput>
+<prompt>$ </prompt><userinput>net setlocalsid 'SID'</userinput>
+</screen>
</para>
</sect2>
exist or is not accessible.</title>
<para>
-When I try to join the domain I get the message "The machine account
-for this computer either does not exist or is not accessible". What's
+When I try to join the domain I get the message <errorname>The machine account
+for this computer either does not exist or is not accessible</errorname>. What's
wrong?
</para>
I get a message about my account being disabled.</title>
<para>
-At first be ensure to enable the useraccounts with <command>smbpasswd -e
-%user%</command>, this is normally done, when you create an account.
+At first be ensure to enable the useraccounts with <userinput>smbpasswd -e
+<replaceable>username</replaceable></userinput>, this is normally done, when you create an account.
</para>
</sect2>
<itemizedlist>
<listitem><para>Domain Controller</para>
- <itemizedlist>
- <listitem><para>Primary Domain Controller</para></listitem>
- <listitem><para>Backup Domain Controller</para></listitem>
- <listitem><para>ADS Domain Controller</para></listitem>
- </itemizedlist>
+ <simplelist>
+ <member>Primary Domain Controller</member>
+ <member>Backup Domain Controller</member>
+ <member>ADS Domain Controller</member>
+ </simplelist>
</listitem>
<listitem><para>Domain Member Server</para>
- <itemizedlist>
- <listitem><para>Active Directory Member Server</para></listitem>
- <listitem><para>NT4 Style Domain Member Server</para></listitem>
- </itemizedlist>
+ <simplelist>
+ <member>Active Directory Member Server</member>
+ <member>NT4 Style Domain Member Server</member>
+ </simplelist>
</listitem>
<listitem><para>Stand Alone Server</para></listitem>
</itemizedlist>
<title>Samba Security Modes</title>
<para>
-In this section the function and purpose of Samba's <emphasis>security</emphasis>
+In this section the function and purpose of Samba's <parameter>security</parameter>
modes are described. An acurate understanding of how Samba implements each security
mode as well as how to configure MS Windows clients for each mode will significantly
reduce user complaints and administrator heartache.
ways that allow the security levels to be implemented. In actual fact, Samba implements
<emphasis>SHARE Level</emphasis> security only one way, but has for ways of implementing
<emphasis>USER Level</emphasis> security. Collectively, we call the samba implementations
-<emphasis>Security Modes</emphasis>. These are: <emphasis>SHARE, USER, DOMAIN, ADS, and SERVER</emphasis>
+<emphasis>Security Modes</emphasis>. These are: <emphasis>SHARE</emphasis>, <emphasis>USER</emphasis>, <emphasis>DOMAIN</emphasis>,
+<emphasis>ADS</emphasis>, and <emphasis>SERVER</emphasis>
modes. They are documented in this chapter.
</para>
<para>
-A SMB server tells the client at startup what <emphasis>security level</emphasis>
+A SMB server tells the client at startup what <parameter>security level</parameter>
it is running. There are two options <emphasis>share level</emphasis> and
<emphasis>user level</emphasis>. Which of these two the client receives affects
the way the client then tries to authenticate itself. It does not directly affect
<title>User Level Security</title>
<para>
-We will describe<emphasis>user level</emphasis> security first, as its simpler.
+We will describe<parameter>user level</parameter> security first, as its simpler.
In <emphasis>user level</emphasis> security the client will send a
<emphasis>session setup</emphasis> command directly after the protocol negotiation.
This contains a username and password. The server can either accept or reject that
this username in a list of <emphasis>possible usernames</emphasis>. When the client
then does a <emphasis>tree connection</emphasis> it also adds to this list the name
of the share they try to connect to (useful for home directories) and any users
-listed in the <command>user =</command> &smb.conf; line. The password is then checked
+listed in the <parameter>user =</parameter> &smb.conf; line. The password is then checked
in turn against these <emphasis>possible usernames</emphasis>. If a match is found
then the client is authenticated as that user.
</para>
<title>Domain Security Mode (User Level Security)</title>
<para>
-When samba is operating in <emphasis>security = domain</emphasis> mode this means that
+When samba is operating in <parameter>security = domain</parameter> mode this means that
the Samba server has a domain security trust account (a machine account) and will cause
all authentication requests to be passed through to the domain controllers.
</para>
</programlisting></para>
<para>
-The use of the "*" argument to <command>password server</command> will cause samba to locate the
+The use of the "*" argument to <parameter>password server</parameter> will cause samba to locate the
domain controller in a way analogous to the way this is done within MS Windows NT.
This is the default behaviour.
</para>
security domain. This is done as follows:
</para>
-<itemizedlist>
- <
listitem><para>On the MS Windows NT domain controller using
+<procedure>
+ <
step><para>On the MS Windows NT domain controller using
the Server Manager add a machine account for the Samba server.
- </para></listitem>
+ </para></step>
- <
listitem><para>Next, on the Unix/Linux system execute:</para>
- <para><programlisting>
- <command>smbpasswd -r PDC_NAME -j DOMAIN_NAME</command> (samba 2.x)
+ <
step><para>Next, on the Unix/Linux system execute:</para>
+
+ <para>&rootprompt;<userinput>smbpasswd -r PDC_NAME -j DOMAIN_NAME</userinput> (samba 2.x)</para>
- <command>net join -U administrator%password</command> (samba-3)
- </programlisting>
- </para>
- </listitem>
-</itemizedlist>
+ <para>&rootprompt;<userinput>net join -U administrator%password</userinput> (samba-3)</para>
+ </step>
+</procedure>
<note><para>
As of Samba-2.2.4 the Samba 2.2.x series can auto-join a Windows NT4 style Domain just
by executing:
-<programlisting>
- smbpasswd -j DOMAIN_NAME -r PDC_NAME -U Administrator%password
-</programlisting>
+<screen>
+&rootprompt;<userinput>smbpasswd -j <replaceable>DOMAIN_NAME</replaceable> -r <replaceable>PDC_NAME</replaceable> -U Administrator%<replaceable>password</replaceable></userinput>
+</screen>
As of Samba-3 the same can be done by executing:
-<programlisting>
- net join -U Administrator%password
-</programlisting>
-It is not necessary with Samba-3 to specify the DOMAIN_NAME or the PDC_NAME as it figures this
-out from the smb.conf file settings.
+<screen>
+ &rootprompt;<userinput>net join -U Administrator%<replaceable>password</replaceable></userinput>
+</screen>
+It is not necessary with Samba-3 to specify the <replaceable>DOMAIN_NAME</replaceable> or the <replaceable>PDC_NAME</replaceable> as it
+figures this out from the &smb.conf; file settings.
</para></note>
<para>
<sect3>
<title>Example Configuration</title>
-<para>
-<programlisting>
+<para><programlisting>
realm = your.kerberos.REALM
security = ADS
encrypt passwords = Yes
+</programlisting></para>
-The following parameter may be required:
+<para>
+ The following parameter may be required:
+</para>
+<para><programlisting>
ads server = your.kerberos.server
-</programlisting>
-</para>
+</programlisting></para>
<para>
Please refer to the Domain Membership section, Active Directory Membership for more information
security has many draw backs. The draw backs include:
</para>
-<itemizedlist>
- <listitem><para>Potential Account Lockout on MS Windows NT4/200x password servers</para></listitem>
- <listitem><para>Lack of assurance that the password server is the one specified</para></listitem>
- <listitem><para>Does not work with Winbind, particularly needed when storing profiles remotely</para></listitem>
- <listitem><para>This mode may open connections to the password server, and keep them open for extended periods.</para></listitem>
- <listitem><para>Security on the samba server breaks badly when the remote password server suddenly shuts down</para></listitem>
- <listitem><para>With this mode there is NO security account in the domain that the password server belongs to for the samba server.</para></listitem>
-</itemizedlist>
+<simplelist>
+ <member>Potential Account Lockout on MS Windows NT4/200x password servers</member>
+ <member>Lack of assurance that the password server is the one specified</member>
+ <member>Does not work with Winbind, particularly needed when storing profiles remotely</member>
+ <member>This mode may open connections to the password server, and keep them open for extended periods.</member>
+ <member>Security on the samba server breaks badly when the remote password server suddenly shuts down</member>
+ <member>With this mode there is NO security account in the domain that the password server belongs to for the samba server.</member>
+</simplelist>
<para>
In server level security the samba server reports to the client that it is in user level
security. The client then does a <emphasis>session setup</emphasis> as described earlier.
The samba server takes the username/password that the client sends and attempts to login to the
-<emphasis>password server</emphasis> by sending exactly the same username/password that
+<parameter>password server</parameter> by sending exactly the same username/password that
it got from the client. If that server is in user level security and accepts the password
then samba accepts the clients connection. This allows the samba server to use another SMB
-server as the <emphasis>password server</emphasis>.
+server as the <parameter>password server</parameter>.
</para>
<para>
</para>
<para>
-The parameter <emphasis>security = server</emphasis> means that Samba reports to clients that
+The parameter <parameter>security = server</parameter> means that Samba reports to clients that
it is running in <emphasis>user mode</emphasis> but actually passes off all authentication
requests to another <emphasis>user mode</emphasis> server. This requires an additional
-parameter <emphasis>password server</emphasis> that points to the real authentication server.
+parameter <parameter>password server</parameter> that points to the real authentication server.
That real authentication server can be another Samba server or can be a Windows NT server,
the later natively capable of encrypted password support.
</para>
<para>
To some the nature of the samba <emphasis>security</emphasis> mode is very obvious, but entirely
-wrong all the same. It is assumed that <emphasis>security = server</emphasis> means that Samba
+wrong all the same. It is assumed that <parameter>security = server</parameter> means that Samba
will act as a server. Not so! See above - this setting means that samba will <emphasis>try</emphasis>
to use another SMB server as it's source of user authentication alone.
</para>
<title>What makes Samba a Domain Controller?</title>
<para>
-The &smb.conf; parameter <emphasis>security = domain</emphasis> does NOT really make Samba behave
+The &smb.conf; parameter <parameter>security = domain</parameter> does NOT really make Samba behave
as a Domain Controller! This setting means we want samba to be a domain member!
</para>
<title>What makes Samba a Domain Member?</title>
<para>
-Guess! So many others do. But whatever you do, do NOT think that <emphasis>security = user</emphasis>
+Guess! So many others do. But whatever you do, do NOT think that <parameter>security = user</parameter>
makes Samba act as a domain member. Read the manufacturers manual before the warranty expires!
</para>
<para>
The socket options that Samba uses are settable both on the command
-line with the -O option, or in the smb.conf file.
+line with the <option>-O</option> option, or in the &smb.conf; file.
</para>
<para>
-The <command>socket options</command> section of the &smb.conf; manual page describes how
+The <parameter>socket options</parameter> section of the &smb.conf; manual page describes how
to set these and gives recommendations.
</para>
<para>
The socket option TCP_NODELAY is the one that seems to make the
biggest single difference for most networks. Many people report that
-adding <command>socket options = TCP_NODELAY</command> doubles the read
+adding <parameter>socket options = TCP_NODELAY</parameter> doubles the read
performance of a Samba drive. The best explanation I have seen for this is
that the Microsoft TCP/IP stack is slow in sending tcp ACKs.
</para>
<title>Read size</title>
<para>
-The option <command>read size</command> affects the overlap of disk
+The option <parameter>read size</parameter> affects the overlap of disk
reads/writes with network reads/writes. If the amount of data being
transferred in several of the SMB commands (currently SMBwrite, SMBwriteX and
SMBreadbraw) is larger than this value then the server begins writing
<title>Max xmit</title>
<para>
-At startup the client and server negotiate a <command>maximum transmit</command> size,
+At startup the client and server negotiate a <parameter>maximum transmit</parameter> size,
which limits the size of nearly all SMB commands. You can set the
-maximum size that Samba will negotiate using the <command>max xmit = </command> option
+maximum size that Samba will negotiate using the <parameter>max xmit = </parameter> option
in &smb.conf;. Note that this is the maximum size of SMB requests that
Samba will accept, but not the maximum size that the *client* will accept.
The client maximum receive size is sent to Samba by the client and Samba
<title>Log level</title>
<para>
-If you set the log level (also known as <command>debug level</command>) higher than 2
+If you set the log level (also known as <parameter>debug level</parameter>) higher than 2
then you may suffer a large drop in performance. This is because the
server flushes the log file after each operation, which can be very
expensive.
<title>Read raw</title>
<para>
-The <command>read raw</command> operation is designed to be an optimised, low-latency
+The <parameter>read raw</parameter> operation is designed to be an optimised, low-latency
file read operation. A server may choose to not support it,
-however. and Samba makes support for <command>read raw</command> optional, with it
+however. and Samba makes support for <parameter>read raw</parameter> optional, with it
being enabled by default.
</para>
<para>
-In some cases clients don't handle <command>read raw</command> very well and actually
+In some cases clients don't handle <parameter>read raw</parameter> very well and actually
get lower performance using it than they get using the conventional
read operations.
</para>
<para>
-So you might like to try <command>read raw = no</command> and see what happens on your
+So you might like to try <parameter>read raw = no</parameter> and see what happens on your
network. It might lower, raise or not affect your performance. Only
testing can really tell.
</para>
<title>Write raw</title>
<para>
-The <command>write raw</command> operation is designed to be an optimised, low-latency
+The <parameter>write raw</parameter> operation is designed to be an optimised, low-latency
file write operation. A server may choose to not support it,
-however. and Samba makes support for <command>write raw</command> optional, with it
+however. and Samba makes support for <parameter>write raw</parameter> optional, with it
being enabled by default.
</para>
<para>
-Some machines may find <command>write raw</command> slower than normal write, in which
+Some machines may find <parameter>write raw</parameter> slower than normal write, in which
case you may wish to change this option.
</para>
<para>
Slow logins are almost always due to the password checking time. Using
-the lowest practical <command>password level</command> will improve things.
+the lowest practical <parameter>password level</parameter> will improve things.
</para>
</sect1>
<para>
LDAP can be vastly improved by using the
-<ulink url="smb.conf.5.html#LDAPTRUSTIDS">ldap trust ids</ulink> parameter.
+<ulink url="smb.conf.5.html#LDAPTRUSTIDS"><parameter>ldap trust ids</parameter></ulink> parameter.
</para>
</sect1>
(the name service switcher) the source of authentication may reside on
another server. We would be inclined to call this the authentication server.
This means that the samba server may use the local Unix/Linux system password database
-(/etc/passwd or /etc/shadow), may use a local smbpasswd file, or may use
+(<filename>/etc/passwd</filename> or <filename>/etc/shadow</filename>), may use a
+local smbpasswd file, or may use
an LDAP back end, or even via PAM and Winbind another CIFS/SMB server
for authentication.
</para>
Unix system database. This is a very simple system to administer.
</para>
-<para>
<programlisting>
- <title>Share Mode Read Only Stand-Alone Server</title>
# Global parameters
[global]
workgroup = MYGROUP
path = /export
guest only = Yes
</programlisting>
-</para>
<para>
In the above example the machine name is set to REFDOCS, the workgroup is set to the name
The default for this is usually the account <command>nobody</command>.
To find the correct name to use for your version of Samba do the
following:
- <programlisting>
- testparm -s -v | grep "guest account"
- </programlisting>
+ <screen>
+<prompt>$ </prompt><userinput>testparm -s -v | grep "guest account"</userinput>
+ </screen>
Then make sure that this account exists in your system password
database (<filename>/etc/passwd</filename>).
</para></listitem>
The directory into which Samba will spool the file must have write
access for the guest account. The following commands will ensure that
this directory is available for use:
- <programlisting>
- mkdir /var/spool/samba
- chown nobody.nobody /var/spool/samba
- chmod a+rwt /var/spool/samba
- </programlisting>
+ <screen>
+&rootprompt;<userinput>mkdir /var/spool/samba</userinput>
+&rootprompt;<userinput>chown nobody.nobody /var/spool/samba</userinput>
+&rootprompt;<userinput>chmod a+rwt /var/spool/samba</userinput>
+ </screen>
</para></listitem>
</itemizedlist>
<para>
<programlisting>
- <title>Simple Central Print Server</title>
# Global parameters
[global]
workgroup = MYGROUP
<title>Configuring samba (smb.conf)</title>
<para>
- Samba's configuration is stored in the smb.conf file,
+ Samba's configuration is stored in the &smb.conf; file,
that usually resides in <filename>/etc/samba/smb.conf</filename>
or <filename>/usr/local/samba/lib/smb.conf</filename>. You can either
edit this file yourself or do it using one of the many graphical
<para>
This will allow connections by anyone with an account on the server, using either
- their login name or "<command>homes</command>" as the service name.
+ their login name or "<parameter>homes</parameter>" as the service name.
(Note that the workgroup that Samba must also be set.)
</para>
<para>
For more information about security settings for the
- <command>[homes]</command> share please refer to the chapter
+ <parameter>[homes]</parameter> share please refer to the chapter
<link linkend="securing-samba">Securing Samba</link>.
</para>
<para>
It's important that you test the validity of your <filename>smb.conf</filename>
- file using the <application>testparm</application> program. If testparm runs OK
+ file using the &testparm; program. If testparm runs OK
then it will list the loaded services. If not it will give an error message.
</para>
</para>
<para>
- Always run testparm again when you change <filename>smb.conf</filename>!
+ Always run testparm again when you change &smb.conf;!
</para>
</sect3>
<para>
To launch SWAT just run your favorite web browser and
- point it at "http://localhost:901/". Replace
+ point it at <ulink url="http://localhost:901/">http://localhost:901/</ulink>. Replace
<replaceable>localhost</replaceable>
with the name of the computer you are running samba on if you
are running samba on a different computer than your browser.
would be the name of the host where you installed &smbd;.
The <replaceable>aservice</replaceable> is
any service you have defined in the &smb.conf;
- file. Try your user name if you just have a <command>[homes]</command>
+ file. Try your user name if you just have a <parameter>[homes]</parameter>
section
in &smb.conf;.</para>
<para>
Site that is running Samba on an AIX box. They are sharing out about 2 terabytes using samba.
Samba was installed using smitty and the binaries. We seem to be experiencing a memory problem
-with this box. When I do a svmon -Pu the monitoring program shows that smbd has several
+with this box. When I do a <command>svmon -Pu</command> the monitoring program shows that &smbd; has several
processes of smbd running:
</para>
</para>
<para>
-<programlisting>
+<screen>
Inuse * 4096 = amount of memory being used by this process
Pid Command Inuse Pin Pgsp Virtual 64-bit Mthrd
19110 smbd 8404 1906 181 4862 N N
Total memory used: 841,592,832 bytes
-</programlisting>
+</screen>
</para>
<para>
<emphasis>ANSWER:</emphasis> Samba consists on three core programs:
-<emphasis>nmbd, smbd, winbindd</emphasis>. <command>nmbd</command> is the name server message daemon,
-<command>smbd</command> is the server message daemon, <command>winbind</command> is the daemon that
+&nmbd;, &smbd;, &winbindd;. &nmbd; is the name server message daemon,
+&smbd; is the server message daemon, &winbindd; is the daemon that
handles communication with Domain Controllers.
</para>
<para>
If your system is NOT running as a WINS server, then there will be one (1) single instance of
- <command>nmbd</command> running on your system. If it is running as a WINS server then there will be
+ &nmbd; running on your system. If it is running as a WINS server then there will be
two (2) instances - one to handle the WINS requests.
</para>
<para>
-<command>smbd</command> handles ALL connection requests and then spawns a new process for each client
+&smbd; handles ALL connection requests and then spawns a new process for each client
connection made. That is why you are seeing so many of them, one (1) per client connection.
</para>
<para>
-<command>winbindd</command> will run as one or two daemons, depending on whether or not it is being
+&winbindd; will run as one or two daemons, depending on whether or not it is being
run in "split mode" (in which case there will be two instances).
</para>
<para>
To use the VFS modules, create a share similar to the one below. The
-important parameter is the <command>vfs object</command> parameter which must point to
+important parameter is the <parameter>vfs object</parameter> parameter which must point to
the exact pathname of the shared library objects. For example, to log all access
to files and use a recycle bin:
-<screen>
- [audit]
- comment = Audited /data directory
- path = /data
- vfs object = /path/to/audit.so /path/to/recycle.so
- writeable = yes
- browseable = yes
-</screen>
+<programlisting>
+[audit]
+ comment = Audited /data directory
+ path = /data
+ vfs object = /path/to/audit.so /path/to/recycle.so
+ writeable = yes
+ browseable = yes
+</programlisting>
</para>
<para>
<para>
The logging information that will be written to the smbd log file is controlled by
- the <emphasis>log level</emphasis> parameter in <filename>smb.conf</filename>. The
+ the <parameter>log level</parameter> parameter in <filename>smb.conf</filename>. The
following information will be recorded:
</para>
<para>Advantages compared to the old netatalk module:
<simplelist>
<member>it doesn't care about creating of .AppleDouble forks, just keeps them in sync</member>
- <member>if share in smb.conf doesn't contain .AppleDouble item in hide or veto list, it will be added automatically</member>
+ <member>if a share in &smb.conf; doesn't contain .AppleDouble item in hide or veto list, it will be added automatically</member>
</simplelist>
</para>
</para>
<para>
-No statemets about the stability or functionality of any module
+No statements about the stability or functionality of any module
should be implied due to its presence here.
</para>
Samba may be secured from connections that originate from outside the local network. This may be
done using <emphasis>host based protection</emphasis> (using samba's implementation of a technology
known as "tcpwrappers", or it may be done be using <emphasis>interface based exclusion</emphasis>
-so that <command>smbd</command> will bind only to specifically permitted interfaces. It is also
+so that &smbd; will bind only to specifically permitted interfaces. It is also
possible to set specific share or resource based exclusions, eg: on the <parameter>IPC$</parameter>
auto-share. The <parameter>IPC$</parameter> share is used for browsing purposes as well as to establish
TCP/IP connections.
</para>
<para>
- One of the simplest fixes in this case is to use the <command>hosts allow</command> and
- <command>hosts deny</command> options in the Samba &smb.conf; configuration file to only
+ One of the simplest fixes in this case is to use the <parameter>hosts allow</parameter> and
+ <parameter>hosts deny</parameter> options in the Samba &smb.conf; configuration file to only
allow access to your server from a specific range of hosts. An example
might be:
</para>
- <para><screen>
+ <para><programlisting>
hosts allow = 127.0.0.1 192.168.2.0/24 192.168.3.0/24
hosts deny = 0.0.0.0/0
- </screen></para>
+ </programlisting></para>
<para>
The above will only allow SMB connections from 'localhost' (your own
computer) and from the two private networks 192.168.2 and
192.168.3. All other connections will be refused as soon
as the client sends its first packet. The refusal will be marked as a
- 'not listening on called name' error.
+ <errorname>not listening on called name</errorname> error.
</para>
</sect2>
<para>
If you want to restrict access to your server to valid users only then the following
- method may be of use. In the smb.conf [globals] section put:
+ method may be of use. In the &smb.conf; <parameter>[globals]</parameter> section put:
</para>
- <para><screen>
+ <para><programlisting>
valid users = @smbusers, jacko
- </screen></para>
+ </programlisting></para>
<para>
What this does is, it restricts all server access to either the user <emphasis>jacko</emphasis>
You can change this behaviour using options like the following:
</para>
- <para><screen>
+ <para><programlisting>
interfaces = eth* lo
bind interfaces only = yes
- </screen></para>
+ </programlisting></para>
<para>
This tells Samba to only listen for connections on interfaces with a
UDP ports to allow and block. Samba uses the following:
</para>
- <para><screen>
- UDP/137 - used by nmbd
- UDP/138 - used by nmbd
- TCP/139 - used by smbd
- TCP/445 - used by smbd
- </screen></para>
+ <simplelist>
+ <member>UDP/137 - used by nmbd</member>
+ <member>UDP/138 - used by nmbd</member>
+ <member>TCP/139 - used by smbd</member>
+ <member>TCP/445 - used by smbd</member>
+ </simplelist>
<para>
The last one is important as many older firewall setups may not be
To do that you could use:
</para>
- <para><screen>
- [ipc$]
- hosts allow = 192.168.115.0/24 127.0.0.1
- hosts deny = 0.0.0.0/0
- </screen></para>
+ <para><programlisting>
+[ipc$]
+ hosts allow = 192.168.115.0/24 127.0.0.1
+ hosts deny = 0.0.0.0/0
+ </programlisting></para>
<para>
this would tell Samba that IPC$ connections are not allowed from
</para>
<para>
- If you use this method then clients will be given a 'access denied'
+ If you use this method then clients will be given a <errorname>access denied</errorname>
reply when they try to access the IPC$ share. That means that those
clients will not be able to browse shares, and may also be unable to
access some other resources.
To configure NTLMv2 authentication the following registry keys are worth knowing about:
</para>
+ <!-- FIXME -->
<para>
<screen>
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
<variablelist>
<varlistentry>
- <term>unix charset</term>
+ <term><parameter>unix charset</parameter></term>
<listitem><para>
This is the charset used internally by your operating system.
The default is <constant>ASCII</constant>, which is fine for most
</varlistentry>
<varlistentry>
- <term>display charset</term>
+ <term><parameter>display charset</parameter></term>
<listitem><para>This is the charset samba will use to print messages
on your screen. It should generally be the same as the <command>unix charset</command>.
</para></listitem>
</varlistentry>
<varlistentry>
- <term>dos charset</term>
+ <term><parameter>dos charset</parameter></term>
<listitem><para>This is the charset samba uses when communicating with
DOS and Windows 9x clients. It will talk unicode to all newer clients.
The default depends on the charsets you have installed on your system.
<itemizedlist>
-<listitem><para>You should set <command>mangling method =
-hash</command></para></listitem>
+<listitem><para>You should set <parameter>mangling method =
+hash</parameter></para></listitem>
<listitem><para>There are various iconv() implementations around and not
all of them work equally well. glibc2's iconv() has a critical problem
in CP932. libiconv-1.8 works with CP932 but still has some problems and
does not work with EUC-JP.</para></listitem>
-<listitem><para>You should set <command>dos charset = CP932</command>, not
+<listitem><para>You should set <parameter>dos charset = CP932</parameter>, not
Shift_JIS, SJIS...</para></listitem>
-<listitem><para>Currently only <command>unix charset = CP932</command>
+<listitem><para>Currently only <parameter>unix charset = CP932</parameter>
will work (but still has some problems...) because of iconv() issues.
-<command>unix charset = EUC-JP</command> doesn't work well because of
+<parameter>unix charset = EUC-JP</parameter> doesn't work well because of
iconv() issues.</para></listitem>
-<listitem><para>Currently Samba 3.0 does not support <command>unix charset
-= UTF8-MAC/CAP/HEX/JIS*</command></para></listitem>
+<listitem><para>Currently Samba 3.0 does not support <parameter>unix charset
+= UTF8-MAC/CAP/HEX/JIS*</parameter></para></listitem>
</itemizedlist>
</affiliation>
</author>
&author.tridge;
- &author.jht;
<author>
<firstname>Naag</firstname><surname>Mummaneni</surname>
<affiliation>
of that service should be tried and in what order. If the passwd
config line is:</para>
- <para><command>passwd: files example</command></para>
+ <para><programlisting>
+passwd: files example
+ </programlisting></para>
<para>then the C library will first load a module called
<filename>/lib/libnss_files.so</filename> followed by
<para>
Before starting, it is probably best to kill off all the SAMBA
-related daemons running on your server. Kill off all <command>smbd</command>,
-<command>nmbd</command>, and <command>winbindd</command> processes that may
+related daemons running on your server. Kill off all &smbd;,
+&nmbd;, and &winbindd; processes that may
be running. To use PAM, you will want to make sure that you have the
standard PAM package (for RedHat) which supplies the <filename>/etc/pam.d</filename>
directory structure, including the pam modules are used by pam-aware
services, several pam libraries, and the <filename>/usr/doc</filename>
and <filename>/usr/man</filename> entries for pam. Winbind built better
in SAMBA if the pam-devel package was also installed. This package includes
-the header files needed to compile pam-aware applications. For instance,
-my RedHat system has both <filename>pam-0.74-22</filename> and
-<filename>pam-devel-0.74-22</filename> RPMs installed.
+the header files needed to compile pam-aware applications.
</para>
<sect3>
whether or not you have previously built the Samba binaries.
</para>
-<para><programlisting>
-<prompt>root#</prompt> <command>autoconf</command>
-<prompt>root#</prompt> <command>make clean</command>
-<prompt>root#</prompt> <command>rm config.cache</command>
-<prompt>root#</prompt> <command>./configure</command>
-<prompt>root#</prompt> <command>make</command>
-<prompt>root#</prompt> <command>make install</command>
-</programlisting></para>
+<para><screen>
+&rootprompt;<command>autoconf</command>
+&rootprompt;<command>make clean</command>
+&rootprompt;<command>rm config.cache</command>
+&rootprompt;<command>./configure</command>
+&rootprompt;<command>make</command>
+&rootprompt;<command>make install</command>
+</screen></para>
<para>
winbind libraries on Linux and Solaris</title>
<para>
-The libraries needed to run the <command>winbindd</command> daemon
+The libraries needed to run the &winbindd; daemon
through nsswitch need to be copied to their proper locations, so
</para>
<para>
-<prompt>root#</prompt> <command>cp ../samba/source/nsswitch/libnss_winbind.so /lib</command>
+<screen>
+&rootprompt;<userinput>cp ../samba/source/nsswitch/libnss_winbind.so /lib</userinput>
+</screen>
</para>
<para>
</para>
<para>
-<prompt>root#</prompt> <command>ln -s /lib/libnss_winbind.so /lib/libnss_winbind.so.2</command>
+&rootprompt; <userinput>ln -s /lib/libnss_winbind.so /lib/libnss_winbind.so.2</userinput>
</para>
<para>And, in the case of Sun solaris:</para>
-<para>
-<prompt>root#</prompt> <userinput>ln -s /usr/lib/libnss_winbind.so /usr/lib/libnss_winbind.so.1</userinput>
-<prompt>root#</prompt> <userinput>ln -s /usr/lib/libnss_winbind.so /usr/lib/nss_winbind.so.1</userinput>
-<prompt>root#</prompt> <userinput>ln -s /usr/lib/libnss_winbind.so /usr/lib/nss_winbind.so.2</userinput>
-</para>
+<screen>
+&rootprompt;<userinput>ln -s /usr/lib/libnss_winbind.so /usr/lib/libnss_winbind.so.1</userinput>
+&rootprompt;<userinput>ln -s /usr/lib/libnss_winbind.so /usr/lib/nss_winbind.so.1</userinput>
+&rootprompt;<userinput>ln -s /usr/lib/libnss_winbind.so /usr/lib/nss_winbind.so.2</userinput>
+</screen>
<para>
Now, as root you need to edit <filename>/etc/nsswitch.conf</filename> to
-allow user and group entries to be visible from the <command>winbindd</command>
+allow user and group entries to be visible from the &winbindd;
daemon. My <filename>/etc/nsswitch.conf</filename> file look like
this after editing:
</para>
</para>
<para>
-<prompt>root#</prompt> <command>/sbin/ldconfig -v | grep winbind</command>
+&rootprompt;<userinput>/sbin/ldconfig -v | grep winbind</userinput>
</para>
<para>
<para>
Several parameters are needed in the smb.conf file to control
-the behavior of <command>winbindd</command>. Configure
-<filename>smb.conf</filename> These are described in more detail in
+the behavior of &winbindd;. Configure
+&smb.conf; These are described in more detail in
the <citerefentry><refentrytitle>winbindd</refentrytitle>
<manvolnum>8</manvolnum></citerefentry> man page. My
-<filename>smb.conf</filename> file was modified to
+&smb.conf; file was modified to
include the following entries in the [global] section:
</para>
<para>
-<prompt>root#</prompt> <command>/usr/local/samba/bin/net join -S PDC -U Administrator</command>
+&rootprompt;<userinput>/usr/local/samba/bin/net join -S PDC -U Administrator</userinput>
</para>
</para>
<para>
-<prompt>root#</prompt> <command>/usr/local/samba/bin/winbindd</command>
+&rootprompt;<userinput>/usr/local/samba/bin/winbindd</userinput>
</para>
<para>
thus making responses to clients faster. The other will
update the cache for the query that the first has just responded.
Advantage of this is that responses stay accurate and are faster.
-You can enable dual daemon mode by adding '-B' to the commandline:
+You can enable dual daemon mode by adding <option>-B</option> to the commandline:
</para>
<para>
-<prompt>root#</prompt> <command>/usr/local/samba/bin/winbindd -B</command>
+&rootprompt;<userinput>/usr/local/samba/bin/winbindd -B</userinput>
</para>
<para>
</para>
<para>
-<prompt>root#</prompt> <command>ps -ae | grep winbindd</command>
+&rootprompt;<userinput>ps -ae | grep winbindd</userinput>
</para>
<para>
This command should produce output like this, if the daemon is running
</para>
-<para>
+<screen>
3025 ? 00:00:00 winbindd
-</para>
+</screen>
<para>
Now... for the real test, try to get some information about the
</para>
<para>
-<prompt>root#</prompt> <command>/usr/local/samba/bin/wbinfo -u</command>
+&rootprompt;<userinput>/usr/local/samba/bin/wbinfo -u</userinput>
</para>
<para>
your PDC. For example, I get the following response:
</para>
-<para><programlisting>
+<para><screen>
CEO+Administrator
CEO+burdell
CEO+Guest
CEO+jt-ad
CEO+krbtgt
CEO+TsInternetUser
-</programlisting></para>
+</screen></para>
<para>
Obviously, I have named my domain 'CEO' and my <parameter>winbind
the PDC:
</para>
-<para><programlisting>
-<prompt>root#</prompt> <command>/usr/local/samba/bin/wbinfo -g</command>
+<para><screen>
+&rootprompt;<userinput>/usr/local/samba/bin/wbinfo -g</userinput>
CEO+Domain Admins
CEO+Domain Users
CEO+Domain Guests
CEO+Schema Admins
CEO+Enterprise Admins
CEO+Group Policy Creator Owners
-</programlisting></para>
+</screen></para>
<para>
The function 'getent' can now be used to get unified
</para>
<para>
-<prompt>root#</prompt> <command>getent passwd</command>
+&rootprompt;<userinput>getent passwd</userinput>
</para>
<para>
</para>
<para>
-<prompt>root#</prompt> <command>getent group</command>
+&rootprompt;<userinput>getent group</userinput>
</para>
</sect3>
<title>Linux</title>
<para>
-The <command>winbindd</command> daemon needs to start up after the
-<command>smbd</command> and <command>nmbd</command> daemons are running.
+The &winbindd; daemon needs to start up after the
+&smbd; and &nmbd; daemons are running.
To accomplish this task, you need to modify the startup scripts of your system.
They are located at <filename>/etc/init.d/smb</filename> in RedHat and
<filename>/etc/init.d/samba</filename> in Debian.
script to add commands to invoke this daemon in the proper sequence. My
-startup script starts up <command>smbd</command>,
-<command>nmbd</command>, and <command>winbindd</command> from the
+startup script starts up &smbd;, &nmbd;, and &winbindd; from the
<filename>/usr/local/samba/bin</filename> directory directly. The 'start'
function in the script looks like this:
</para>
<sect4>
<title>Restarting</title>
<para>
-If you restart the <command>smbd</command>, <command>nmbd</command>,
-and <command>winbindd</command> daemons at this point, you
+If you restart the &smbd;, &nmbd;, and &winbindd; daemons at this point, you
should be able to connect to the samba server as a domain member just as
if you were a local user.
</para>
</para>
<para>
-<prompt>root#</prompt> <command>make nsswitch/pam_winbind.so</command>
+&rootprompt;<userinput>make nsswitch/pam_winbind.so</userinput>
</para>
<para>
</para>
<para>
-<prompt>root#</prompt> <command>cp ../samba/source/nsswitch/pam_winbind.so /lib/security</command>
+&rootprompt;<userinput>cp ../samba/source/nsswitch/pam_winbind.so /lib/security</userinput>
</para>
<sect4>
have individual directories for the domain users already present on
the server, or change the home directory template to a general
directory for all domain users. These can be easily set using
-the <filename>smb.conf</filename> global entry
-<command>template homedir</command>.
+the &smb.conf; global entry
+<parameter>template homedir</parameter>.
</para>
<para>
</programlisting></para>
<para>
-In this case, I added the <command>auth sufficient /lib/security/pam_winbind.so</command>
-lines as before, but also added the <command>required pam_securetty.so</command>
+In this case, I added the <programlisting>auth sufficient /lib/security/pam_winbind.so</programlisting>
+lines as before, but also added the <programlisting>required pam_securetty.so</programlisting>
above it, to disallow root logins over the network. I also added a
<command>sufficient /lib/security/pam_unix.so use_first_pass</command>
line after the <command>winbind.so</command> line to get rid of annoying
git.samba.org / sfrench / samba-autobuild / .git / commitdiff