458
The architecture of the remote machine\&. It currently recognizes Samba (\fBSamba\fR), the Linux CIFS file system (\fBCIFSFS\fR), OS/2, (\fBOS2\fR), Windows for Workgroups (\fBWfWg\fR), Windows 9x/ME (\fBWin95\fR), Windows NT (\fBWinNT\fR), Windows 2000 (\fBWin2K\fR), Windows XP (\fBWinXP\fR), Windows XP 64\-bit(\fBWinXP64\fR), Windows 2003 including 2003R2 (\fBWin2K3\fR), and Windows Vista (\fBVista\fR)\&. Anything else will be known as
460
The architecture of the remote machine\&. It currently recognizes Samba (\fBSamba\fR), the Linux CIFS file system (\fBCIFSFS\fR), OS/2, (\fBOS2\fR), Mac OS X (\fBOSX\fR), Windows for Workgroups (\fBWfWg\fR), Windows 9x/ME (\fBWin95\fR), Windows NT (\fBWinNT\fR), Windows 2000 (\fBWin2K\fR), Windows XP (\fBWinXP\fR), Windows XP 64\-bit(\fBWinXP64\fR), Windows 2003 including 2003R2 (\fBWin2K3\fR), and Windows Vista (\fBVista\fR)\&. Anything else will be known as
464
466
the IP address of the client machine\&.
468
Before 3\&.6\&.0 it could contain IPv4 mapped IPv6 addresses, now it only contains IPv4 or IPv6 addresses\&.
469
473
the local IP address to which a client connected\&.
475
Before 3\&.6\&.0 it could contain IPv4 mapped IPv6 addresses, now it only contains IPv4 or IPv6 addresses\&.
554
560
default case = upper/lower
556
562
controls what the default case is for new filenames (ie\&. files that don\'t currently exist in the filesystem)\&. Default
557
\fIlower\fR\&. IMPORTANT NOTE: This option will be used to modify the case of
559
incoming client filenames, not just new filenames if the options
563
\fIlower\fR\&. IMPORTANT NOTE: As part of the optimizations for directories containing large numbers of files, the following special case applies\&. If the options
560
564
\m[blue]\fBcase sensitive = yes\fR\m[],
561
\m[blue]\fBpreserve case = No\fR\m[],
565
\m[blue]\fBpreserve case = No\fR\m[], and
562
566
\m[blue]\fBshort preserve case = No\fR\m[]
563
are set\&. This change is needed as part of the optimisations for directories containing large numbers of files\&.
567
are set, then the case of
569
incoming client filenames, not just new filenames, will be modified\&. See additional notes below\&.
566
572
preserve case = yes/no
1352
1361
\fI\fIallocation roundup size\fR\fR\fI = \fR\fI0 # (to disable roundups)\fR\fI \fR
1364
allow insecure wide links (G)
1365
.\" allow insecure wide links
1368
In normal operation the option
1369
\m[blue]\fBwide links\fR\m[]
1370
which allows the server to follow symlinks outside of a share path is automatically disabled when
1371
\m[blue]\fBunix extensions\fR\m[]
1372
are enabled on a Samba server\&. This is done for security purposes to prevent UNIX clients creating symlinks to areas of the server file system that the administrator does not wish to export\&.
1375
\m[blue]\fBallow insecure wide links\fR\m[]
1376
to true disables the link between these two parameters, removing this protection and allowing a site to configure the server to follow symlinks (by setting
1377
\m[blue]\fBwide links\fR\m[]
1378
to "true") even when
1379
\m[blue]\fBunix extensions\fR\m[]
1382
If is not recommended to enable this option unless you fully understand the implications of allowing the server to follow symbolic links created by UNIX clients\&. For most normal Samba configurations this would be considered a security hole and setting this parameter is not recommended\&.
1384
This option was added at the request of sites who had deliberately set Samba up in this way and needed to continue supporting this functionality without having to patch the Samba code\&.
1387
\fI\fIallow insecure wide links\fR\fR\fI = \fR\fIno\fR\fI \fR
1355
1390
allow trusted domains (G)
1356
1391
.\" allow trusted domains
1849
1895
If disabled, an NTLM response (and possibly a LANMAN response) will be sent by the client, depending on the value of
1850
1896
client lanman auth\&.
1852
Note that some sites (particularly those following \'best practice\' security polices) only allow NTLMv2 responses, and not the weaker LM or NTLM\&.
1898
Note that Windows Vista and later versions already use NTLMv2 by default, and some sites (particularly those following \'best practice\' security polices) only allow NTLMv2 responses, and not the weaker LM or NTLM\&.
1855
\fI\fIclient ntlmv2 auth\fR\fR\fI = \fR\fIno\fR\fI \fR
1901
\fI\fIclient ntlmv2 auth\fR\fR\fI = \fR\fIyes\fR\fI \fR
1858
1904
client plaintext auth (G)
2119
2165
\fI\fIctdbd socket\fR\fR\fI = \fR\fI/tmp/ctdb\&.socket\fR\fI \fR
2168
ctdb locktime warn threshold (G)
2169
.\" ctdb locktime warn threshold
2172
In a cluster environment using Samba and ctdb it is critical that locks on central ctdb\-hosted databases like locking\&.tdb are not held for long\&. With the current Samba architecture it happens that Samba takes a lock and while holding that lock makes file system calls into the shared cluster file system\&. This option makes Samba warn if it detects that it has held locks for the specified number of milliseconds\&. If this happens,
2174
will emit a debug level 0 message into its logs and potentially into syslog\&. The most likely reason for such a log message is that an operation of the cluster file system Samba exports is taking longer than expected\&. The messages are meant as a debugging aid for potential cluster problems\&.
2176
The default value of 0 disables this logging\&.
2179
\fI\fIctdb locktime warn threshold\fR\fR\fI = \fR\fI0\fR\fI \fR
2122
2182
ctdb timeout (G)
2123
2183
.\" ctdb timeout
3907
3971
\fI\fIhosts deny\fR\fR\fI = \fR\fI150\&.203\&.4\&. badhost\&.mynet\&.edu\&.au\fR\fI \fR
3910
idmap alloc backend (G)
3911
.\" idmap alloc backend
3914
The idmap alloc backend provides a plugin interface for Winbind to use when allocating Unix uids/gids for Windows SIDs\&. This option refers to the name of the idmap module which will provide the id allocation functionality\&. Please refer to the man page for each idmap plugin to determine whether or not the module implements the allocation feature\&. The most common plugins are the tdb (\fBidmap_tdb\fR(8)) and ldap (\fBidmap_ldap\fR(8)) libraries\&.
3916
This parameter defaults to the value
3917
\m[blue]\fBidmap backend\fR\m[]
3918
was set to, so by default winbind will allocate Unix IDs from the default backend\&. You will only need to set this parameter explicitly if you have an external source for Unix IDs, like a central database service somewhere in your company\&.
3921
\m[blue]\fBidmap alloc config\fR\m[]
3927
\fI\fIidmap alloc backend\fR\fR\fI = \fR\fItdb\fR\fI \fR
3930
idmap alloc config (G)
3931
.\" idmap alloc config
3934
The idmap alloc config prefix provides a means of managing settings for the backend defined by the
3935
\m[blue]\fBidmap alloc backend\fR\m[]
3936
parameter\&. Refer to the man page for each idmap plugin regarding specific configuration details\&.
3941
3974
idmap backend (G)
3942
3975
.\" idmap backend
3945
3978
The idmap backend provides a plugin interface for Winbind to use varying backends to store SID/uid/gid mapping tables\&.
3947
This option specifies the default backend that is used when no special configuration set by
3948
\m[blue]\fBidmap config\fR\m[]
3949
matches the specific request\&.
3951
This default backend also specifies the place where winbind\-generated idmap entries will be stored\&. So it is highly recommended that you specify a writable backend like
3955
as the idmap backend\&. The
3959
backends are not writable and thus will generate unexpected results if set as idmap backend\&.
3961
To use the rid and ad backends, please specify them via the
3962
\m[blue]\fBidmap config\fR\m[]
3963
parameter, possibly also for the domain your machine is member of, specified by
3964
\m[blue]\fBworkgroup\fR\m[]\&.
3966
Examples of SID/uid/gid backends include tdb (\fBidmap_tdb\fR(8)), ldap (\fBidmap_ldap\fR(8)), rid (\fBidmap_rid\fR(8)), and ad (\fBidmap_ad\fR(8))\&.
3980
This option specifies the default backend that is used when no special configuration set, but it is now deprecated in favour of the new spelling
3981
\m[blue]\fBidmap config * : backend\fR\m[]\&.
3969
3984
\fI\fIidmap backend\fR\fR\fI = \fR\fItdb\fR\fI \fR
3983
3998
.\" idmap config
3986
The idmap config prefix provides a means of managing each trusted domain separately\&. The idmap config prefix should be followed by the name of the domain, a colon, and a setting specific to the chosen backend\&. There are three options available for all domains:
4001
ID mapping in Samba is the mapping between Windows SIDs and Unix user and group IDs\&. This is performed by Winbindd with a configurable plugin interface\&. Samba\'s ID mapping is configured by options starting with the
4002
\m[blue]\fBidmap config\fR\m[]
4003
prefix\&. An idmap option consists of the
4004
\m[blue]\fBidmap config\fR\m[]
4005
prefix, followed by a domain name or the asterisk character (*), a colon, and the name of an idmap setting for the chosen domain\&.
4007
The idmap configuration is hence divided into groups, one group for each domain to be configured, and one group with the the asterisk instead of a proper domain name, which speifies the default configuration that is used to catch all domains that do not have an explicit idmap configuration of their own\&.
4009
There are three general options available:
3988
4011
backend = backend_name
3990
Specifies the name of the idmap plugin to use as the SID/uid/gid backend for this domain\&.
4013
This specifies the name of the idmap plugin to use as the SID/uid/gid backend for this domain\&. The standard backends are tdb (\fBidmap_tdb\fR(8)), tdb2 (\fBidmap_tdb2\fR(8)), ldap (\fBidmap_ldap\fR(8)), , rid (\fBidmap_rid\fR(8)), , hash (\fBidmap_hash\fR(8)), , autorid (\fBidmap_autorid\fR(8)), , ad (\fBidmap_ad\fR(8)), , adex (\fBidmap_adex\fR(8)), , and nss\&. (\fBidmap_nss\fR(8)), The corresponding manual pages contain the details, but here is a summary\&.
4015
The first three of these create mappings of their own using internal unixid counters and store the mappings in a database\&. These are suitable for use in the default idmap configuration\&. The rid and hash backends use a pure algorithmic calculation to determine the unixid for a SID\&. The autorid module is a mixture of the tdb and rid backend\&. It creates ranges for each domain encountered and then uses the rid algorithm for each of these automatically configured domains individually\&. The ad and adex backends both use unix IDs stored in Active Directory via the standard schema extensions\&. The nss backend reverses the standard winbindd setup and gets the unixids via names from nsswitch which can be useful in an ldap setup\&.
3993
4018
range = low \- high
3995
Defines the available matching uid and gid range for which the backend is authoritative\&. Note that the range commonly matches the allocation range due to the fact that the same backend will store and retrieve SID/uid/gid mapping entries\&.
4020
Defines the available matching uid and gid range for which the backend is authoritative\&. For allocating backends, this also defines the start and the end of the range for allocating new unid IDs\&.
3997
winbind uses this parameter to find the backend that is authoritative for a unix ID to SID mapping, so it must be set for each individually configured domain, and it must be disjoint from the ranges set via
3998
\m[blue]\fBidmap uid\fR\m[]
4000
\m[blue]\fBidmap gid\fR\m[]\&.
4022
winbind uses this parameter to find the backend that is authoritative for a unix ID to SID mapping, so it must be set for each individually configured domain and for the default configuration\&. The configured ranges must be mutually disjoint\&.
4027
This option can be used to turn the writing backends tdb, tdb2, and ldap into read only mode\&. This can be useful e\&.g\&. in cases where a pre\-filled database exists that should not be extended automatically\&.
4003
4030
The following example illustrates how to configure the
4004
4031
\fBidmap_ad\fR(8)
4005
for the CORP domain and the
4032
backend for the CORP domain and the
4006
4033
\fBidmap_tdb\fR(8)
4007
4034
backend for all other domains\&. This configuration assumes that the admin of CORP assigns unix ids below 1000000 via the SFU extensions, and winbind is supposed to use the next million entries for its own mappings from trusted domains and for local groups for example\&.
7316
7391
security = [ads|domain|server]
7317
7392
it is possible to get Samba to do all its username/password validation using a specific remote server\&.
7319
This option sets the name or IP address of the password server to use\&. New syntax has been added to support defining the port to use when connecting to the server the case of an ADS realm\&. To define a port other than the default LDAP port of 389, add the port number using a colon after the name or IP address (e\&.g\&. 192\&.168\&.1\&.100:389)\&. If you do not specify a port, Samba will use the standard LDAP port of tcp/389\&. Note that port numbers have no effect on password servers for Windows NT 4\&.0 domains or netbios connections\&.
7399
\fBads\fR, then this option
7401
be used, as the default \'*\' indicates to Samba to determine the best DC to contact dynamically, just as all other hosts in an AD domain do\&. This allows the domain to be maintained without modification to the smb\&.conf file\&. The cryptograpic protection on the authenticated RPC calls used to verify passwords ensures that this default is safe\&.
7403
\fIIt is strongly recommended that you use the default of \'*\'\fR, however if in your particular environment you have reason to specify a particular DC list, then the list of machines in this option must be a list of names or IP addresses of Domain controllers for the Domain\&. If you use the default of \'*\', or list several hosts in the
7404
\fIpassword server\fR
7407
will try each in turn till it finds one that responds\&. This is useful in case your primary server goes down\&.
7409
If the list of servers contains both names/IP\'s and the \'*\' character, the list is treated as a list of preferred domain controllers, but an auto lookup of all remaining DC\'s will be added to the list as well\&. Samba will not attempt to optimize this list by locating the closest DC\&.
7321
7411
If parameter is a name, it is looked up using the parameter
7322
7412
\m[blue]\fBname resolve order\fR\m[]
7323
7413
and so may resolved by any method and order described in that parameter\&.
7418
\fBserver\fR, these additional restrictions apply:
7422
\h'-04'\(bu\h'+03'\c
7428
You may list several password servers in the
7429
\fIpassword server\fR
7430
parameter, however if an
7432
makes a connection to a password server, and then the password server fails, no more users will be able to be authenticated from this
7433
smbd\&. This is a restriction of the SMB/CIFS protocol when in
7435
mode and cannot be fixed in Samba\&.
7440
\h'-04'\(bu\h'+03'\c
7446
You will have to ensure that your users are able to login from the Samba server, as when in
7448
mode the network logon will appear to come from the Samba server rather than from the users workstation\&.
7453
\h'-04'\(bu\h'+03'\c
7459
The client must not select NTLMv2 authentication\&.
7464
\h'-04'\(bu\h'+03'\c
7325
7470
The password server must be a machine capable of using the "LM1\&.2X002" or the "NT LM 0\&.12" protocol, and it must be in user level security mode\&.
7331
.nr an-no-space-flag 1
7338
Using a password server means your UNIX box (running Samba) is only as secure as your password server\&.
7475
\h'-04'\(bu\h'+03'\c
7481
Using a password server means your UNIX box (running Samba) is only as secure as (a host masqurading as) your password server\&.
7339
7482
\fIDO NOT CHOOSE A PASSWORD SERVER THAT YOU DON\'T COMPLETELY TRUST\fR\&.
7487
\h'-04'\(bu\h'+03'\c
7342
7493
Never point a Samba server at itself for password serving\&. This will cause a loop and could lock up your Samba server!
7498
\h'-04'\(bu\h'+03'\c
7344
7504
The name of the password server takes the standard substitutions, but probably the only useful one is
7345
7505
\fI%m \fR, which means the Samba server will use the incoming client as the password server\&. If you use this then you better trust your clients, and you had better restrict them with hosts allow!
7352
\fBads\fR, then the list of machines in this option must be a list of Primary or Backup Domain controllers for the Domain or the character \'*\', as the Samba server is effectively in that domain, and will use cryptographically authenticated RPC calls to authenticate the user logging on\&. The advantage of using
7354
is that if you list several hosts in the
7355
\fIpassword server\fR
7358
will try each in turn till it finds one that responds\&. This is useful in case your primary server goes down\&.
7361
\fIpassword server\fR
7362
option is set to the character \'*\', then Samba will attempt to auto\-locate the Primary or Backup Domain controllers to authenticate against by doing a query for the name
7364
and then contacting each server returned in the list of IP addresses from the name resolution source\&.
7366
If the list of servers contains both names/IP\'s and the \'*\' character, the list is treated as a list of preferred domain controllers, but an auto lookup of all remaining DC\'s will be added to the list as well\&. Samba will not attempt to optimize this list by locating the closest DC\&.
7371
\fBserver\fR, then there are different restrictions that
7373
doesn\'t suffer from:
7377
\h'-04'\(bu\h'+03'\c
7383
You may list several password servers in the
7384
\fIpassword server\fR
7385
parameter, however if an
7387
makes a connection to a password server, and then the password server fails, no more users will be able to be authenticated from this
7388
smbd\&. This is a restriction of the SMB/CIFS protocol when in
7390
mode and cannot be fixed in Samba\&.
7395
\h'-04'\(bu\h'+03'\c
7401
If you are using a Windows NT server as your password server then you will have to ensure that your users are able to login from the Samba server, as when in
7403
mode the network logon will appear to come from there rather than from the users workstation\&.
8315
8432
\fI\fIroot preexec\fR\fR\fI = \fR\fI\fR\fI \fR
8439
Defines what kind of rpc server to use for a named pipe\&. The rpc_server prefix must be followed by the pipe name, and a value\&.
8441
Three possible values are currently supported:
8446
The classic method is to run every pipe as an internal function
8450
An alternative method is to fork a
8452
early on at smbd startup time\&. This is supported only for selected pipes\&.
8456
option allows to run a completely independent (3rd party) server capable of interfacing with samba via the MS\-RPC interface over named pipes\&.
8458
Currently only the spoolss pipe can be configured in
8466
rpc_server:spoolss = daemon
8474
\fI\fIrpc_server\fR\fR\fI = \fR\fInone\fR\fI \fR
8318
8477
security mask (S)
8319
8478
.\" security mask
8355
8514
security = user, as this is the most common setting needed when talking to Windows 98 and Windows NT\&.
8357
8516
The alternatives are
8361
security = domain\&.
8519
security = domain, which support joining Samba to a Windows domain, along with
8522
security = server, both of which are deprecated\&.
8363
8524
In versions of Samba prior to 2\&.0\&.0, the default was
8364
8525
security = share
8365
8526
mainly because that was the only option at one stage\&.
8367
There is a bug in WfWg that has relevance to this setting\&. When in user or server level security a WfWg client will totally ignore the username and password you type in the "connect drive" dialog box\&. This makes it very difficult (if not impossible) to connect to a Samba service as anyone except the user that you are logged into WfWg as\&.
8369
If your PCs use usernames that are the same as their usernames on the UNIX machine then you will want to use
8370
security = user\&. If you mostly use usernames that don\'t exist on the UNIX box then use
8375
if you want to mainly setup shares without a password (guest shares)\&. This is commonly used for a shared printer server\&. It is more difficult to setup guest shares with
8376
security = user, see the
8377
8531
\m[blue]\fBmap to guest\fR\m[]
8378
parameter for details\&.
8532
if you want to mainly setup shares without a password (guest shares)\&. This is commonly used for a shared printer server\&.
8380
8534
It is possible to use
8387
8541
The different settings will now be explained\&.
8543
\fISECURITY = USER\fR
8545
This is the default security setting in Samba\&. With user\-level security a client must first "log\-on" with a valid username and password (which can be mapped using the
8546
\m[blue]\fBusername map\fR\m[]
8547
parameter)\&. Encrypted passwords (see the
8548
\m[blue]\fBencrypted passwords\fR\m[]
8549
parameter) can also be used in this security mode\&. Parameters such as
8550
\m[blue]\fBuser\fR\m[]
8552
\m[blue]\fBguest only\fR\m[]
8553
if set are then applied and may change the UNIX user to use on this connection, but only after the user has been successfully authenticated\&.
8556
that the name of the resource being requested is
8558
sent to the server until after the server has successfully authenticated the client\&. This is why guest shares don\'t work in user level security without allowing the server to automatically map unknown users into the
8559
\m[blue]\fBguest account\fR\m[]\&. See the
8560
\m[blue]\fBmap to guest\fR\m[]
8561
parameter for details on doing this\&.
8563
See also the section
8564
NOTE ABOUT USERNAME/PASSWORD VALIDATION\&.
8566
\fISECURITY = DOMAIN\fR
8568
This mode will only work correctly if
8570
has been used to add this machine into a Windows NT Domain\&. It expects the
8571
\m[blue]\fBencrypted passwords\fR\m[]
8572
parameter to be set to
8573
\fByes\fR\&. In this mode Samba will try to validate the username/password by passing it to a Windows NT Primary or Backup Domain Controller, in exactly the same way that a Windows NT Server would do\&.
8576
that a valid UNIX user must still exist as well as the account on the Domain Controller to allow Samba to have a valid UNIX account to map file access to\&.
8579
that from the client\'s point of view
8582
security = user\&. It only affects how the server deals with the authentication, it does not in any way affect what the client sees\&.
8585
that the name of the resource being requested is
8587
sent to the server until after the server has successfully authenticated the client\&. This is why guest shares don\'t work in user level security without allowing the server to automatically map unknown users into the
8588
\m[blue]\fBguest account\fR\m[]\&. See the
8589
\m[blue]\fBmap to guest\fR\m[]
8590
parameter for details on doing this\&.
8592
See also the section
8593
NOTE ABOUT USERNAME/PASSWORD VALIDATION\&.
8596
\m[blue]\fBpassword server\fR\m[]
8598
\m[blue]\fBencrypted passwords\fR\m[]
8389
8601
\fISECURITY = SHARE\fR
8607
.nr an-no-space-flag 1
8614
This option is deprecated as it is incompatible with SMB2
8391
8617
When clients connect to a share level security server, they need not log onto the server with a valid username and password before attempting to connect to a shared resource (although modern clients such as Windows 95/98 and Windows NT will send a logon request with a username but no password when talking to a
8392
8618
security = share
8393
8619
server)\&. Instead, the clients send authentication information (passwords) on a per\-share basis, at the time they attempt to connect to that share\&.
8496
8723
See also the section
8497
8724
NOTE ABOUT USERNAME/PASSWORD VALIDATION\&.
8499
\fISECURITY = USER\fR
8501
This is the default security setting in Samba 3\&.0\&. With user\-level security a client must first "log\-on" with a valid username and password (which can be mapped using the
8502
\m[blue]\fBusername map\fR\m[]
8503
parameter)\&. Encrypted passwords (see the
8504
\m[blue]\fBencrypted passwords\fR\m[]
8505
parameter) can also be used in this security mode\&. Parameters such as
8506
\m[blue]\fBuser\fR\m[]
8508
\m[blue]\fBguest only\fR\m[]
8509
if set are then applied and may change the UNIX user to use on this connection, but only after the user has been successfully authenticated\&.
8512
that the name of the resource being requested is
8514
sent to the server until after the server has successfully authenticated the client\&. This is why guest shares don\'t work in user level security without allowing the server to automatically map unknown users into the
8515
\m[blue]\fBguest account\fR\m[]\&. See the
8516
\m[blue]\fBmap to guest\fR\m[]
8517
parameter for details on doing this\&.
8519
See also the section
8520
NOTE ABOUT USERNAME/PASSWORD VALIDATION\&.
8522
\fISECURITY = DOMAIN\fR
8524
This mode will only work correctly if
8526
has been used to add this machine into a Windows NT Domain\&. It expects the
8527
\m[blue]\fBencrypted passwords\fR\m[]
8528
parameter to be set to
8529
\fByes\fR\&. In this mode Samba will try to validate the username/password by passing it to a Windows NT Primary or Backup Domain Controller, in exactly the same way that a Windows NT Server would do\&.
8532
that a valid UNIX user must still exist as well as the account on the Domain Controller to allow Samba to have a valid UNIX account to map file access to\&.
8535
that from the client\'s point of view
8538
security = user\&. It only affects how the server deals with the authentication, it does not in any way affect what the client sees\&.
8541
that the name of the resource being requested is
8543
sent to the server until after the server has successfully authenticated the client\&. This is why guest shares don\'t work in user level security without allowing the server to automatically map unknown users into the
8544
\m[blue]\fBguest account\fR\m[]\&. See the
8545
\m[blue]\fBmap to guest\fR\m[]
8546
parameter for details on doing this\&.
8548
See also the section
8549
NOTE ABOUT USERNAME/PASSWORD VALIDATION\&.
8552
\m[blue]\fBpassword server\fR\m[]
8554
\m[blue]\fBencrypted passwords\fR\m[]
8557
8726
\fISECURITY = SERVER\fR
8559
In this mode Samba will try to validate the username/password by passing it to another SMB server, such as an NT box\&. If this fails it will revert to
8728
In this depicted mode Samba will try to validate the username/password by passing it to another SMB server, such as an NT box\&. If this fails it will revert to
8560
8729
security = user\&. It expects the
8561
8730
\m[blue]\fBencrypted passwords\fR\m[]
8562
8731
parameter to be set to
8578
This mode of operation has significant pitfalls since it is more vulnerable to man\-in\-the\-middle attacks and server impersonation\&. In particular, this mode of operation can cause significant resource consuption on the PDC, as it must maintain an active connection for the duration of the user\'s session\&. Furthermore, if this connection is lost, there is no way to reestablish it, and futher authentications to the Samba server may fail (from a single client, till it disconnects)\&.
8747
This mode of operation has significant pitfalls since it is more vulnerable to man\-in\-the\-middle attacks and server impersonation\&. In particular, this mode of operation can cause significant resource consumption on the PDC, as it must maintain an active connection for the duration of the user\'s session\&. Furthermore, if this connection is lost, there is no way to reestablish it, and further authentications to the Samba server may fail (from a single client, till it disconnects)\&.
8755
.nr an-no-space-flag 1
8762
If the client selects NTLMv2 authentication, then this mode of operation
8628
8828
\fI\fIsecurity\fR\fR\fI = \fR\fIDOMAIN\fR\fI \fR
8831
send spnego principal (G)
8832
.\" send spnego principal
8835
This parameter determines whether or not
8837
will send the server\-supplied principal sometimes given in the SPNEGO exchange\&.
8839
If enabled, Samba can attempt to help clients to use Kerberos to contact it, even when known only by IP address or a name not registered with our KDC as a service principal name\&. Kerberos relies on names, so ordinarily cannot function in this situation\&.
8841
If disabled, Samba will send the string not_defined_in_RFC4178@please_ignore as the \'rfc4178 hint\', following the updated RFC and Windows 2008 behaviour in this area\&.
8843
Note that Windows XP SP2 and later versions already ignored this value in all circumstances\&.
8846
\fI\fIsend spnego principal\fR\fR\fI = \fR\fIno\fR\fI \fR
8631
8849
server schannel (G)
8632
8850
.\" server schannel
9060
9281
\fI\fIshutdown script\fR\fR\fI = \fR\fI/usr/local/samba/sbin/shutdown %m %t %r %f\fR\fI \fR
9284
smb2 max credits (G)
9285
.\" smb2 max credits
9288
This option controls the maximum number of outstanding simultaneous SMB2 operations that Samba tells the client it will allow\&. This is similar to the
9289
\m[blue]\fBmax mux\fR\m[]
9290
parameter for SMB1\&. You should never need to set this parameter\&.
9292
The default is 8192 credits, which is the same as a Windows 2008R2 SMB2 server\&.
9295
\fI\fIsmb2 max credits\fR\fR\fI = \fR\fI8192\fR\fI \fR
9302
This option specifies the protocol value that
9304
will return to a client, informing the client of the largest size that may be returned by a single SMB2 read call\&.
9306
The maximum is 65536 bytes (64KB), which is the same as a Windows Vista SMB2 server\&.
9309
\fI\fIsmb2 max read\fR\fR\fI = \fR\fI65536\fR\fI \fR
9316
This option specifies the protocol value that
9318
will return to a client, informing the client of the largest size of buffer that may be used in querying file meta\-data via QUERY_INFO and related SMB2 calls\&.
9320
The maximum is 65536 bytes (64KB), which is the same as a Windows Vista SMB2 server\&.
9323
\fI\fIsmb2 max trans\fR\fR\fI = \fR\fI65536\fR\fI \fR
9330
This option specifies the protocol value that
9332
will return to a client, informing the client of the largest size that may be sent to the server by a single SMB2 write call\&.
9334
The maximum is 65536 bytes (64KB), which is the same as a Windows Vista SMB2 server\&.
9337
\fI\fIsmb2 max write\fR\fR\fI = \fR\fI65536\fR\fI \fR
9063
9340
smb encrypt (S)
9064
9341
.\" smb encrypt
9346
9624
This is a boolean that controls the handling of disk space allocation in the server\&. When this is set to
9348
the server will change from UNIX behaviour of not committing real disk storage blocks when a file is extended to the Windows behaviour of actually forcing the disk system to allocate real storage blocks when a file is created or extended to be a given size\&. In UNIX terminology this means that Samba will stop creating sparse files\&. This can be slow on some systems\&. When you work with large files like >100MB or so you may even run into problems with clients running into timeouts\&.
9626
the server will change from UNIX behaviour of not committing real disk storage blocks when a file is extended to the Windows behaviour of actually forcing the disk system to allocate real storage blocks when a file is created or extended to be a given size\&. In UNIX terminology this means that Samba will stop creating sparse files\&.
9628
This option is really desgined for file systems that support fast allocation of large numbers of blocks such as extent\-based file systems\&. On file systems that don\'t support extents (most notably ext3) this can make Samba slower\&. When you work with large files over >100MB on file systems without extents you may even run into problems with clients running into timeouts\&.
9350
9630
When you have an extent based filesystem it\'s likely that we can make use of unwritten extents which allows Samba to allocate even large amounts of space very fast and you will not see any timeout problems caused by strict allocate\&. With strict allocate in use you will also get much better out of quota messages in case you use quotas\&. Another advantage of activating this setting is that it will help to reduce file fragmentation\&.
9556
9854
\fI\fIunix password sync\fR\fR\fI = \fR\fIno\fR\fI \fR
9559
update encrypted (G)
9560
.\" update encrypted
9563
This boolean parameter allows a user logging on with a plaintext password to have their encrypted (hashed) password in the smbpasswd file to be updated automatically as they log on\&. This option allows a site to migrate from plaintext password authentication (users authenticate with plaintext password over the wire, and are checked against a UNIX account database) to encrypted password authentication (the SMB challenge/response authentication mechanism) without forcing all users to re\-enter their passwords via smbpasswd at the time the change is made\&. This is a convenience option to allow the change over to encrypted passwords to be made over a longer period\&. Once all users have encrypted representations of their passwords in the smbpasswd file this parameter should be set to
9566
In order for this parameter to be operative the
9567
\m[blue]\fBencrypt passwords\fR\m[]
9568
parameter must be set to
9569
\fBno\fR\&. The default value of
9570
\m[blue]\fBencrypt passwords = Yes\fR\m[]\&. Note: This must be set to
9573
\m[blue]\fBupdate encrypted\fR\m[]
9576
Note that even when this parameter is set, a user authenticating to
9578
must still enter a valid password in order to connect correctly, and to update their hashed (smbpasswd) passwords\&.
9581
\fI\fIupdate encrypted\fR\fR\fI = \fR\fIno\fR\fI \fR
9584
9857
use client driver (S)
9585
9858
.\" use client driver
9627
9900
\fI\fIusername level\fR\fR\fI = \fR\fI5\fR\fI \fR
9903
username map cache time (G)
9904
.\" username map cache time
9907
Mapping usernames with the
9908
\m[blue]\fBusername map\fR\m[]
9910
\m[blue]\fBusername map script\fR\m[]
9911
features of Samba can be relatively expensive\&. During login of a user, the mapping is done several times\&. In particular, calling the
9912
\m[blue]\fBusername map script\fR\m[]
9913
can slow down logins if external databases have to be queried from the script being called\&.
9916
\m[blue]\fBusername map cache time\fR\m[]
9917
controls a mapping cache\&. It specifies the number of seconds a mapping from the username map file or script is to be efficiently cached\&. The default of 0 means no caching is done\&.
9920
\fI\fIusername map cache time\fR\fR\fI = \fR\fI0\fR\fI \fR
9923
\fI\fIusername map cache time\fR\fR\fI = \fR\fI60\fR\fI \fR
9630
9926
username map script (G)
9631
9927
.\" username map script
10239
10539
\fI\fIwinbind expand groups\fR\fR\fI = \fR\fI1\fR\fI \fR
10542
winbind max clients (G)
10543
.\" winbind max clients
10546
This parameter specifies the maximum number of clients the
10548
daemon can connect with\&.
10551
\fI\fIwinbind max clients\fR\fR\fI = \fR\fI200\fR\fI \fR
10554
winbind max domain connections (G)
10555
.\" winbind max domain connections
10558
This parameter specifies the maximum number of simultaneous connections that the
10560
daemon should open to the domain controller of one domain\&. Setting this parameter to a value greater than 1 can improve scalability with many simultaneous winbind requests, some of which might be slow\&.
10563
\m[blue]\fBwinbind offline logon\fR\m[]
10565
\fBYes\fR, then only one DC connection is allowed per domain, regardless of this setting\&.
10568
\fI\fIwinbind max domain connections\fR\fR\fI = \fR\fI1\fR\fI \fR
10571
\fI\fIwinbind max domain connections\fR\fR\fI = \fR\fI10\fR\fI \fR
10242
10574
winbind nested groups (G)
10243
10575
.\" winbind nested groups
10404
10737
This parameter specifies whether the
10405
10738
\fBwinbindd\fR(8)
10406
daemon should operate on users without domain component in their username\&. Users without a domain component are treated as is part of the winbindd server\'s own domain\&. While this does not benifit Windows users, it makes SSH, FTP and e\-mail function in a way much closer to the way they would in a native unix system\&.
10739
daemon should operate on users without domain component in their username\&. Users without a domain component are treated as is part of the winbindd server\'s own domain\&. While this does not benefit Windows users, it makes SSH, FTP and e\-mail function in a way much closer to the way they would in a native unix system\&.
10741
This option should be avoided if possible\&. It can cause confusion about responsibilities for a user or group\&. In many situations it is not clear whether winbind or /etc/passwd should be seen as authoritative for a user, likewise for groups\&.
10409
10744
\fI\fIwinbind use default domain\fR\fR\fI = \fR\fIno\fR\fI \fR