Table 4-2 shows the options that are commonly used in association with Samba on a Windows NT domain.
Table 4-2. Windows NT domain options
Option |
Parameters |
Function |
Default |
Scope |
---|---|---|---|---|
|
boolean |
Indicates whether Windows domain logons are to be used |
|
Global |
|
boolean |
For telling Samba to take the role of domain master browser |
Auto |
Global |
|
string (command) |
Script to run to add a user or computer account |
None |
Global |
|
string (command) |
Script to run to delete a user or computer account |
None |
Global |
|
string (list of users) |
Users that are in the Domain Admins group |
None |
Global |
|
string (list of users) |
Users that are in the Domain Guests group |
None |
Global |
|
string (list of computers) |
List of domain controllers used for authentication when Samba is running as a domain member server |
None |
Global |
|
numeric (seconds) |
Sets the renewal interval for NT domain machine passwords |
|
Global |
Here are detailed explanations of each Windows NT domain option listed in Table 4-2.
This option configures Samba to accept domain logons as a primary
domain controller. When a client successfully logs on to the domain,
Samba will return a special token to the client that allows the
client to access domain shares without consulting the PDC again for
authentication. Note that the Samba machine must employ user-level
security (security
=
user
) and must be the PDC for this option to
function. In addition, Windows machines will expect a
[netlogon]
share to exist on the Samba server.
In a Windows network, a local master browser handles browsing within
a subnet. A Windows domain can be made up of a number of subnets,
each of which has its own local master browser. The primary domain
controller serves the function of domain master browser, collecting
the browse lists from the local master browser of each subnet. Each
local master browser queries the domain master browser and adds the
information about other subnets to their own browse lists. When Samba
is configured as a primary domain controller, it automatically sets
domain
master
=
yes
, making itself the domain
master browser.
Because Windows NT PDCs always claim the role of domain master browser, Samba should never be allowed to be domain master if there is a Windows PDC in the domain.
There are two ways in which add
user
script
can be used. When
the Samba server is set up as a primary domain controller, it can be
assigned to a command that will run on the Samba server to add a
Windows NT/2000/XP computer account to Samba’s
password database. When the user on the Windows system changes the
computer’s settings to join a domain, he is asked
for the username and password of a user who has administrative rights
on the domain controller. Samba authenticates this user and then runs
the add
user
script
with root permissions.
When Samba is configured as a domain member server, the
add
user
script
can be assigned to a command to add a user
to the system. This allows Windows clients to add users that can
access shares on the Samba system without requiring an administrator
to create the account manually on the Samba host.
There are times when users are automatically deleted from the domain,
and the delete
user
script
can be assigned to a command that removes a
user from the Samba host as a Windows server would do. However, you
might not want this to happen, because the Unix user might need the
account for reasons other than use with Samba. Therefore, we
recommend that you be very careful about using this option.
In a domain of Windows systems, it is possible for a server to get a
list of the members of the Domain Admins group from a domain
controller. Samba 2.2 does not have the ability to handle this, and
the domain
admin
group
parameter exists as a manual means of
informing Samba who is in the group. The list should contain root
(necessary for adding computer accounts) and any users on Windows
NT/2000/XP clients in the domain who are in the Domain Admins group.
These users must be recognized by the primary controller in order for
them to perform some administrative duties such as adding users to
the domain.
In a Windows domain in which the domain controllers are a Windows
primary domain controller, along with any number of Windows backup
domain controllers, clients and domain member servers authenticate
users by querying either the PDC or any of the BDCs. When Samba is
configured as a domain member server, the password
server
parameter allows some control over how
Samba finds a domain controller. Earlier versions of Samba could not
use the same method that Windows systems use, and it was necessary to
specify a list of systems to try. When you set
password
server
=
*
, Samba 2.2 is able to find
the domain controller in the same manner that Windows does, which
helps to spread the requests over several backup domain controllers,
minimizing the possibility of them becoming overloaded with
authentication requests. We recommend that you use this method.
The machine
password
timeout
global option sets a retention period for
Windows NT domain machine passwords. The default is currently set to
the same time period that Windows NT 4.0 uses: 604,800 seconds (one
week). Samba will periodically attempt to change the
machine account password, which is a password
used specifically by another server to report changes to it. This
option specifies the number of seconds that Samba should wait before
attempting to change that password. The timeout period can be changed
to a single day by specifying the following:
[global] machine password timeout = 86400
Get Using Samba, Second Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.