sin/samba-mirror
1
0
Fork 0
mirror of https://github.com/samba-team/samba.git synced 2024-12-27 03:21:53 +03:00
Code

More edits, hackety hack.

Browse Source
This commit is contained in:
John Terpstra 0001-01-01 00:00:00 +00:00
parent 7f76eac5a0
commit 044489f218
2 changed files with 298 additions and 32 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

229
docs/docbook/projdoc/DOMAIN_MEMBER.xml
View File

@ -1,9 +1,9 @@
<chapter id="domain-member">
<chapterinfo>
&author.jht;
&author.jeremy;
&author.jerry;
&author.jht;
</chapterinfo>
<title>Domain Membership</title>
@ -40,6 +40,44 @@ Samba-3 can join an MS Windows NT4 style domain as a native member server, an MS
Active Directory Domain as a native member server, or a Samba Domain Control network.
</para>
<para>
Domain membership has many advantages:
</para>
<itemizedlist>
<listitem><para>
MS Windows workstation users get the benefit of SSO
</para></listitem>
<listitem><para>
Domain user access rights and file ownership / access controls can be set from
the single Domain SAM (Security Accounts Management) database (works with Domain member
servers as well as with MS Windows workstations that are domain members)
</para></listitem>
<listitem><para>
Only MS Windows NT4 / 200x / XP Professional workstations that are Domain members
can use network logon facilities
</para></listitem>
<listitem><para>
Domain Member workstations can be better controlled through the use of Policy files
(NTConfig.POL) and Desktop Profiles.
</para></listitem>
<listitem><para>
Through the use of logon scripts users can be given transparent access to network
applications that run off application servers
</para></listitem>
<listitem><para>
Network administrators gain better application and user access management abilities
because there is no need to maintain user accounts on any network client or server,
other than the central Domain database (either NT4/Samba SAM style Domain, NT4 Domain
that is back ended with an LDAP directory, or via an Active Directory infrastructure)
</para></listitem>
</itemizedlist>
</sect1>
<sect1>
@ -64,8 +102,8 @@ shared secret with the domain controller.
</para>
<para>
A Windows NT4 PDC stores each machine trust account in the Windows
Registry. The introduction of MS Windows 2000 saw the introduction of Active Directory,
A Windows NT4 PDC stores each machine trust account in the Windows Registry.
The introduction of MS Windows 2000 saw the introduction of Active Directory,
the new repository for machine trust accounts.
</para>
@ -103,12 +141,19 @@ as follows:
</para>
<para>
There are two ways to create machine trust accounts:
There are three ways to create machine trust accounts:
</para>
<itemizedlist>
<listitem><para>
Manual creation. Both the Samba and corresponding Unix account are created by hand.
Manual creation from the Unix/Linux command line. Here, both the Samba and corresponding
Unix account are created by hand.
</para></listitem>
<listitem><para>
Using the MS Windows NT4 Server Manager (either from an NT4 Domain member server, or using
the Nexus toolkit available from the Microsoft web site. This tool can be run from any
MS Windows machine so long as the user is logged on as the administrator account.
</para></listitem>
<listitem><para>
@ -200,6 +245,56 @@ the corresponding Unix account.
</warning>
</sect2>
<sect2>
<title>Using NT4 Server Manager to Add Machine Accounts to the Domain</title>
<para>
If the machine from which you are trying to manage the domain is an MS Windows NT4 workstation
then the tool of choice is the package called SRVTOOLS.EXE. When executed in the target directory
this will unpack SrvMge.exe and UsrMgr.exe (both are Domain Management tools for MS Windows NT4
workstation.
</para>
<para>
If your workstation is any other MS Windows product you should download the Nexus.exe package
from the Microsoft web site. When executed from the target directory this will unpack the same
tools but for use on MS Windows 9x/Me/200x/XP.
</para>
<para>
Launch the <command>srvmgr.exe</command> (Server Manager for Domains) and follow these steps:
</para>
<procedure>
<title>Server Manager Account Machine Account Management</title>
<step><para>
From the menu select Computer
</para></step>
<step><para>
Click on "Select Domain"
</para></step>
<step><para>
Click on the name of the domain you wish to administer in the "Select Domain" panel
and then Click OK.
</para></step>
<step><para>
Again from the menu select Computer
</para></step>
<step><para>
Select "Add to Domain"
</para></step>
<step><para>
In the dialog box, click on the radio button to "Add NT Workstation of Server", then
enter the machine name in the field provided, then Click the "Add" button.
</para></step>
</procedure>
</sect2>
<sect2>
<title>"On-the-Fly" Creation of Machine Trust Accounts</title>
@ -210,13 +305,11 @@ simply to allow the Samba server to create them as needed when the client
is joined to the domain.
</para>
<para>Since each Samba machine trust account requires a corresponding
Unix account, a method for automatically creating the
Unix account is usually supplied; this requires configuration of the
<ulink url="smb.conf.5.html#ADDMACHINESCRIPT">add machine script</ulink>
option in <filename>smb.conf</filename>. This
method is not required, however; corresponding Unix accounts may also
be created manually.
<para>Since each Samba machine trust account requires a corresponding Unix account, a method
for automatically creating the Unix account is usually supplied; this requires configuration of the
<ulink url="smb.conf.5.html#ADDMACHINESCRIPT">add machine script</ulink> option in
<filename>smb.conf</filename>. This method is not required, however; corresponding Unix
accounts may also be created manually.
</para>
@ -230,25 +323,39 @@ Below is an example for a RedHat Linux system.
add machine script = /usr/sbin/useradd -d /dev/null -g 100 -s /bin/false -M %u
</programlisting></para>
</sect2>
<sect2><title>Joining the Client to the Domain</title>
<sect2><title>Making an MS Windows Workstation or Server a Domain Member</title>
<para>
The procedure for joining a client to the domain varies with the version of Windows.
The procedure for making an MS Windows workstation of server a member of the domain varies
with the version of Windows:
</para>
<itemizedlist>
<listitem><para><emphasis>Windows 2000</emphasis></para>
<listitem><para><emphasis>Windows 200x XP Professional</emphasis></para>
<para>
When the user elects to join the client to a domain, Windows prompts for
an account and password that is privileged to join the domain. A Samba administrative
account (i.e., a Samba account that has root privileges on the Samba server) must be
entered here; the operation will fail if an ordinary user account is given.
The password for this account should be set to a different password than the associated
<filename>/etc/passwd</filename> entry, for security reasons.
When the user elects to make the client a domain member, Windows 200x prompts for
an account and password that has privileges to create machine accounts in the domain.
A Samba administrative account (i.e., a Samba account that has root privileges on the
Samba server) must be entered here; the operation will fail if an ordinary user
account is given.
</para>
<para>
Note: For security reasons the password for this administrative account should be set
to a password that is other than that used for the root user in the
<filename>/etc/passwd</filename>.
</para>
<para>
The name of the account that is used to create domain member machine accounts can be
anything the network administrator may choose. If it is other than <command>root</command>
then this is easily mapped to root using the file pointed to be the &smb.conf; parameter
<emphasis>username map =</emphasis> <command>/etc/samba/smbusers</command>.
</para>
<para>
@ -258,7 +365,7 @@ The procedure for joining a client to the domain varies with the version of Wind
updated if it already exists.
</para></listitem>
<listitem><para><emphasis>Windows NT</emphasis></para>
<listitem><para><emphasis>Windows NT4</emphasis></para>
<para>
If the machine trust account was created manually, on the
@ -700,6 +807,84 @@ w2k doesn't seem to create the _kerberos._udp and _ldap._tcp in
their defaults DNS setup. Maybe fixed in service packs?
</para>
</sect2>
</sect1>
<sect1>
<title>Common Errors</title>
<para>
In the process of adding / deleting / re-adding domain member machine accounts there are
many traps for the unwary player and there are many "little" things that can go wrong.
It is particularly interesting how often subscribers on the samba mailing list have concluded
after repeated failed attempts to add a machine account that it is necessary to "re-install"
MS Windows on t he machine. In truth, it is seldom necessary to reinstall because of this type
of problem. The real solution is often very simple, and with understanding of how MS Windows
networking functions. easily overcome.
</para>
<sect2>
<title>Can Not Add Machine Back to Domain</title>
<para>
<emphasis>Problem:</emphasis> A Windows workstation was reinstalled. The original domain machine
account was deleted and added immediately. The workstation will not join the domain if I use
the same machine name. Attempts to add the machine fail with a message that the machine already
exists on the network - I know it doen't. Why is this failing?
</para>
<para>
The original name is still in the NetBIOS name cache and must expire after machine account
deletion BEFORE adding that same name as a domain member again. The best advice is to delete
the old account and then to add the machine with a new name.
</para>
</sect2>
<sect2>
<title>Adding Machine to Domain Fails</title>
<para>
Adding a Windows 200x or XP Professional machine to the Samba PDC Domain fails with a
message that, "The machine could not be added at this time, there is a network problem.
Please try again later." Why?
</para>
<para>
You should check that there is an <emphasis>add machine script</emphasis> in your &smb.conf;
file. If there is not, please add one that is appropriate for your OS platform. If a script
has been defined you will need to debug it's operation. Increase the <emphasis>log level</emphasis>
in the &smb.conf; file to level 10, then try to rejoin the domain. Check the logs to see which
operation is failing.
</para>
<para>
Possible causes include:
</para>
<itemizedlist>
<listitem><para>
The script does not actually exist, or could not be located in the path specified.
</para>
<para>
<emphasis>Corrective Action:</emphasis> Fix it. Make sure that when run manually
that the script will add both the Unix system account _and_ the Samba SAM account.
</para></listitem>
<listitem><para>
The machine could not be added to the Unix system accounts file <filename>/etc/passwd</filename>
</para>
<para>
<emphasis>Corrective Action:</emphasis> Check that the machine name is a legal Unix
system account name. ie: If the Unix utility <command>useradd</command> is called
then make sure that the machine name you are trying to add can be added using this
tool. <command>Useradd</command> on some systems will not allow any upper case characters
nor will it allow spaces in the name.
</para></listitem>
</itemizedlist>
</sect2>
</sect1>

101
docs/docbook/projdoc/StandAloneServer.xml
View File

@ -4,8 +4,42 @@
</chapterinfo>
<title>Stand-Alone Servers</title>
<para>
Stand-Alone servers are independant of an Domain Controllers on the network.
They are NOT domain members and function more like workgroup servers. In many
cases a stand-alone server is configured with a minimum of security control
with the intent that all data served will be readilly accessible to all users.
</para>
<sect1>
<title>Stand Alone Server</title>
<title>Features and Benefits</title>
<para>
Stand-Alone servers can be as secure or as insecure as needs dictate. They can
have simple or complex configurations. Above all, despite the hoopla about
Domain security they remain a very common installation.
</para>
<para>
If all that is needed is a server for read-only files, or for
printers alone, it may not make sense to affect a complex installation.
For example: A drafting office needs to store old drawings and reference
standards. No-one can write files to the server as it is legislatively
important that all documents remain unaltered. A share mode read-only stand-alone
server is an ideal solution.
</para>
<para>
Another situation that warrants simplicity is an office that has many printers
that are queued off a single central server. Everyone needs to be able to print
to the printers, there is no need to affect any access controls and no files will
be served from the print server. Again a share mode stand-alone server makes
a great solution.
</para>
</sect1>
<sect1>
<title>Background</title>
<para>
The term <emphasis>stand alone server</emphasis> means that the server
@ -13,21 +47,22 @@ will provide local authentication and access control for all resources
that are available from it. In general this means that there will be a
local user database. In more technical terms, it means that resources
on the machine will either be made available in either SHARE mode or in
USER mode. SHARE mode and USER mode security are documented under
discussions regarding "security mode". The smb.conf configuration parameters
that control security mode are: "security = user" and "security = share".
USER mode.
</para>
<para>
No special action is needed other than to create user accounts. Stand-alone
servers do NOT provide network logon services, meaning that machines that
use this server do NOT perform a domain logon but instead make use only of
the MS Windows logon which is local to the MS Windows workstation/server.
servers do NOT provide network logon services. This means that machines that
use this server do NOT perform a domain log onto it. Whatever logon facility
the workstations are subject to is independant of this machine. It is however
necessary to accomodate any network user so that the logon name they use will
be translated (mapped) locally on the stand-alone server to a locally known
user name. There are several ways this cane be done.
</para>
<para>
Samba tends to blur the distinction a little in respect of what is
a stand alone server. This is because the authentication database may be
a stand-alone server. This is because the authentication database may be
local or on a remote server, even if from the samba protocol perspective
the samba server is NOT a member of a domain security context.
</para>
@ -38,10 +73,56 @@ Through the use of PAM (Pluggable Authentication Modules) and nsswitch
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 (/etc/samba/smbpasswd or /usr/local/samba/lib/private/smbpasswd), or
may use an LDAP back end, or even via PAM and Winbind another CIFS/SMB
file, or may use an LDAP back end, or even via PAM and Winbind another CIFS/SMB
server for authentication.
</para>
</sect1>
<sect1>
<title>Example Configuration</title>
<para>
The following examples are designed to inspire simplicity. It is too easy to
attempt a high level of creativity and to introduce too much complexity in
server and network design.
</para>
<sect2>
<title>Reference Documentation Server</title>
<para>
Put one here!
</para>
</sect2>
<sect2>
<title>Central Print Serving</title>
<para>
Put one here!
</para>
</sect2>
<sect2>
<title>Legal Office Daily Work Server</title>
<para>
Put one here!
</para>
</sect2>
</sect1>
<sect1>
<title>Common Errors</title>
<para>
Put stuff here.
</para>
</sect1>
</chapter>