mirror of
https://github.com/samba-team/samba.git
synced 2025-01-13 13:18:06 +03:00
Another set of updates.
This commit is contained in:
John Terpstra
parent
a635b6406a
commit
5fc92d4596
@ -8,186 +8,48 @@
|
||||
|
||||
<title>Domain Membership</title>
|
||||
|
||||
<sect1>
|
||||
<title>Domain Member Server</title>
|
||||
|
||||
<para>
|
||||
This mode of server operation involves the samba machine being made a member
|
||||
of a domain security context. This means by definition that all user authentication
|
||||
will be done from a centrally defined authentication regime. The authentication
|
||||
regime may come from an NT3/4 style (old domain technology) server, or it may be
|
||||
provided from an Active Directory server (ADS) running on MS Windows 2000 or later.
|
||||
Domain Membership is a subject of vital concern, Samba must be able to participate
|
||||
as a member server in a Microsoft Domain security context, and Samba must be capable of
|
||||
providing Domain machine member trust accounts, otherwise it would not be capable of offering
|
||||
a viable option for many users.
|
||||
</para>
|
||||
|
||||
<para><emphasis>
|
||||
Of course it should be clear that the authentication back end itself could be from any
|
||||
distributed directory architecture server that is supported by Samba. This can be
|
||||
LDAP (from OpenLDAP), or Sun's iPlanet, of NetWare Directory Server, etc.
|
||||
</emphasis></para>
|
||||
<para>
|
||||
This chapter covers background information pertaining to domain membership, Samba
|
||||
configuration for it, and MS Windows client procedures for joining a domain. Why is
|
||||
this necessary? Because both are areas in which there exists within the current MS
|
||||
Windows networking world and particularly in the Unix/Linux networking and administration
|
||||
world, a considerable level of mis-information, incorrect understanding, and a lack of
|
||||
knowledge. Hopefully this chapter will fill the voids.
|
||||
</para>
|
||||
|
||||
<sect1>
|
||||
<title>Features and Benefits</title>
|
||||
|
||||
<para>
|
||||
Please refer to the section on Howto configure Samba as a Primary Domain Controller
|
||||
and for more information regarding how to create a domain machine account for a
|
||||
domain member server as well as for information regarding how to enable the samba
|
||||
domain member machine to join the domain and to be fully trusted by it.
|
||||
MS Windows workstations and servers that want to participate in domain security need to
|
||||
be made Domain members. Participating in Domain security is often called
|
||||
<emphasis>Single Sign On</emphasis> or SSO for short. This chapter describes the process
|
||||
that must be followed to make a workstation (or another server - be it an MS Windows NT4 / 200x
|
||||
server) or a Samba server a member of an MS Windows Domain security context.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Samba-3 can join an MS Windows NT4 style domain as a native member server, an MS Windows
|
||||
Active Directory Domain as a native member server, or a Samba Domain Control network.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Joining an NT4 type Domain with Samba-3</title>
|
||||
<para><emphasis>Assumptions:</emphasis>
|
||||
<programlisting>
|
||||
NetBIOS name: SERV1
|
||||
Win2K/NT domain name: DOM
|
||||
Domain's PDC NetBIOS name: DOMPDC
|
||||
Domain's BDC NetBIOS names: DOMBDC1 and DOMBDC2
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<para>First, you must edit your &smb.conf; file to tell Samba it should
|
||||
now use domain security.</para>
|
||||
|
||||
<para>Change (or add) your <ulink url="smb.conf.5.html#SECURITY">
|
||||
<parameter>security =</parameter></ulink> line in the [global] section
|
||||
of your &smb.conf; to read:</para>
|
||||
|
||||
<para><command>security = domain</command></para>
|
||||
|
||||
<para>Next change the <ulink url="smb.conf.5.html#WORKGROUP"><parameter>
|
||||
workgroup =</parameter></ulink> line in the [global] section to read: </para>
|
||||
|
||||
<para><command>workgroup = DOM</command></para>
|
||||
|
||||
<para>as this is the name of the domain we are joining. </para>
|
||||
|
||||
<para>You must also have the parameter <ulink url="smb.conf.5.html#ENCRYPTPASSWORDS">
|
||||
<parameter>encrypt passwords</parameter></ulink> set to <constant>yes
|
||||
</constant> in order for your users to authenticate to the NT PDC.</para>
|
||||
|
||||
<para>Finally, add (or modify) a <ulink url="smb.conf.5.html#PASSWORDSERVER">
|
||||
<parameter>password server =</parameter></ulink> line in the [global]
|
||||
section to read: </para>
|
||||
|
||||
<para><command>password server = DOMPDC DOMBDC1 DOMBDC2</command></para>
|
||||
|
||||
<para>These are the primary and backup domain controllers Samba
|
||||
will attempt to contact in order to authenticate users. Samba will
|
||||
try to contact each of these servers in order, so you may want to
|
||||
rearrange this list in order to spread out the authentication load
|
||||
among domain controllers.</para>
|
||||
|
||||
<para>Alternatively, if you want smbd to automatically determine
|
||||
the list of Domain controllers to use for authentication, you may
|
||||
set this line to be :</para>
|
||||
|
||||
<para><command>password server = *</command></para>
|
||||
|
||||
<para>This method, allows Samba to use exactly the same
|
||||
mechanism that NT does. This
|
||||
method either broadcasts or uses a WINS database in order to
|
||||
find domain controllers to authenticate against.</para>
|
||||
|
||||
<para>In order to actually join the domain, you must run this
|
||||
command:</para>
|
||||
|
||||
<para><prompt>root# </prompt><userinput>net join -S DOMPDC
|
||||
-U<replaceable>Administrator%password</replaceable></userinput></para>
|
||||
|
||||
<para>
|
||||
If the <userinput>-S DOMPDC</userinput> argument is not given then
|
||||
the domain name will be obtained from smb.conf.
|
||||
</para>
|
||||
|
||||
<para>as we are joining the domain DOM and the PDC for that domain
|
||||
(the only machine that has write access to the domain SAM database)
|
||||
is DOMPDC. The <replaceable>Administrator%password</replaceable> is
|
||||
the login name and password for an account which has the necessary
|
||||
privilege to add machines to the domain. If this is successful
|
||||
you will see the message:</para>
|
||||
|
||||
<para><computeroutput>Joined domain DOM.</computeroutput>
|
||||
or <computeroutput>Joined 'SERV1' to realm 'MYREALM'</computeroutput>
|
||||
</para>
|
||||
|
||||
<para>in your terminal window. See the <ulink url="net.8.html">
|
||||
net(8)</ulink> man page for more details.</para>
|
||||
|
||||
<para>This process joins the server to the domain
|
||||
without having to create the machine trust account on the PDC
|
||||
beforehand.</para>
|
||||
|
||||
<para>This command goes through the machine account password
|
||||
change protocol, then writes the new (random) machine account
|
||||
password for this Samba server into a file in the same directory
|
||||
in which an smbpasswd file would be stored - normally :</para>
|
||||
|
||||
<para><filename>/usr/local/samba/private/secrets.tdb</filename></para>
|
||||
|
||||
<para>This file is created and owned by root and is not
|
||||
readable by any other user. It is the key to the domain-level
|
||||
security for your system, and should be treated as carefully
|
||||
as a shadow password file.</para>
|
||||
|
||||
<para>Finally, restart your Samba daemons and get ready for
|
||||
clients to begin using domain security!</para>
|
||||
|
||||
<sect2>
|
||||
<title>Why is this better than security = server?</title>
|
||||
|
||||
<para>Currently, domain security in Samba doesn't free you from
|
||||
having to create local Unix users to represent the users attaching
|
||||
to your server. This means that if domain user <constant>DOM\fred
|
||||
</constant> attaches to your domain security Samba server, there needs
|
||||
to be a local Unix user fred to represent that user in the Unix
|
||||
filesystem. This is very similar to the older Samba security mode
|
||||
<ulink url="smb.conf.5.html#SECURITYEQUALSSERVER">security = server</ulink>,
|
||||
where Samba would pass through the authentication request to a Windows
|
||||
NT server in the same way as a Windows 95 or Windows 98 server would.
|
||||
</para>
|
||||
|
||||
<para>Please refer to the <ulink url="winbind.html">Winbind
|
||||
paper</ulink> for information on a system to automatically
|
||||
assign UNIX uids and gids to Windows NT Domain users and groups.
|
||||
</para>
|
||||
|
||||
<para>The advantage to domain-level security is that the
|
||||
authentication in domain-level security is passed down the authenticated
|
||||
RPC channel in exactly the same way that an NT server would do it. This
|
||||
means Samba servers now participate in domain trust relationships in
|
||||
exactly the same way NT servers do (i.e., you can add Samba servers into
|
||||
a resource domain and have the authentication passed on from a resource
|
||||
domain PDC to an account domain PDC).</para>
|
||||
|
||||
<para>In addition, with <command>security = server</command> every Samba
|
||||
daemon on a server has to keep a connection open to the
|
||||
authenticating server for as long as that daemon lasts. This can drain
|
||||
the connection resources on a Microsoft NT server and cause it to run
|
||||
out of available connections. With <command>security = domain</command>,
|
||||
however, the Samba daemons connect to the PDC/BDC only for as long
|
||||
as is necessary to authenticate the user, and then drop the connection,
|
||||
thus conserving PDC connection resources.</para>
|
||||
|
||||
<para>And finally, acting in the same manner as an NT server
|
||||
authenticating to a PDC means that as part of the authentication
|
||||
reply, the Samba server gets the user identification information such
|
||||
as the user SID, the list of NT groups the user belongs to, etc. </para>
|
||||
|
||||
<note><para> Much of the text of this document
|
||||
was first published in the Web magazine <ulink url="http://www.linuxworld.com">
|
||||
LinuxWorld</ulink> as the article <ulink
|
||||
url="http://www.linuxworld.com/linuxworld/lw-1998-10/lw-10-samba.html">Doing
|
||||
the NIS/NT Samba</ulink>.</para></note>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Machine Trust Accounts and Domain Membership</title>
|
||||
<title>MS Windows Workstation/Server Machine Trust Accounts</title>
|
||||
|
||||
<para>
|
||||
A machine trust account is an account that is used to authenticate a client machine
|
||||
(rather than a user) to the Domain Controller server. In Windows terminology,
|
||||
this is known as a "Computer Account."</para>
|
||||
this is known as a "Computer Account."
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The password of a machine trust account acts as the shared secret for
|
||||
@ -201,7 +63,8 @@ because it does not possess a machine trust account, and thus has no
|
||||
shared secret with the domain controller.
|
||||
</para>
|
||||
|
||||
<para>A Windows NT4 PDC stores each machine trust account in the Windows
|
||||
<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,
|
||||
the new repository for machine trust accounts.
|
||||
</para>
|
||||
@ -211,13 +74,31 @@ A Samba PDC, however, stores each machine trust account in two parts,
|
||||
as follows:
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para>A Samba account, stored in the same location as user
|
||||
LanMan and NT password hashes (currently <filename>smbpasswd</filename>).
|
||||
The Samba account possesses and uses only the NT password hash.</para></listitem>
|
||||
<listitem><para>
|
||||
A Domain Security Account (stored in the <emphasis>passdb backend</emphasis>
|
||||
that has been configured in the &smb.conf; file. The precise nature of the
|
||||
account information that is stored depends on the type of backend database
|
||||
that has been chosen.
|
||||
</para>
|
||||
|
||||
<listitem><para>A corresponding Unix account, typically stored in
|
||||
<filename>/etc/passwd</filename>. (Future releases will alleviate the need to
|
||||
create <filename>/etc/passwd</filename> entries.) </para></listitem>
|
||||
<para>
|
||||
The older format of this data is the <filename>smbpasswd</filename> database
|
||||
which contains the unix login ID, the Unix user identifier (UID), and the
|
||||
LanMan and NT encrypted passwords. There is also some other information in
|
||||
this file that we do not need to concern ourselves with here.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The two newer database types are called <emphasis>ldapsam, tdbsam</emphasis>.
|
||||
Both store considerably more data than the older <filename>smbpasswd</filename>
|
||||
file did. The extra information enables new user account controls to be used.
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>
|
||||
A corresponding Unix account, typically stored in <filename>/etc/passwd</filename>.
|
||||
Work is in progress to allow a simplified mode of operation that does not require
|
||||
Unix user accounts, but this may not be a feature of the early releases of Samba-3.
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
||||
@ -226,39 +107,38 @@ There are two ways to create machine trust accounts:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para> Manual creation. Both the Samba and corresponding
|
||||
Unix account are created by hand.</para></listitem>
|
||||
<listitem><para>
|
||||
Manual creation. Both the Samba and corresponding Unix account are created by hand.
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para> "On-the-fly" creation. The Samba machine trust
|
||||
account is automatically created by Samba at the time the client
|
||||
is joined to the domain. (For security, this is the
|
||||
recommended method.) The corresponding Unix account may be
|
||||
created automatically or manually. </para>
|
||||
</listitem>
|
||||
|
||||
<listitem><para>
|
||||
"On-the-fly" creation. The Samba machine trust account is automatically created by
|
||||
Samba at the time the client is joined to the domain. (For security, this is the
|
||||
recommended method.) The corresponding Unix account may be created automatically or manually.
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<sect2>
|
||||
<title>Manual Creation of Machine Trust Accounts</title>
|
||||
|
||||
<para>
|
||||
The first step in manually creating a machine trust account is to
|
||||
manually create the corresponding Unix account in
|
||||
<filename>/etc/passwd</filename>. This can be done using
|
||||
<command>vipw</command> or other 'add user' command that is normally
|
||||
used to create new Unix accounts. The following is an example for a
|
||||
Linux based Samba server:
|
||||
The first step in manually creating a machine trust account is to manually create the
|
||||
corresponding Unix account in <filename>/etc/passwd</filename>. This can be done using
|
||||
<command>vipw</command> or other 'add user' command that is normally used to create new
|
||||
Unix accounts. The following is an example for a Linux based Samba server:
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<prompt>root# </prompt><command>/usr/sbin/useradd -g 100 -d /dev/null -c <replaceable>"machine
|
||||
nickname"</replaceable> -s /bin/false <replaceable>machine_name</replaceable>$ </command>
|
||||
<prompt>root# </prompt><command>/usr/sbin/useradd -g 100 -d /dev/null -c <replaceable>"machine nickname"</replaceable> -s /bin/false <replaceable>machine_name</replaceable>$ </command>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<prompt>root# </prompt><command>passwd -l <replaceable>machine_name</replaceable>$</command>
|
||||
</para>
|
||||
|
||||
<para>On *BSD systems, this can be done using the 'chpass' utility:</para>
|
||||
<para>
|
||||
On *BSD systems, this can be done using the 'chpass' utility:
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<prompt>root# </prompt><command>chpass -a "<replaceable>machine_name</replaceable>$:*:101:100::0:0:Workstation <replaceable>machine_name</replaceable>:/dev/null:/sbin/nologin"</command>
|
||||
@ -271,9 +151,9 @@ home directory. For example a machine named 'doppy' would have an
|
||||
<filename>/etc/passwd</filename> entry like this:
|
||||
</para>
|
||||
|
||||
<para><programlisting>
|
||||
<para>
|
||||
doppy$:x:505:501:<replaceable>machine_nickname</replaceable>:/dev/null:/bin/false
|
||||
</programlisting></para>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Above, <replaceable>machine_nickname</replaceable> can be any
|
||||
@ -293,7 +173,9 @@ as shown here:
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<programlisting>
|
||||
<prompt>root# </prompt><userinput>smbpasswd -a -m <replaceable>machine_name</replaceable></userinput>
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -325,7 +207,8 @@ the corresponding Unix account.
|
||||
<para>
|
||||
The second (and recommended) way of creating machine trust accounts is
|
||||
simply to allow the Samba server to create them as needed when the client
|
||||
is joined to the domain. </para>
|
||||
is joined to the domain.
|
||||
</para>
|
||||
|
||||
<para>Since each Samba machine trust account requires a corresponding
|
||||
Unix account, a method for automatically creating the
|
||||
@ -357,7 +240,7 @@ The procedure for joining a client to the domain varies with the version of Wind
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis>Windows 2000</emphasis></para>
|
||||
<listitem><para><emphasis>Windows 2000</emphasis></para>
|
||||
|
||||
<para>
|
||||
When the user elects to join the client to a domain, Windows prompts for
|
||||
@ -373,35 +256,277 @@ The procedure for joining a client to the domain varies with the version of Wind
|
||||
encryption key for setting the password of the machine trust
|
||||
account. The machine trust account will be created on-the-fly, or
|
||||
updated if it already exists.
|
||||
</para>
|
||||
</para></listitem>
|
||||
|
||||
</listitem>
|
||||
<listitem><para><emphasis>Windows NT</emphasis></para>
|
||||
|
||||
<listitem><para><emphasis>Windows NT</emphasis></para>
|
||||
|
||||
<para> If the machine trust account was created manually, on the
|
||||
<para>
|
||||
If the machine trust account was created manually, on the
|
||||
Identification Changes menu enter the domain name, but do not
|
||||
check the box "Create a Computer Account in the Domain." In this case,
|
||||
the existing machine trust account is used to join the machine to
|
||||
the domain.</para>
|
||||
the domain.
|
||||
</para>
|
||||
|
||||
<para> If the machine trust account is to be created
|
||||
<para>
|
||||
If the machine trust account is to be created
|
||||
on-the-fly, on the Identification Changes menu enter the domain
|
||||
name, and check the box "Create a Computer Account in the Domain." In
|
||||
this case, joining the domain proceeds as above for Windows 2000
|
||||
(i.e., you must supply a Samba administrative account when
|
||||
prompted).</para>
|
||||
</listitem>
|
||||
prompted).
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para><emphasis>Samba</emphasis></para>
|
||||
<listitem><para><emphasis>Samba</emphasis></para>
|
||||
<para>Joining a samba client to a domain is documented in
|
||||
the <link linkend="domain-member">Domain Member</link> chapter.
|
||||
</para></listitem>
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Domain Member Server</title>
|
||||
|
||||
<para>
|
||||
This mode of server operation involves the samba machine being made a member
|
||||
of a domain security context. This means by definition that all user authentication
|
||||
will be done from a centrally defined authentication regime. The authentication
|
||||
regime may come from an NT3/4 style (old domain technology) server, or it may be
|
||||
provided from an Active Directory server (ADS) running on MS Windows 2000 or later.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<emphasis>
|
||||
Of course it should be clear that the authentication back end itself could be from any
|
||||
distributed directory architecture server that is supported by Samba. This can be
|
||||
LDAP (from OpenLDAP), or Sun's iPlanet, of NetWare Directory Server, etc.
|
||||
</emphasis>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Please refer to the section on Howto configure Samba as a Primary Domain Controller
|
||||
and for more information regarding how to create a domain machine account for a
|
||||
domain member server as well as for information regarding how to enable the samba
|
||||
domain member machine to join the domain and to be fully trusted by it.
|
||||
</para>
|
||||
|
||||
<sect2>
|
||||
<title>Joining an NT4 type Domain with Samba-3</title>
|
||||
|
||||
<para>
|
||||
<emphasis>Assumptions:</emphasis>
|
||||
<programlisting>
|
||||
NetBIOS name: SERV1
|
||||
Win2K/NT domain name: DOM
|
||||
Domain's PDC NetBIOS name: DOMPDC
|
||||
Domain's BDC NetBIOS names: DOMBDC1 and DOMBDC2
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
First, you must edit your &smb.conf; file to tell Samba it should
|
||||
now use domain security.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Change (or add) your <ulink url="smb.conf.5.html#SECURITY">
|
||||
<parameter>security =</parameter></ulink> line in the [global] section
|
||||
of your &smb.conf; to read:
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<programlisting>
|
||||
<command>security = domain</command>
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Next change the <ulink url="smb.conf.5.html#WORKGROUP"><parameter>
|
||||
workgroup =</parameter></ulink> line in the [global] section to read:
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<programlisting>
|
||||
<command>workgroup = DOM</command>
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
as this is the name of the domain we are joining.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You must also have the parameter <ulink url="smb.conf.5.html#ENCRYPTPASSWORDS">
|
||||
<parameter>encrypt passwords</parameter></ulink> set to <constant>yes
|
||||
</constant> in order for your users to authenticate to the NT PDC.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Finally, add (or modify) a <ulink url="smb.conf.5.html#PASSWORDSERVER">
|
||||
<parameter>password server =</parameter></ulink> line in the [global]
|
||||
section to read:
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<programlisting>
|
||||
<command>password server = DOMPDC DOMBDC1 DOMBDC2</command>
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
These are the primary and backup domain controllers Samba
|
||||
will attempt to contact in order to authenticate users. Samba will
|
||||
try to contact each of these servers in order, so you may want to
|
||||
rearrange this list in order to spread out the authentication load
|
||||
among domain controllers.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Alternatively, if you want smbd to automatically determine
|
||||
the list of Domain controllers to use for authentication, you may
|
||||
set this line to be:
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<programlisting>
|
||||
<command>password server = *</command>
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This method, allows Samba to use exactly the same mechanism that NT does. This
|
||||
method either broadcasts or uses a WINS database in order to
|
||||
find domain controllers to authenticate against.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In order to actually join the domain, you must run this command:
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<programlisting>
|
||||
<prompt>root# </prompt><userinput>net join -S DOMPDC -U<replaceable>Administrator%password</replaceable></userinput>
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If the <userinput>-S DOMPDC</userinput> argument is not given then
|
||||
the domain name will be obtained from smb.conf.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
As we are joining the domain DOM and the PDC for that domain
|
||||
(the only machine that has write access to the domain SAM database)
|
||||
is DOMPDC. The <replaceable>Administrator%password</replaceable> is
|
||||
the login name and password for an account which has the necessary
|
||||
privilege to add machines to the domain. If this is successful
|
||||
you will see the message:
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<computeroutput>Joined domain DOM.</computeroutput>
|
||||
or <computeroutput>Joined 'SERV1' to realm 'MYREALM'</computeroutput>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
in your terminal window. See the <ulink url="net.8.html">
|
||||
net(8)</ulink> man page for more details.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This process joins the server to the domain without having to create the machine
|
||||
trust account on the PDC beforehand.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This command goes through the machine account password
|
||||
change protocol, then writes the new (random) machine account
|
||||
password for this Samba server into a file in the same directory
|
||||
in which an smbpasswd file would be stored - normally :
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<filename>/usr/local/samba/private/secrets.tdb</filename>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This file is created and owned by root and is not
|
||||
readable by any other user. It is the key to the domain-level
|
||||
security for your system, and should be treated as carefully
|
||||
as a shadow password file.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Finally, restart your Samba daemons and get ready for
|
||||
clients to begin using domain security!
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Why is this better than security = server?</title>
|
||||
|
||||
<para>
|
||||
Currently, domain security in Samba doesn't free you from
|
||||
having to create local Unix users to represent the users attaching
|
||||
to your server. This means that if domain user <constant>DOM\fred
|
||||
</constant> attaches to your domain security Samba server, there needs
|
||||
to be a local Unix user fred to represent that user in the Unix
|
||||
filesystem. This is very similar to the older Samba security mode
|
||||
<ulink url="smb.conf.5.html#SECURITYEQUALSSERVER">security = server</ulink>,
|
||||
where Samba would pass through the authentication request to a Windows
|
||||
NT server in the same way as a Windows 95 or Windows 98 server would.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Please refer to the <ulink url="winbind.html">Winbind
|
||||
paper</ulink> for information on a system to automatically
|
||||
assign UNIX uids and gids to Windows NT Domain users and groups.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The advantage to domain-level security is that the
|
||||
authentication in domain-level security is passed down the authenticated
|
||||
RPC channel in exactly the same way that an NT server would do it. This
|
||||
means Samba servers now participate in domain trust relationships in
|
||||
exactly the same way NT servers do (i.e., you can add Samba servers into
|
||||
a resource domain and have the authentication passed on from a resource
|
||||
domain PDC to an account domain PDC).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In addition, with <command>security = server</command> every Samba
|
||||
daemon on a server has to keep a connection open to the
|
||||
authenticating server for as long as that daemon lasts. This can drain
|
||||
the connection resources on a Microsoft NT server and cause it to run
|
||||
out of available connections. With <command>security = domain</command>,
|
||||
however, the Samba daemons connect to the PDC/BDC only for as long
|
||||
as is necessary to authenticate the user, and then drop the connection,
|
||||
thus conserving PDC connection resources.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
And finally, acting in the same manner as an NT server
|
||||
authenticating to a PDC means that as part of the authentication
|
||||
reply, the Samba server gets the user identification information such
|
||||
as the user SID, the list of NT groups the user belongs to, etc.
|
||||
</para>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
Much of the text of this document
|
||||
was first published in the Web magazine <ulink url="http://www.linuxworld.com">
|
||||
LinuxWorld</ulink> as the article <ulink
|
||||
url="http://www.linuxworld.com/linuxworld/lw-1998-10/lw-10-samba.html">Doing
|
||||
the NIS/NT Samba</ulink>.
|
||||
</para>
|
||||
</note>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Samba ADS Domain Membership</title>
|
||||
|
||||
@ -413,7 +538,9 @@ Windows2000 KDC.
|
||||
<sect2>
|
||||
<title>Setup your <filename>smb.conf</filename></title>
|
||||
|
||||
<para>You must use at least the following 3 options in smb.conf:</para>
|
||||
<para>
|
||||
You must use at least the following 3 options in smb.conf:
|
||||
</para>
|
||||
|
||||
<para><programlisting>
|
||||
realm = your.kerberos.REALM
|
||||
@ -429,21 +556,25 @@ In case samba can't figure out your ads server using your realm name, use the
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<note><para>You do *not* need a smbpasswd file, and older clients will
|
||||
be authenticated as if <command>security = domain</command>,
|
||||
although it won't do any harm
|
||||
and allows you to have local users not in the domain.
|
||||
I expect that the above required options will change soon when we get better
|
||||
active directory integration.</para></note>
|
||||
<note><para>
|
||||
You do *not* need a smbpasswd file, and older clients will be authenticated as if
|
||||
<command>security = domain</command>, although it won't do any harm and allows you
|
||||
to have local users not in the domain. I expect that the above required options will
|
||||
change soon when we get better active directory integration.
|
||||
</para></note>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Setup your <filename>/etc/krb5.conf</filename></title>
|
||||
|
||||
<para>Note: you will need the krb5 workstation, devel, and libs installed</para>
|
||||
<para>
|
||||
Note: you will need the krb5 workstation, devel, and libs installed
|
||||
</para>
|
||||
|
||||
<para>The minimal configuration for <filename>krb5.conf</filename> is:</para>
|
||||
<para>
|
||||
The minimal configuration for <filename>krb5.conf</filename> is:
|
||||
</para>
|
||||
|
||||
<para><programlisting>
|
||||
[realms]
|
||||
@ -452,17 +583,22 @@ In case samba can't figure out your ads server using your realm name, use the
|
||||
}
|
||||
</programlisting></para>
|
||||
|
||||
<para>Test your config by doing a <userinput>kinit
|
||||
<para>
|
||||
Test your config by doing a <userinput>kinit
|
||||
<replaceable>USERNAME</replaceable>@<replaceable>REALM</replaceable></userinput> and
|
||||
making sure that your password is accepted by the Win2000 KDC.
|
||||
</para>
|
||||
|
||||
<note><para>The realm must be uppercase or you will get "Cannot find KDC for requested
|
||||
realm while getting initial credentials" error </para></note>
|
||||
<note><para>
|
||||
The realm must be uppercase or you will get "Cannot find KDC for requested
|
||||
realm while getting initial credentials" error
|
||||
</para></note>
|
||||
|
||||
<note><para>Time between the two servers must be synchronized. You will get a
|
||||
<note><para>
|
||||
Time between the two servers must be synchronized. You will get a
|
||||
"kinit(v5): Clock skew too great while getting initial credentials" if the time
|
||||
difference is more than five minutes. </para></note>
|
||||
difference is more than five minutes.
|
||||
</para></note>
|
||||
|
||||
<para>
|
||||
You also must ensure that you can do a reverse DNS lookup on the IP
|
||||
@ -554,11 +690,16 @@ specify the <parameter>-k</parameter> option to choose kerberos authentication.
|
||||
<sect2>
|
||||
<title>Notes</title>
|
||||
|
||||
<para>You must change administrator password at least once after DC
|
||||
install, to create the right encoding types</para>
|
||||
<para>
|
||||
You must change administrator password at least once after DC
|
||||
install, to create the right encoding types
|
||||
</para>
|
||||
|
||||
<para>
|
||||
w2k doesn't seem to create the _kerberos._udp and _ldap._tcp in
|
||||
their defaults DNS setup. Maybe fixed in service packs?
|
||||
</para>
|
||||
|
||||
<para>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>
|
||||
|
||||
@ -1283,6 +1283,32 @@ If either router R1 or R2 fails the following will occur:
|
||||
</orderedlist>
|
||||
</sect3>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Common Errors</title>
|
||||
|
||||
<para>
|
||||
Many questions are sked on the mailing lists regarding browsing. The majority of browsing
|
||||
problems originate out of incorrect configuration of NetBIOS name resolution. Some are of
|
||||
particular note.
|
||||
</para>
|
||||
|
||||
<sect2>
|
||||
<title>How can one flush the Samba NetBIOS name cache without restarting samba?</title>
|
||||
|
||||
<para>
|
||||
Sambas' nmbd process controls all browse list handling. Under normal circumstances it is
|
||||
safe to restart nmbd. This will effectively flush the samba NetBIOS name cache and cause it
|
||||
to be rebuilt. Note that this does NOT make certain that a rogue machine name will not re-appear
|
||||
in the browse list. When nmbd is taken out of service another machine on the network will
|
||||
become the browse master. This new list may still have the rogue entry in it. If you really
|
||||
want to clear a rogue machine from the list then every machine on the network will need to be
|
||||
shut down and restarted at after all machines are down. Failing a complete restart, the only
|
||||
other thing you can do is wait until the entry times out and is then flushed from the list.
|
||||
This may take a long time on some networks (months).
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
@ -1123,4 +1123,55 @@ In which case, the local cache copy will be deleted on logout.
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Common Errors</title>
|
||||
|
||||
<para>
|
||||
THe following are some typical errors/problems/questions that have been asked.
|
||||
</para>
|
||||
|
||||
<sect2>
|
||||
<title>How does one set up roaming profiles for just one (or a few) user/s or group/s?</title>
|
||||
|
||||
<para>
|
||||
With samba-2.2.x the choice you have is to enable or disable roaming
|
||||
profiles support. It is a global only setting. The default is to have
|
||||
roaming profiles and the default path will locate them in the user's home
|
||||
directory.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If disabled globally then no-one will have roaming profile ability.
|
||||
If enabled and you want it to apply only to certain machines, then on
|
||||
those machines on which roaming profile support is NOT wanted it is then
|
||||
necessary to disable roaming profile handling in the registry of each such
|
||||
machine.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
With samba-3.0.0 (soon to be released) you can have a global profile
|
||||
setting in smb.conf _AND_ you can over-ride this by per-user settings
|
||||
using the Domain User Manager (as with MS Windows NT4/ Win 2Kx).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In any case, you can configure only one profile per user. That profile can
|
||||
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>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
</chapter>
|
||||
|
||||
@ -17,9 +17,50 @@ with configuring a Samba Domain Controller as described in the
|
||||
<title>Features And Benefits</title>
|
||||
|
||||
<para>
|
||||
Stuff goees here
|
||||
This is one of the most difficult chapters to summarise. It matters not what we say here
|
||||
for someone will still draw conclusions and / or approach the Samba-Team with expectations
|
||||
that are either not yet capable of being delivered, or that can be achieved for more
|
||||
effectively using a totally different approach. Since this HOWTO is already so large and
|
||||
extensive, we have taken the decision to provide sufficient (but not comprehensive)
|
||||
information regarding Backup Domain Control. In the event that you should have a persistent
|
||||
concern that is not addressed in this HOWTO document then please email
|
||||
<ulink url="mailto:jht@samba.org">John H Terpstra</ulink> clearly setting out your requirements
|
||||
and / or question and we will do our best to provide a solution.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Samba-3 is capable of acting as a Backup Domain Controller to another Samba Primary Domain
|
||||
Controller. A Samba-3 PDC can operate with an LDAP Account backend. The Samba-3 BDC can
|
||||
operate with a slave LDAP server for the Account backend. This effectively gives samba a high
|
||||
degree of scalability. This is a very sweet (nice) solution for large organisations.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
While it is possible to run a Samba-3 BDC with non-LDAP backend, the administrator will
|
||||
need to figure out precisely what is the best way to replicate (copy / distribute) the
|
||||
user and machine Accounts backend. Again, Samba-3 provides a number of possibilities:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<title>Backup Domain Backend Account Distribution Options</title>
|
||||
<listitem><para>
|
||||
Passwd Backend is LDAP based, BDCs use a slave LDAP server
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>
|
||||
Passdb Backend is tdbsam based, BDCs use cron based "net rcp vampire" to
|
||||
suck down the Accounts database from the PDC
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>
|
||||
Make use of rsync to replicate (pull down) copies of the essential account files
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>
|
||||
Operate with an entirely local accounts database (not recommended)
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
@ -202,29 +243,6 @@ mutually authenticate and the password change is done.
|
||||
</sect1>
|
||||
|
||||
|
||||
<sect1>
|
||||
<title>Can Samba be a Backup Domain Controller to an NT4 PDC?</title>
|
||||
|
||||
<para>
|
||||
With version 2.2, no. The native NT4 SAM replication protocols have not yet been fully
|
||||
implemented. The Samba Team is working on understanding and implementing the protocols,
|
||||
but this work has not been finished for version 2.2.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
With version 3.0, the work on both the replication protocols and a suitable storage
|
||||
mechanism has progressed, and some form of NT4 BDC support is expected soon.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Can I get the benefits of a BDC with Samba? Yes. The main reason for implementing a
|
||||
BDC is availability. If the PDC is a Samba machine, a second Samba machine can be set up to
|
||||
service logon requests whenever the PDC is down.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
|
||||
<sect1>
|
||||
<title>Backup Domain Controller Configuration</title>
|
||||
|
||||
@ -273,11 +291,15 @@ Several things have to be done:
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
<sect2>
|
||||
<title>Example Configuration</title>
|
||||
|
||||
<para>
|
||||
Finally, the BDC has to be found by the workstations. This can be done by setting:
|
||||
</para>
|
||||
|
||||
<para><programlisting>
|
||||
<title>Essential Parameters for BDC Operation</title>
|
||||
workgroup = SAMBA
|
||||
domain master = no
|
||||
domain logons = yes
|
||||
@ -285,13 +307,58 @@ Finally, the BDC has to be found by the workstations. This can be done by settin
|
||||
|
||||
<para>
|
||||
in the [global]-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
|
||||
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 =
|
||||
no' forces the BDC not to register SAMBA#1b which as a unique NetBIOS
|
||||
no' forces the BDC not to register SAMBA<#1b> which as a unique NetBIOS
|
||||
name is reserved for the Primary Domain Controller.
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Common Errors</title>
|
||||
|
||||
<para>
|
||||
As this is a rather new area for Samba there are not many examples thta we may refer to. Keep
|
||||
watching for updates to this section.
|
||||
</para>
|
||||
|
||||
<sect2>
|
||||
<title>Machine Accounts keep expiring, what can I do?</title>
|
||||
|
||||
<para>
|
||||
This problem will occur when occur when the account files are replicated from a central
|
||||
server but the local Domain Controllers are not forwarding machine account password updates
|
||||
back to the central server, or where there is an excessive delay in replication of the centrally
|
||||
changed machine account password to the local Domain Controller.
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Can Samba be a Backup Domain Controller to an NT4 PDC?</title>
|
||||
|
||||
<para>
|
||||
With version 2.2, no. The native NT4 SAM replication protocols have not yet been fully
|
||||
implemented. The Samba Team is working on understanding and implementing the protocols,
|
||||
but this work has not been finished for version 2.2.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
With version 3.0, the work on both the replication protocols and a suitable storage
|
||||
mechanism has progressed, and some form of NT4 BDC support is expected soon.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Can I get the benefits of a BDC with Samba? Yes. The main reason for implementing a
|
||||
BDC is availability. If the PDC is a Samba machine, a second Samba machine can be set up to
|
||||
service logon requests whenever the PDC is down.
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>How do I replicate the smbpasswd file?</title>
|
||||
|
||||
@ -309,7 +376,6 @@ Ssh itself can be set up to accept *only* rsync transfer without requiring the u
|
||||
to type a password.
|
||||
</para>
|
||||
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
@ -321,16 +387,7 @@ LDAP server, and will also follow referrals and rebind to the master if it ever
|
||||
needs to make a modification to the database. (Normally BDCs are read only, so
|
||||
this will not occur often).
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Common Errors</title>
|
||||
|
||||
<para>
|
||||
Stuff goes here
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
@ -68,6 +68,24 @@ to not inflict pain on others. Do your learning on a test network.
|
||||
<sect1>
|
||||
<title>Features and Benefits</title>
|
||||
|
||||
<para>
|
||||
<emphasis>What is the key benefit of Microsoft Domain security?</emphasis>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In a word, <emphasis>Single Sign On</emphasis>, or SSO for short. This to many is the holy
|
||||
grail of MS Windows NT and beyond networking. SSO allows users in a well designed network
|
||||
to log onto any workstation that is a member of the domain that their user account is in
|
||||
(or in a domain that has an appropriate trust relationship with the domain they are visiting)
|
||||
and they will be able to log onto the network and access resources (shares, files, and printers)
|
||||
as if they are sitting at their home (personal) workstation. This is a feature of the Domain
|
||||
security protocols.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The benefits of Domain security are fully available to those sites that deploy a Samba PDC.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The following functionalities are new to the Samba-3 release:
|
||||
</para>
|
||||
|
||||
@ -13,7 +13,8 @@
|
||||
<sect1>
|
||||
<title>Obtaining and installing samba</title>
|
||||
|
||||
<para>Binary packages of samba are included in almost any Linux or
|
||||
<para>
|
||||
Binary packages of samba are included in almost any Linux or
|
||||
Unix distribution. There are also some packages available at
|
||||
<ulink url="http://samba.org/">the samba homepage</ulink>.
|
||||
</para>
|
||||
@ -29,67 +30,80 @@
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Configuring samba</title>
|
||||
<title>Configuring samba (smb.conf)</title>
|
||||
|
||||
<para>Samba's configuration is stored in the smb.conf file,
|
||||
<para>
|
||||
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
|
||||
tools that are available, such as the web-based interface swat, that
|
||||
is included with samba.</para>
|
||||
is included with samba.
|
||||
</para>
|
||||
|
||||
<sect2>
|
||||
<title>Editing the <filename>smb.conf</filename> file</title>
|
||||
<title>Example Configuration</title>
|
||||
|
||||
<para>There are sample configuration files in the examples
|
||||
subdirectory in the distribution. I suggest you read them
|
||||
carefully so you can see how the options go together in
|
||||
practice. See the man page for all the options.</para>
|
||||
<para>
|
||||
There are sample configuration files in the examples subdirectory in the
|
||||
distribution. I suggest you read them carefully so you can see how the options
|
||||
go together in practice. See the man page for all the options.
|
||||
</para>
|
||||
|
||||
<para>The simplest useful configuration file would be
|
||||
something like this:</para>
|
||||
<para>
|
||||
The simplest useful configuration file would be something like this:
|
||||
</para>
|
||||
|
||||
<para><programlisting>
|
||||
[global]
|
||||
workgroup = MYGROUP
|
||||
<para>
|
||||
<programlisting>
|
||||
[global]
|
||||
workgroup = MYGROUP
|
||||
|
||||
[homes]
|
||||
guest ok = no
|
||||
read only = no
|
||||
</programlisting></para>
|
||||
[homes]
|
||||
guest ok = no
|
||||
read only = no
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<para>which would allow connections by anyone with an
|
||||
account on the server, using either their login name or
|
||||
"<command>homes</command>" as the service name. (Note that I also set the
|
||||
workgroup that Samba is part of. See BROWSING.txt for details)</para>
|
||||
<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.
|
||||
(Note that the workgroup that Samba must also be set.)
|
||||
</para>
|
||||
|
||||
<para>Make sure you put the <filename>smb.conf</filename> file in the same place
|
||||
<para>
|
||||
Make sure you put the <filename>smb.conf</filename> file in the same place
|
||||
you specified in the<filename>Makefile</filename> (the default is to
|
||||
look for it in <filename>/usr/local/samba/lib/</filename>).</para>
|
||||
look for it in <filename>/usr/local/samba/lib/</filename>).
|
||||
</para>
|
||||
|
||||
<para>For more information about security settings for the
|
||||
<para>
|
||||
For more information about security settings for the
|
||||
<command>[homes]</command> share please refer to the chapter
|
||||
<link linkend="securing-samba">Securing Samba</link>.</para>
|
||||
<link linkend="securing-samba">Securing Samba</link>.
|
||||
</para>
|
||||
|
||||
<sect3>
|
||||
<title>Test your config file with
|
||||
<command>testparm</command></title>
|
||||
<title>Test your config file with <command>testparm</command></title>
|
||||
|
||||
<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 then it will list the loaded services. If
|
||||
not it will give an error message.</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
|
||||
then it will list the loaded services. If not it will give an error message.
|
||||
</para>
|
||||
|
||||
<para>Make sure it runs OK and that the services look
|
||||
reasonable before proceeding. </para>
|
||||
<para>
|
||||
Make sure it runs OK and that the services look reasonable before proceeding.
|
||||
</para>
|
||||
|
||||
<para>Always run testparm again when you change
|
||||
<filename>smb.conf</filename>!</para>
|
||||
<para>
|
||||
Always run testparm again when you change <filename>smb.conf</filename>!
|
||||
</para>
|
||||
|
||||
</sect3>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<sect2>
|
||||
<title>SWAT</title>
|
||||
|
||||
<para>
|
||||
@ -99,15 +113,21 @@
|
||||
on compiling, installing and configuring swat from source.
|
||||
</para>
|
||||
|
||||
<para>To launch SWAT just run your favorite web browser and
|
||||
point it at "http://localhost:901/". 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.</para>
|
||||
<para>
|
||||
To launch SWAT just run your favorite web browser and
|
||||
point it at "http://localhost:901/". 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.
|
||||
</para>
|
||||
|
||||
<para>Note that you can attach to SWAT from any IP connected
|
||||
<para>
|
||||
Note that you can attach to SWAT from any IP connected
|
||||
machine but connecting from a remote machine leaves your
|
||||
connection open to password sniffing as passwords will be sent
|
||||
in the clear over the wire. </para>
|
||||
</sect2>
|
||||
in the clear over the wire.
|
||||
</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
@ -179,5 +199,86 @@
|
||||
Samba has been successfully installed at thousands of sites worldwide,
|
||||
so maybe someone else has hit your problem and has overcome it. </para>
|
||||
|
||||
</sect1>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Common Errors</title>
|
||||
|
||||
<para>
|
||||
The following questions and issues get raised on the samba mailing list over and over again.
|
||||
</para>
|
||||
|
||||
<sect2>
|
||||
<title>Why are so many smbd processes eating memory?</title>
|
||||
|
||||
<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
|
||||
processes of smbd running:
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Is samba suppose to start this many different smbd processes? Or does it run as one smbd process? Also
|
||||
is it normal for it to be taking up this much memory?
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<programlisting>
|
||||
Inuse * 4096 = amount of memory being used by this process
|
||||
|
||||
Pid Command Inuse Pin Pgsp Virtual 64-bit Mthrd
|
||||
20950 smbd 33098 1906 181 5017 N N
|
||||
22262 smbd 9104 1906 5410
|
||||
21060 smbd 9048 1906 181 5479 N N
|
||||
25972 smbd 8678 1906 181 5109 N N
|
||||
24524 smbd 8674 1906 181 5105 N N
|
||||
19262 smbd 8582 1906 181 5013 N N
|
||||
20722 smbd 8572 1906 181 5003 N N
|
||||
21454 smbd 8572 1906 181 5003 N N
|
||||
28946 smbd 8567 1906 181 4996 N N
|
||||
24076 smbd 8566 1906 181 4996 N N
|
||||
20138 smbd 8566 1906 181 4996 N N
|
||||
17608 smbd 8565 1906 181 4996 N N
|
||||
21820 smbd 8565 1906 181 4996 N N
|
||||
26940 smbd 8565 1906 181 4996 N N
|
||||
19884 smbd 8565 1906 181 4996 N N
|
||||
9912 smbd 8565 1906 181 4996 N N
|
||||
25800 smbd 8564 1906 181 4995 N N
|
||||
20452 smbd 8564 1906 181 4995 N N
|
||||
18592 smbd 8562 1906 181 4993 N N
|
||||
28216 smbd 8521 1906 181 4954 N N
|
||||
19110 smbd 8404 1906 181 4862 N N
|
||||
|
||||
Total memory used: 841,592,832 bytes
|
||||
</programlisting>
|
||||
</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
|
||||
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
|
||||
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
|
||||
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
|
||||
run in "split mode" (in which case there will be two instances).
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
</chapter>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user