From 8f8a9f01909ba29e2b781310baeeaaddc3f15f0d Mon Sep 17 00:00:00 2001 From: "Gerald W. Carter" Date: Tue, 22 Apr 2008 10:09:40 -0500 Subject: Moving docs tree to docs-xml to make room for generated docs in the release tarball. (This used to be commit 9f672c26d63955f613088489c6efbdc08b5b2d14) --- docs-xml/smbdotconf/security/aclgroupcontrol.xml | 43 ++++ docs-xml/smbdotconf/security/adminusers.xml | 21 ++ .../smbdotconf/security/algorithmicridbase.xml | 27 +++ .../smbdotconf/security/allowtrusteddomains.xml | 26 +++ docs-xml/smbdotconf/security/authmethods.xml | 34 +++ .../smbdotconf/security/checkpasswordscript.xml | 21 ++ docs-xml/smbdotconf/security/clientlanmanauth.xml | 28 +++ docs-xml/smbdotconf/security/clientntlmv2auth.xml | 32 +++ .../smbdotconf/security/clientplaintextauth.xml | 12 + docs-xml/smbdotconf/security/clientschannel.xml | 18 ++ docs-xml/smbdotconf/security/clientsigning.xml | 20 ++ docs-xml/smbdotconf/security/createmask.xml | 43 ++++ docs-xml/smbdotconf/security/directorymask.xml | 38 ++++ .../smbdotconf/security/directorysecuritymask.xml | 39 ++++ docs-xml/smbdotconf/security/encryptpasswords.xml | 40 ++++ docs-xml/smbdotconf/security/forcecreatemode.xml | 25 +++ .../smbdotconf/security/forcedirectorymode.xml | 25 +++ .../security/forcedirectorysecuritymode.xml | 43 ++++ docs-xml/smbdotconf/security/forcegroup.xml | 39 ++++ docs-xml/smbdotconf/security/forcesecuritymode.xml | 41 ++++ .../smbdotconf/security/forceunknownacluser.xml | 27 +++ docs-xml/smbdotconf/security/forceuser.xml | 27 +++ docs-xml/smbdotconf/security/guestaccount.xml | 28 +++ docs-xml/smbdotconf/security/guestok.xml | 20 ++ docs-xml/smbdotconf/security/guestonly.xml | 15 ++ docs-xml/smbdotconf/security/hostsallow.xml | 63 ++++++ docs-xml/smbdotconf/security/hostsdeny.xml | 25 +++ docs-xml/smbdotconf/security/inheritacls.xml | 16 ++ docs-xml/smbdotconf/security/inheritowner.xml | 21 ++ .../smbdotconf/security/inheritpermissions.xml | 35 +++ docs-xml/smbdotconf/security/invalidusers.xml | 34 +++ docs-xml/smbdotconf/security/lanmanauth.xml | 33 +++ docs-xml/smbdotconf/security/maptoguest.xml | 76 +++++++ docs-xml/smbdotconf/security/ntlmauth.xml | 20 ++ docs-xml/smbdotconf/security/nullpasswords.xml | 14 ++ .../smbdotconf/security/obeypamrestrictions.xml | 20 ++ docs-xml/smbdotconf/security/onlyuser.xml | 25 +++ docs-xml/smbdotconf/security/pampasswordchange.xml | 17 ++ docs-xml/smbdotconf/security/passdbbackend.xml | 64 ++++++ .../smbdotconf/security/passdbexpandexplicit.xml | 15 ++ docs-xml/smbdotconf/security/passwdchat.xml | 60 +++++ docs-xml/smbdotconf/security/passwdchatdebug.xml | 27 +++ docs-xml/smbdotconf/security/passwdchattimeout.xml | 14 ++ docs-xml/smbdotconf/security/passwdprogram.xml | 37 +++ docs-xml/smbdotconf/security/passwordlevel.xml | 48 ++++ docs-xml/smbdotconf/security/passwordserver.xml | 99 ++++++++ docs-xml/smbdotconf/security/preloadmodules.xml | 14 ++ docs-xml/smbdotconf/security/printeradmin.xml | 27 +++ docs-xml/smbdotconf/security/privatedir.xml | 14 ++ docs-xml/smbdotconf/security/readlist.xml | 22 ++ docs-xml/smbdotconf/security/readonly.xml | 19 ++ docs-xml/smbdotconf/security/renameuserscript.xml | 33 +++ docs-xml/smbdotconf/security/restrictanonymous.xml | 38 ++++ docs-xml/smbdotconf/security/rootdirectory.xml | 35 +++ docs-xml/smbdotconf/security/security.xml | 250 +++++++++++++++++++++ docs-xml/smbdotconf/security/securitymask.xml | 39 ++++ docs-xml/smbdotconf/security/serverschannel.xml | 23 ++ docs-xml/smbdotconf/security/serversigning.xml | 20 ++ docs-xml/smbdotconf/security/smbencrypt.xml | 45 ++++ docs-xml/smbdotconf/security/smbpasswdfile.xml | 19 ++ docs-xml/smbdotconf/security/unixpasswordsync.xml | 21 ++ docs-xml/smbdotconf/security/updateencrypted.xml | 34 +++ docs-xml/smbdotconf/security/usekerberoskeytab.xml | 23 ++ docs-xml/smbdotconf/security/username.xml | 65 ++++++ docs-xml/smbdotconf/security/usernamelevel.xml | 27 +++ docs-xml/smbdotconf/security/usernamemap.xml | 130 +++++++++++ docs-xml/smbdotconf/security/usernamemapscript.xml | 19 ++ docs-xml/smbdotconf/security/validusers.xml | 28 +++ docs-xml/smbdotconf/security/writeable.xml | 9 + docs-xml/smbdotconf/security/writelist.xml | 29 +++ 70 files changed, 2478 insertions(+) create mode 100644 docs-xml/smbdotconf/security/aclgroupcontrol.xml create mode 100644 docs-xml/smbdotconf/security/adminusers.xml create mode 100644 docs-xml/smbdotconf/security/algorithmicridbase.xml create mode 100644 docs-xml/smbdotconf/security/allowtrusteddomains.xml create mode 100644 docs-xml/smbdotconf/security/authmethods.xml create mode 100644 docs-xml/smbdotconf/security/checkpasswordscript.xml create mode 100644 docs-xml/smbdotconf/security/clientlanmanauth.xml create mode 100644 docs-xml/smbdotconf/security/clientntlmv2auth.xml create mode 100644 docs-xml/smbdotconf/security/clientplaintextauth.xml create mode 100644 docs-xml/smbdotconf/security/clientschannel.xml create mode 100644 docs-xml/smbdotconf/security/clientsigning.xml create mode 100644 docs-xml/smbdotconf/security/createmask.xml create mode 100644 docs-xml/smbdotconf/security/directorymask.xml create mode 100644 docs-xml/smbdotconf/security/directorysecuritymask.xml create mode 100644 docs-xml/smbdotconf/security/encryptpasswords.xml create mode 100644 docs-xml/smbdotconf/security/forcecreatemode.xml create mode 100644 docs-xml/smbdotconf/security/forcedirectorymode.xml create mode 100644 docs-xml/smbdotconf/security/forcedirectorysecuritymode.xml create mode 100644 docs-xml/smbdotconf/security/forcegroup.xml create mode 100644 docs-xml/smbdotconf/security/forcesecuritymode.xml create mode 100644 docs-xml/smbdotconf/security/forceunknownacluser.xml create mode 100644 docs-xml/smbdotconf/security/forceuser.xml create mode 100644 docs-xml/smbdotconf/security/guestaccount.xml create mode 100644 docs-xml/smbdotconf/security/guestok.xml create mode 100644 docs-xml/smbdotconf/security/guestonly.xml create mode 100644 docs-xml/smbdotconf/security/hostsallow.xml create mode 100644 docs-xml/smbdotconf/security/hostsdeny.xml create mode 100644 docs-xml/smbdotconf/security/inheritacls.xml create mode 100644 docs-xml/smbdotconf/security/inheritowner.xml create mode 100644 docs-xml/smbdotconf/security/inheritpermissions.xml create mode 100644 docs-xml/smbdotconf/security/invalidusers.xml create mode 100644 docs-xml/smbdotconf/security/lanmanauth.xml create mode 100644 docs-xml/smbdotconf/security/maptoguest.xml create mode 100644 docs-xml/smbdotconf/security/ntlmauth.xml create mode 100644 docs-xml/smbdotconf/security/nullpasswords.xml create mode 100644 docs-xml/smbdotconf/security/obeypamrestrictions.xml create mode 100644 docs-xml/smbdotconf/security/onlyuser.xml create mode 100644 docs-xml/smbdotconf/security/pampasswordchange.xml create mode 100644 docs-xml/smbdotconf/security/passdbbackend.xml create mode 100644 docs-xml/smbdotconf/security/passdbexpandexplicit.xml create mode 100644 docs-xml/smbdotconf/security/passwdchat.xml create mode 100644 docs-xml/smbdotconf/security/passwdchatdebug.xml create mode 100644 docs-xml/smbdotconf/security/passwdchattimeout.xml create mode 100644 docs-xml/smbdotconf/security/passwdprogram.xml create mode 100644 docs-xml/smbdotconf/security/passwordlevel.xml create mode 100644 docs-xml/smbdotconf/security/passwordserver.xml create mode 100644 docs-xml/smbdotconf/security/preloadmodules.xml create mode 100644 docs-xml/smbdotconf/security/printeradmin.xml create mode 100644 docs-xml/smbdotconf/security/privatedir.xml create mode 100644 docs-xml/smbdotconf/security/readlist.xml create mode 100644 docs-xml/smbdotconf/security/readonly.xml create mode 100644 docs-xml/smbdotconf/security/renameuserscript.xml create mode 100644 docs-xml/smbdotconf/security/restrictanonymous.xml create mode 100644 docs-xml/smbdotconf/security/rootdirectory.xml create mode 100644 docs-xml/smbdotconf/security/security.xml create mode 100644 docs-xml/smbdotconf/security/securitymask.xml create mode 100644 docs-xml/smbdotconf/security/serverschannel.xml create mode 100644 docs-xml/smbdotconf/security/serversigning.xml create mode 100644 docs-xml/smbdotconf/security/smbencrypt.xml create mode 100644 docs-xml/smbdotconf/security/smbpasswdfile.xml create mode 100644 docs-xml/smbdotconf/security/unixpasswordsync.xml create mode 100644 docs-xml/smbdotconf/security/updateencrypted.xml create mode 100644 docs-xml/smbdotconf/security/usekerberoskeytab.xml create mode 100644 docs-xml/smbdotconf/security/username.xml create mode 100644 docs-xml/smbdotconf/security/usernamelevel.xml create mode 100644 docs-xml/smbdotconf/security/usernamemap.xml create mode 100644 docs-xml/smbdotconf/security/usernamemapscript.xml create mode 100644 docs-xml/smbdotconf/security/validusers.xml create mode 100644 docs-xml/smbdotconf/security/writeable.xml create mode 100644 docs-xml/smbdotconf/security/writelist.xml (limited to 'docs-xml/smbdotconf/security') diff --git a/docs-xml/smbdotconf/security/aclgroupcontrol.xml b/docs-xml/smbdotconf/security/aclgroupcontrol.xml new file mode 100644 index 0000000000..e2600ca9da --- /dev/null +++ b/docs-xml/smbdotconf/security/aclgroupcontrol.xml @@ -0,0 +1,43 @@ + + + + In a POSIX filesystem, only the owner of a file or directory and the superuser can modify the permissions + and ACLs on a file. If this parameter is set, then Samba overrides this restriction, and also allows the + primary group owner of a file or directory to modify the permissions and ACLs + on that file. + + + On a Windows server, groups may be the owner of a file or directory - thus allowing anyone in + that group to modify the permissions on it. This allows the delegation of security controls + on a point in the filesystem to the group owner of a directory and anything below it also owned + by that group. This means there are multiple people with permissions to modify ACLs on a file + or directory, easing managability. + + + This parameter allows Samba to also permit delegation of the control over a point in the exported + directory hierarchy in much the same way as Windows. This allows all members of a UNIX group to + control the permissions on a file or directory they have group ownership on. + + + + This parameter is best used with the option and also + on on a share containing directories with the UNIX setgid bit set + on them, which causes new files and directories created within it to inherit the group + ownership from the containing directory. + + + + This is parameter has been marked deprecated in Samba 3.0.23. The same behavior is now + implemented by the dos filemode option. + + + + +inherit owner +inherit permissions + +no + diff --git a/docs-xml/smbdotconf/security/adminusers.xml b/docs-xml/smbdotconf/security/adminusers.xml new file mode 100644 index 0000000000..d8f14b6d74 --- /dev/null +++ b/docs-xml/smbdotconf/security/adminusers.xml @@ -0,0 +1,21 @@ + + + This is a list of users who will be granted + administrative privileges on the share. This means that they + will do all file operations as the super-user (root). + + You should use this option very carefully, as any user in + this list will be able to do anything they like on the share, + irrespective of file permissions. + + This parameter will not work with the share in + Samba 3.0. This is by design. + + + + +jason + diff --git a/docs-xml/smbdotconf/security/algorithmicridbase.xml b/docs-xml/smbdotconf/security/algorithmicridbase.xml new file mode 100644 index 0000000000..24a3150024 --- /dev/null +++ b/docs-xml/smbdotconf/security/algorithmicridbase.xml @@ -0,0 +1,27 @@ + + + This determines how Samba will use its + algorithmic mapping from uids/gid to the RIDs needed to construct + NT Security Identifiers. + + + Setting this option to a larger value could be useful to sites + transitioning from WinNT and Win2k, as existing user and + group rids would otherwise clash with sytem users etc. + + + All UIDs and GIDs must be able to be resolved into SIDs for + the correct operation of ACLs on the server. As such the algorithmic + mapping can't be 'turned off', but pushing it 'out of the way' should + resolve the issues. Users and groups can then be assigned 'low' RIDs + in arbitrary-rid supporting backends. + + + +1000 +100000 + diff --git a/docs-xml/smbdotconf/security/allowtrusteddomains.xml b/docs-xml/smbdotconf/security/allowtrusteddomains.xml new file mode 100644 index 0000000000..57bf1d2422 --- /dev/null +++ b/docs-xml/smbdotconf/security/allowtrusteddomains.xml @@ -0,0 +1,26 @@ + + + + This option only takes effect when the option is set to + server, domain or ads. + If it is set to no, then attempts to connect to a resource from + a domain or workgroup other than the one which smbd is running + in will fail, even if that domain is trusted by the remote server + doing the authentication. + + This is useful if you only want your Samba server to + serve resources to users in the domain it is a member of. As + an example, suppose that there are two domains DOMA and DOMB. DOMB + is trusted by DOMA, which contains the Samba server. Under normal + circumstances, a user with an account in DOMB can then access the + resources of a UNIX account with the same account name on the + Samba server even if they do not have an account in DOMA. This + can make implementing a security boundary difficult. + + +yes + diff --git a/docs-xml/smbdotconf/security/authmethods.xml b/docs-xml/smbdotconf/security/authmethods.xml new file mode 100644 index 0000000000..39d211dbd3 --- /dev/null +++ b/docs-xml/smbdotconf/security/authmethods.xml @@ -0,0 +1,34 @@ + + + + + This option allows the administrator to chose what authentication methods smbd + will use when authenticating a user. This option defaults to sensible values based on . + This should be considered a developer option and used only in rare circumstances. In the majority (if not all) + of production servers, the default setting should be adequate. + + + + Each entry in the list attempts to authenticate the user in turn, until + the user authenticates. In practice only one method will ever actually + be able to complete the authentication. + + + + Possible options include guest (anonymous access), + sam (lookups in local list of accounts based on netbios + name or domain name), winbind (relay authentication requests + for remote users through winbindd), ntdomain (pre-winbindd + method of authentication for remote domain users; deprecated in favour of winbind method), + trustdomain (authenticate trusted users by contacting the + remote DC directly from smbd; deprecated in favour of winbind method). + + + + +guest sam winbind + diff --git a/docs-xml/smbdotconf/security/checkpasswordscript.xml b/docs-xml/smbdotconf/security/checkpasswordscript.xml new file mode 100644 index 0000000000..9169891c29 --- /dev/null +++ b/docs-xml/smbdotconf/security/checkpasswordscript.xml @@ -0,0 +1,21 @@ + + + The name of a program that can be used to check password + complexity. The password is sent to the program's standrad input. + + The program must return 0 on good password any other value otherwise. + In case the password is considered weak (the program do not return 0) the + user will be notified and the password change will fail. + + Note: In the example directory there is a sample program called crackcheck + that uses cracklib to checkpassword quality. + + + +Disabled +check password script = /usr/local/sbin/crackcheck + diff --git a/docs-xml/smbdotconf/security/clientlanmanauth.xml b/docs-xml/smbdotconf/security/clientlanmanauth.xml new file mode 100644 index 0000000000..5266fef6a2 --- /dev/null +++ b/docs-xml/smbdotconf/security/clientlanmanauth.xml @@ -0,0 +1,28 @@ + + + This parameter determines whether or not smbclient + 8 and other samba client + tools will attempt to authenticate itself to servers using the + weaker LANMAN password hash. If disabled, only server which support NT + password hashes (e.g. Windows NT/2000, Samba, etc... but not + Windows 95/98) will be able to be connected from the Samba client. + + The LANMAN encrypted response is easily broken, due to it's + case-insensitive nature, and the choice of algorithm. Clients + without Windows 95/98 servers are advised to disable + this option. + + Disabling this option will also disable the client plaintext auth option + + Likewise, if the client ntlmv2 + auth parameter is enabled, then only NTLMv2 logins will be + attempted. + + +no + diff --git a/docs-xml/smbdotconf/security/clientntlmv2auth.xml b/docs-xml/smbdotconf/security/clientntlmv2auth.xml new file mode 100644 index 0000000000..9f0627abbf --- /dev/null +++ b/docs-xml/smbdotconf/security/clientntlmv2auth.xml @@ -0,0 +1,32 @@ + + + This parameter determines whether or not smbclient + 8 will attempt to + authenticate itself to servers using the NTLMv2 encrypted password + response. + + If enabled, only an NTLMv2 and LMv2 response (both much more + secure than earlier versions) will be sent. Many servers + (including NT4 < SP4, Win9x and Samba 2.2) are not compatible with + NTLMv2. + + Similarly, if enabled, NTLMv1, client lanman auth and client plaintext auth + authentication will be disabled. This also disables share-level + authentication. + + If disabled, an NTLM response (and possibly a LANMAN response) + will be sent by the client, depending on the value of client lanman auth. + + Note that some sites (particularly + those following 'best practice' security polices) only allow NTLMv2 + responses, and not the weaker LM or NTLM. + +no + diff --git a/docs-xml/smbdotconf/security/clientplaintextauth.xml b/docs-xml/smbdotconf/security/clientplaintextauth.xml new file mode 100644 index 0000000000..c4061559db --- /dev/null +++ b/docs-xml/smbdotconf/security/clientplaintextauth.xml @@ -0,0 +1,12 @@ + + + Specifies whether a client should send a plaintext + password if the server does not support encrypted passwords. + +no + + diff --git a/docs-xml/smbdotconf/security/clientschannel.xml b/docs-xml/smbdotconf/security/clientschannel.xml new file mode 100644 index 0000000000..e229182f97 --- /dev/null +++ b/docs-xml/smbdotconf/security/clientschannel.xml @@ -0,0 +1,18 @@ + + + + + This controls whether the client offers or even demands the use of the netlogon schannel. + no does not offer the schannel, + auto offers the schannel but does not + enforce it, and yes denies access + if the server is not able to speak netlogon schannel. + + +auto +yes + diff --git a/docs-xml/smbdotconf/security/clientsigning.xml b/docs-xml/smbdotconf/security/clientsigning.xml new file mode 100644 index 0000000000..bf37cbb874 --- /dev/null +++ b/docs-xml/smbdotconf/security/clientsigning.xml @@ -0,0 +1,20 @@ + + + This controls whether the client offers or requires + the server it talks to to use SMB signing. Possible values + are auto, mandatory + and disabled. + + + When set to auto, SMB signing is offered, but not enforced. + When set to mandatory, SMB signing is required and if set + to disabled, SMB signing is not offered either. + + + +auto + diff --git a/docs-xml/smbdotconf/security/createmask.xml b/docs-xml/smbdotconf/security/createmask.xml new file mode 100644 index 0000000000..cf6864c78e --- /dev/null +++ b/docs-xml/smbdotconf/security/createmask.xml @@ -0,0 +1,43 @@ + + +create mode + + + When a file is created, the necessary permissions are calculated according to the mapping from DOS modes to + UNIX permissions, and the resulting UNIX mode is then bit-wise 'AND'ed with this parameter. This parameter may + be thought of as a bit-wise MASK for the UNIX modes of a file. Any bit not set here will + be removed from the modes set on a file when it is created. + + + + The default value of this parameter removes the group and other + write and execute bits from the UNIX modes. + + + + Following this Samba will bit-wise 'OR' the UNIX mode created from this parameter with the value of the + parameter which is set to 000 by default. + + + + This parameter does not affect directory masks. See the parameter + for details. + + + + Note that this parameter does not apply to permissions set by Windows NT/2000 ACL editors. If the + administrator wishes to enforce a mask on access control lists also, they need to set the . + + + +force create mode +directory mode +inherit permissions + +0744 +0775 + diff --git a/docs-xml/smbdotconf/security/directorymask.xml b/docs-xml/smbdotconf/security/directorymask.xml new file mode 100644 index 0000000000..7b67f79214 --- /dev/null +++ b/docs-xml/smbdotconf/security/directorymask.xml @@ -0,0 +1,38 @@ + +directory mode + + This parameter is the octal modes which are + used when converting DOS modes to UNIX modes when creating UNIX + directories. + + When a directory is created, the necessary permissions are + calculated according to the mapping from DOS modes to UNIX permissions, + and the resulting UNIX mode is then bit-wise 'AND'ed with this + parameter. This parameter may be thought of as a bit-wise MASK for + the UNIX modes of a directory. Any bit not set + here will be removed from the modes set on a directory when it is + created. + + The default value of this parameter removes the 'group' + and 'other' write bits from the UNIX mode, allowing only the + user who owns the directory to modify it. + + Following this Samba will bit-wise 'OR' the UNIX mode + created from this parameter with the value of the parameter. + This parameter is set to 000 by default (i.e. no extra mode bits are added). + + Note that this parameter does not apply to permissions + set by Windows NT/2000 ACL editors. If the administrator wishes to enforce + a mask on access control lists also, they need to set the . + + +force directory mode +create mask +directory security mask +inherit permissions +0755 +0775 + diff --git a/docs-xml/smbdotconf/security/directorysecuritymask.xml b/docs-xml/smbdotconf/security/directorysecuritymask.xml new file mode 100644 index 0000000000..5ed85ae3f8 --- /dev/null +++ b/docs-xml/smbdotconf/security/directorysecuritymask.xml @@ -0,0 +1,39 @@ + + + This parameter controls what UNIX permission bits + will be set when a Windows NT client is manipulating the UNIX + permission on a directory using the native NT security dialog + box. + + + This parameter is applied as a mask (AND'ed with) to the incoming permission bits, thus resetting + any bits not in this mask. Make sure not to mix up this parameter with , which works similar like this one but uses logical OR instead of AND. + Essentially, zero bits in this mask are a set of bits that will always be set to zero. + + + + Essentially, all bits set to zero in this mask will result in setting to zero the corresponding bits on the + file permissions regardless of the previous status of this bits on the file. + + + If not set explicitly this parameter is set to 0777 + meaning a user is allowed to set all the user/group/world + permissions on a directory. + + Note that users who can access the + Samba server through other means can easily bypass this restriction, + so it is primarily useful for standalone "appliance" systems. + Administrators of most normal systems will probably want to leave + it as the default of 0777. + + +force directory security mode +security mask +force security mode +0777 +0700 + diff --git a/docs-xml/smbdotconf/security/encryptpasswords.xml b/docs-xml/smbdotconf/security/encryptpasswords.xml new file mode 100644 index 0000000000..1a631fd098 --- /dev/null +++ b/docs-xml/smbdotconf/security/encryptpasswords.xml @@ -0,0 +1,40 @@ + + + This boolean controls whether encrypted passwords + will be negotiated with the client. Note that Windows NT 4.0 SP3 and + above and also Windows 98 will by default expect encrypted passwords + unless a registry entry is changed. To use encrypted passwords in + Samba see the chapter "User Database" in the Samba HOWTO Collection. + + + + MS Windows clients that expect Microsoft encrypted passwords and that + do not have plain text password support enabled will be able to + connect only to a Samba server that has encrypted password support + enabled and for which the user accounts have a valid encrypted password. + Refer to the smbpasswd command man page for information regarding the + creation of encrypted passwords for user accounts. + + + + The use of plain text passwords is NOT advised as support for this feature + is no longer maintained in Microsoft Windows products. If you want to use + plain text passwords you must set this parameter to no. + + + In order for encrypted passwords to work correctly + smbd + 8 must either + have access to a local smbpasswd + 5 file (see the smbpasswd + 8 program for information on how to set up + and maintain this file), or set the [server|domain|ads] parameter which + causes smbd to authenticate against another + server. + +yes + diff --git a/docs-xml/smbdotconf/security/forcecreatemode.xml b/docs-xml/smbdotconf/security/forcecreatemode.xml new file mode 100644 index 0000000000..8a6449fe21 --- /dev/null +++ b/docs-xml/smbdotconf/security/forcecreatemode.xml @@ -0,0 +1,25 @@ + + + This parameter specifies a set of UNIX mode bit + permissions that will always be set on a + file created by Samba. This is done by bitwise 'OR'ing these bits onto + the mode bits of a file that is being created or having its + permissions changed. The default for this parameter is (in octal) + 000. The modes in this parameter are bitwise 'OR'ed onto the file + mode after the mask set in the create mask + parameter is applied. + + The example below would force all created files to have read and execute + permissions set for 'group' and 'other' as well as the + read/write/execute bits set for the 'user'. + + + +create mask +inherit permissions + +000 +0755 + diff --git a/docs-xml/smbdotconf/security/forcedirectorymode.xml b/docs-xml/smbdotconf/security/forcedirectorymode.xml new file mode 100644 index 0000000000..7effc0e399 --- /dev/null +++ b/docs-xml/smbdotconf/security/forcedirectorymode.xml @@ -0,0 +1,25 @@ + + + This parameter specifies a set of UNIX mode bit + permissions that will always be set on a directory + created by Samba. This is done by bitwise 'OR'ing these bits onto the + mode bits of a directory that is being created. The default for this + parameter is (in octal) 0000 which will not add any extra permission + bits to a created directory. This operation is done after the mode + mask in the parameter directory mask is + applied. + + The example below would force all created directories to have read and execute + permissions set for 'group' and 'other' as well as the + read/write/execute bits set for the 'user'. + + +000 +0755 + +directory mask +inherit permissions + diff --git a/docs-xml/smbdotconf/security/forcedirectorysecuritymode.xml b/docs-xml/smbdotconf/security/forcedirectorysecuritymode.xml new file mode 100644 index 0000000000..2c15ec2753 --- /dev/null +++ b/docs-xml/smbdotconf/security/forcedirectorysecuritymode.xml @@ -0,0 +1,43 @@ + + + + This parameter controls what UNIX permission bits can be modified when a Windows NT client is manipulating + the UNIX permission on a directory using the native NT security dialog box. + + + + This parameter is applied as a mask (OR'ed with) to the changed permission bits, thus forcing any bits in this + mask that the user may have modified to be on. Make sure not to mix up this parameter with , which works in a similar manner to this one, but uses a logical AND instead + of an OR. + + + + Essentially, this mask may be treated as a set of bits that, when modifying security on a directory, + to will enable (1) any flags that are off (0) but which the mask has set to on (1). + + + + If not set explicitly this parameter is 0000, which allows a user to modify all the user/group/world + permissions on a directory without restrictions. + + + + Users who can access the Samba server through other means can easily bypass this restriction, so it is + primarily useful for standalone "appliance" systems. Administrators of most normal systems will + probably want to leave it set as 0000. + + + + +0 +700 + +directory security mask +security mask +force security mode + + diff --git a/docs-xml/smbdotconf/security/forcegroup.xml b/docs-xml/smbdotconf/security/forcegroup.xml new file mode 100644 index 0000000000..f6c9974f99 --- /dev/null +++ b/docs-xml/smbdotconf/security/forcegroup.xml @@ -0,0 +1,39 @@ + +group + + This specifies a UNIX group name that will be + assigned as the default primary group for all users connecting + to this service. This is useful for sharing files by ensuring + that all access to files on service will use the named group for + their permissions checking. Thus, by assigning permissions for this + group to the files and directories within this service the Samba + administrator can restrict or allow sharing of these files. + + In Samba 2.0.5 and above this parameter has extended + functionality in the following way. If the group name listed here + has a '+' character prepended to it then the current user accessing + the share only has the primary group default assigned to this group + if they are already assigned as a member of that group. This allows + an administrator to decide that only users who are already in a + particular group will create files with group ownership set to that + group. This gives a finer granularity of ownership assignment. For + example, the setting force group = +sys means + that only users who are already in group sys will have their default + primary group assigned to sys when accessing this Samba share. All + other users will retain their ordinary primary group. + + + If the parameter is also set the group specified in + force group will override the primary group + set in force user. + + + +force user + + +agroup + diff --git a/docs-xml/smbdotconf/security/forcesecuritymode.xml b/docs-xml/smbdotconf/security/forcesecuritymode.xml new file mode 100644 index 0000000000..7451ef91ae --- /dev/null +++ b/docs-xml/smbdotconf/security/forcesecuritymode.xml @@ -0,0 +1,41 @@ + + + + This parameter controls what UNIX permission bits can be modified when a Windows NT client is manipulating + the UNIX permission on a file using the native NT security dialog box. + + + + This parameter is applied as a mask (OR'ed with) to the changed permission bits, thus forcing any bits in this + mask that the user may have modified to be on. Make sure not to mix up this parameter with , which works similar like this one but uses logical AND instead of OR. + + + + Essentially, one bits in this mask may be treated as a set of bits that, when modifying security on a file, + the user has always set to be on. + + + + If not set explicitly this parameter is set to 0, and allows a user to modify all the user/group/world + permissions on a file, with no restrictions. + + + + Note that users who can access the Samba server through other means can easily bypass this + restriction, so it is primarily useful for standalone "appliance" systems. Administrators of most + normal systems will probably want to leave this set to 0000. + + + + +0 +700 + +force directory security mode +directory security mask +security mask + diff --git a/docs-xml/smbdotconf/security/forceunknownacluser.xml b/docs-xml/smbdotconf/security/forceunknownacluser.xml new file mode 100644 index 0000000000..4c0949f052 --- /dev/null +++ b/docs-xml/smbdotconf/security/forceunknownacluser.xml @@ -0,0 +1,27 @@ + + + + + If this parameter is set, a Windows NT ACL that contains an unknown SID (security descriptor, or + representation of a user or group id) as the owner or group owner of the file will be silently + mapped into the current UNIX uid or gid of the currently connected user. + + + + This is designed to allow Windows NT clients to copy files and folders containing ACLs that were + created locally on the client machine and contain users local to that machine only (no domain + users) to be copied to a Samba server (usually with XCOPY /O) and have the unknown userid and + groupid of the file owner map to the current connected user. This can only be fixed correctly + when winbindd allows arbitrary mapping from any Windows NT SID to a UNIX uid or gid. + + + + Try using this parameter when XCOPY /O gives an ACCESS_DENIED error. + + + +no + diff --git a/docs-xml/smbdotconf/security/forceuser.xml b/docs-xml/smbdotconf/security/forceuser.xml new file mode 100644 index 0000000000..f1ec5d449c --- /dev/null +++ b/docs-xml/smbdotconf/security/forceuser.xml @@ -0,0 +1,27 @@ + + + This specifies a UNIX user name that will be + assigned as the default user for all users connecting to this service. + This is useful for sharing files. You should also use it carefully + as using it incorrectly can cause security problems. + + This user name only gets used once a connection is established. + Thus clients still need to connect as a valid user and supply a + valid password. Once connected, all file operations will be performed + as the "forced user", no matter what username the client connected + as. This can be very useful. + + In Samba 2.0.5 and above this parameter also causes the + primary group of the forced user to be used as the primary group + for all file activity. Prior to 2.0.5 the primary group was left + as the primary group of the connecting user (this was a bug). + + + +force group + +auser + diff --git a/docs-xml/smbdotconf/security/guestaccount.xml b/docs-xml/smbdotconf/security/guestaccount.xml new file mode 100644 index 0000000000..8132835a82 --- /dev/null +++ b/docs-xml/smbdotconf/security/guestaccount.xml @@ -0,0 +1,28 @@ + + + This is a username which will be used for access + to services which are specified as (see below). Whatever privileges this + user has will be available to any client connecting to the guest service. + This user must exist in the password file, but does not require + a valid login. The user account "ftp" is often a good choice + for this parameter. + + + On some systems the default guest account "nobody" may not + be able to print. Use another account in this case. You should test + this by trying to log in as your guest user (perhaps by using the + su - command) and trying to print using the + system print command such as lpr(1) or + lp(1). + + This parameter does not accept % macros, because + many parts of the system require this value to be + constant for correct operation. + +nobodydefault can be changed at compile-time +ftp + diff --git a/docs-xml/smbdotconf/security/guestok.xml b/docs-xml/smbdotconf/security/guestok.xml new file mode 100644 index 0000000000..7cbf4e50bb --- /dev/null +++ b/docs-xml/smbdotconf/security/guestok.xml @@ -0,0 +1,20 @@ + +public + + If this parameter is yes for + a service, then no password is required to connect to the service. + Privileges will be those of the . + + This paramater nullifies the benifits of setting + 2 + + + See the section below on for more information about this option. + + +no + diff --git a/docs-xml/smbdotconf/security/guestonly.xml b/docs-xml/smbdotconf/security/guestonly.xml new file mode 100644 index 0000000000..258eba9267 --- /dev/null +++ b/docs-xml/smbdotconf/security/guestonly.xml @@ -0,0 +1,15 @@ + +only guest + + If this parameter is yes for + a service, then only guest connections to the service are permitted. + This parameter will have no effect if is not set for the service. + + See the section below on for more information about this option. + + +no + diff --git a/docs-xml/smbdotconf/security/hostsallow.xml b/docs-xml/smbdotconf/security/hostsallow.xml new file mode 100644 index 0000000000..849b515f46 --- /dev/null +++ b/docs-xml/smbdotconf/security/hostsallow.xml @@ -0,0 +1,63 @@ + +allow hosts + + A synonym for this parameter is . + + This parameter is a comma, space, or tab delimited + set of hosts which are permitted to access a service. + + If specified in the [global] section then it will + apply to all services, regardless of whether the individual + service has a different setting. + + You can specify the hosts by name or IP number. For + example, you could restrict access to only the hosts on a + Class C subnet with something like allow hosts = 150.203.5.. + The full syntax of the list is described in the man + page hosts_access(5). Note that this man + page may not be present on your system, so a brief description will + be given here also. + + Note that the localhost address 127.0.0.1 will always + be allowed access unless specifically denied by a option. + + You can also specify hosts by network/netmask pairs and + by netgroup names if your system supports netgroups. The + EXCEPT keyword can also be used to limit a + wildcard list. The following examples may provide some help: + +Example 1: allow all IPs in 150.203.*.*; except one + + hosts allow = 150.203. EXCEPT 150.203.6.66 + + Example 2: allow hosts that match the given network/netmask + + hosts allow = 150.203.15.0/255.255.255.0 + + Example 3: allow a couple of hosts + + hosts allow = lapland, arvidsjaur + + Example 4: allow only hosts in NIS netgroup "foonet", but + deny access from one particular host + + hosts allow = @foonet + + hosts deny = pirate + + Note that access still requires suitable user-level passwords. + + See testparm + 1 for a way of testing your host access + to see if it does what you expect. + + + + +150.203.5. myhost.mynet.edu.au +none (i.e., all hosts permitted access) + diff --git a/docs-xml/smbdotconf/security/hostsdeny.xml b/docs-xml/smbdotconf/security/hostsdeny.xml new file mode 100644 index 0000000000..136f86c9c8 --- /dev/null +++ b/docs-xml/smbdotconf/security/hostsdeny.xml @@ -0,0 +1,25 @@ + +deny hosts + + The opposite of hosts allow + - hosts listed here are NOT permitted access to + services unless the specific services have their own lists to override + this one. Where the lists conflict, the allow + list takes precedence. + + + In the event that it is necessary to deny all by default, use the keyword + ALL (or the netmask 0.0.0.0/0) and then explicitly specify + to the hosts allow parameter those hosts + that should be permitted access. + + + +none (i.e., no hosts specifically excluded) + +150.203.4. badhost.mynet.edu.au + diff --git a/docs-xml/smbdotconf/security/inheritacls.xml b/docs-xml/smbdotconf/security/inheritacls.xml new file mode 100644 index 0000000000..44afa8a3e2 --- /dev/null +++ b/docs-xml/smbdotconf/security/inheritacls.xml @@ -0,0 +1,16 @@ + + + This parameter can be used to ensure that if default acls + exist on parent directories, they are always honored when creating a + new file or subdirectory in these parent directories. The default + behavior is to use the unix mode specified when creating the directory. + Enabling this option sets the unix mode to 0777, thus guaranteeing that + default directory acls are propagated. + + + +no + diff --git a/docs-xml/smbdotconf/security/inheritowner.xml b/docs-xml/smbdotconf/security/inheritowner.xml new file mode 100644 index 0000000000..ba4fc617cb --- /dev/null +++ b/docs-xml/smbdotconf/security/inheritowner.xml @@ -0,0 +1,21 @@ + + + The ownership of new files and directories + is normally governed by effective uid of the connected user. + This option allows the Samba administrator to specify that + the ownership for new files and directories should be controlled + by the ownership of the parent directory. + + Common scenarios where this behavior is useful is in + implementing drop-boxes where users can create and edit files but not + delete them and to ensure that newly create files in a user's + roaming profile directory are actually owner by the user. + + +inherit permissions + +no + diff --git a/docs-xml/smbdotconf/security/inheritpermissions.xml b/docs-xml/smbdotconf/security/inheritpermissions.xml new file mode 100644 index 0000000000..6e09f4f033 --- /dev/null +++ b/docs-xml/smbdotconf/security/inheritpermissions.xml @@ -0,0 +1,35 @@ + + + + The permissions on new files and directories are normally governed by , + , and but the boolean inherit permissions parameter overrides this. + + + New directories inherit the mode of the parent directory, + including bits such as setgid. + + + New files inherit their read/write bits from the parent directory. Their execute bits continue to be + determined by , and as usual. + + + Note that the setuid bit is never set via + inheritance (the code explicitly prohibits this). + + This can be particularly useful on large systems with + many users, perhaps several thousand, to allow a single [homes] + share to be used flexibly by each user. + + +create mask +directory mask +force create mode +force directory mode + +no + diff --git a/docs-xml/smbdotconf/security/invalidusers.xml b/docs-xml/smbdotconf/security/invalidusers.xml new file mode 100644 index 0000000000..f4ed66f314 --- /dev/null +++ b/docs-xml/smbdotconf/security/invalidusers.xml @@ -0,0 +1,34 @@ + + + This is a list of users that should not be allowed + to login to this service. This is really a paranoid + check to absolutely ensure an improper setting does not breach + your security. + + A name starting with a '@' is interpreted as an NIS + netgroup first (if your system supports NIS), and then as a UNIX + group if the name was not found in the NIS netgroup database. + + A name starting with '+' is interpreted only + by looking in the UNIX group database via the NSS getgrnam() interface. A name starting with + '&' is interpreted only by looking in the NIS netgroup database + (this requires NIS to be working on your system). The characters + '+' and '&' may be used at the start of the name in either order + so the value +&group means check the + UNIX group database, followed by the NIS netgroup database, and + the value &+group means check the NIS + netgroup database, followed by the UNIX group database (the + same as the '@' prefix). + + The current servicename is substituted for %S. + This is useful in the [homes] section. + + +valid users + +no invalid users +root fred admin @wheel + diff --git a/docs-xml/smbdotconf/security/lanmanauth.xml b/docs-xml/smbdotconf/security/lanmanauth.xml new file mode 100644 index 0000000000..341952205f --- /dev/null +++ b/docs-xml/smbdotconf/security/lanmanauth.xml @@ -0,0 +1,33 @@ + + + This parameter determines whether or not smbd + 8 will attempt to + authenticate users or permit password changes + using the LANMAN password hash. If disabled, only clients which support NT + password hashes (e.g. Windows NT/2000 clients, smbclient, but not + Windows 95/98 or the MS DOS network client) will be able to + connect to the Samba host. + + The LANMAN encrypted response is easily broken, due to it's + case-insensitive nature, and the choice of algorithm. Servers + without Windows 95/98/ME or MS DOS clients are advised to disable + this option. + + Unlike the encrypt + passwords option, this parameter cannot alter client + behaviour, and the LANMAN response will still be sent over the + network. See the client lanman + auth to disable this for Samba's clients (such as smbclient) + + If this option, and ntlm + auth are both disabled, then only NTLMv2 logins will be + permited. Not all clients support NTLMv2, and most will require + special configuration to use it. + + +no + diff --git a/docs-xml/smbdotconf/security/maptoguest.xml b/docs-xml/smbdotconf/security/maptoguest.xml new file mode 100644 index 0000000000..0f680ae71c --- /dev/null +++ b/docs-xml/smbdotconf/security/maptoguest.xml @@ -0,0 +1,76 @@ + + + This parameter is only useful in + security modes other than security = share + and security = server + - i.e. user, and domain. + + This parameter can take four different values, which tell + smbd + 8 what to do with user + login requests that don't match a valid UNIX user in some way. + + The four settings are : + + + + Never - Means user login + requests with an invalid password are rejected. This is the + default. + + + + Bad User - Means user + logins with an invalid password are rejected, unless the username + does not exist, in which case it is treated as a guest login and + mapped into the . + + + + Bad Password - Means user logins + with an invalid password are treated as a guest login and mapped + into the . Note that + this can cause problems as it means that any user incorrectly typing + their password will be silently logged on as "guest" - and + will not know the reason they cannot access files they think + they should - there will have been no message given to them + that they got their password wrong. Helpdesk services will + hate you if you set the map to + guest parameter this way :-). + + + Bad Uid - Is only applicable when Samba is configured + in some type of domain mode security (security = {domain|ads}) and means that + user logins which are successfully authenticated but which have no valid Unix + user account (and smbd is unable to create one) should be mapped to the defined + guest account. This was the default behavior of Samba 2.x releases. Note that + if a member server is running winbindd, this option should never be required + because the nss_winbind library will export the Windows domain users and groups + to the underlying OS via the Name Service Switch interface. + + + + Note that this parameter is needed to set up "Guest" + share services when using security modes other than + share and server. This is because in these modes the name of the resource being + requested is not sent to the server until after + the server has successfully authenticated the client so the server + cannot make authentication decisions at the correct time (connection + to the share) for "Guest" shares. This parameter is not useful with + security = server as in this security mode + no information is returned about whether a user logon failed due to + a bad username or bad password, the same error is returned from a modern server + in both cases. + + For people familiar with the older Samba releases, this + parameter maps to the old compile-time setting of the + GUEST_SESSSETUP value in local.h. + + +Never +Bad User + diff --git a/docs-xml/smbdotconf/security/ntlmauth.xml b/docs-xml/smbdotconf/security/ntlmauth.xml new file mode 100644 index 0000000000..ebcdad72a1 --- /dev/null +++ b/docs-xml/smbdotconf/security/ntlmauth.xml @@ -0,0 +1,20 @@ + + + This parameter determines whether or not smbd + 8 will attempt to + authenticate users using the NTLM encrypted password response. + If disabled, either the lanman password hash or an NTLMv2 response + will need to be sent by the client. + + If this option, and lanman + auth are both disabled, then only NTLMv2 logins will be + permited. Not all clients support NTLMv2, and most will require + special configuration to us it. + + +yes + diff --git a/docs-xml/smbdotconf/security/nullpasswords.xml b/docs-xml/smbdotconf/security/nullpasswords.xml new file mode 100644 index 0000000000..402114e259 --- /dev/null +++ b/docs-xml/smbdotconf/security/nullpasswords.xml @@ -0,0 +1,14 @@ + + + Allow or disallow client access to accounts that have null passwords. + + See also smbpasswd + 5. + + +no + diff --git a/docs-xml/smbdotconf/security/obeypamrestrictions.xml b/docs-xml/smbdotconf/security/obeypamrestrictions.xml new file mode 100644 index 0000000000..40777f4f5d --- /dev/null +++ b/docs-xml/smbdotconf/security/obeypamrestrictions.xml @@ -0,0 +1,20 @@ + + + When Samba 3.0 is configured to enable PAM support + (i.e. --with-pam), this parameter will control whether or not Samba + should obey PAM's account and session management directives. The + default behavior is to use PAM for clear text authentication only + and to ignore any account or session management. Note that Samba + always ignores PAM for authentication in the case of yes. The reason + is that PAM modules cannot support the challenge/response + authentication mechanism needed in the presence of SMB password encryption. + + + +no + diff --git a/docs-xml/smbdotconf/security/onlyuser.xml b/docs-xml/smbdotconf/security/onlyuser.xml new file mode 100644 index 0000000000..b1ef1b7606 --- /dev/null +++ b/docs-xml/smbdotconf/security/onlyuser.xml @@ -0,0 +1,25 @@ + + + This is a boolean option that controls whether + connections with usernames not in the user + list will be allowed. By default this option is disabled so that a + client can supply a username to be used by the server. Enabling + this parameter will force the server to only use the login + names from the user list and is only really + useful in share level security. + + Note that this also means Samba won't try to deduce + usernames from the service name. This can be annoying for + the [homes] section. To get around this you could use user = + %S which means your user list + will be just the service name, which for home directories is the + name of the user. + + +user + +no + diff --git a/docs-xml/smbdotconf/security/pampasswordchange.xml b/docs-xml/smbdotconf/security/pampasswordchange.xml new file mode 100644 index 0000000000..e5c04d405c --- /dev/null +++ b/docs-xml/smbdotconf/security/pampasswordchange.xml @@ -0,0 +1,17 @@ + + + With the addition of better PAM support in Samba 2.2, + this parameter, it is possible to use PAM's password change control + flag for Samba. If enabled, then PAM will be used for password + changes when requested by an SMB client instead of the program listed in + . + It should be possible to enable this without changing your + parameter for most setups. + + +no + diff --git a/docs-xml/smbdotconf/security/passdbbackend.xml b/docs-xml/smbdotconf/security/passdbbackend.xml new file mode 100644 index 0000000000..487d8b8a9d --- /dev/null +++ b/docs-xml/smbdotconf/security/passdbbackend.xml @@ -0,0 +1,64 @@ + + + + This option allows the administrator to chose which backend + will be used for storing user and possibly group information. This allows + you to swap between different storage mechanisms without recompile. + + The parameter value is divided into two parts, the backend's name, and a 'location' + string that has meaning only to that particular backed. These are separated + by a : character. + + Available backends can include: + + + smbpasswd - The default smbpasswd + backend. Takes a path to the smbpasswd file as an optional argument. + + + + + tdbsam - The TDB based password storage + backend. Takes a path to the TDB as an optional argument (defaults to passdb.tdb + in the directory. + + + + ldapsam - The LDAP based passdb + backend. Takes an LDAP URL as an optional argument (defaults to + ldap://localhost) + + LDAP connections should be secured where possible. This may be done using either + Start-TLS (see ) or by + specifying ldaps:// in + the URL argument. + + Multiple servers may also be specified in double-quotes. + Whether multiple servers are supported or not and the exact + syntax depends on the LDAP library you use. + + + + + + + Examples of use are: + +passdb backend = tdbsam:/etc/samba/private/passdb.tdb + +or multi server LDAP URL with OpenLDAP library: + +passdb backend = ldapsam:"ldap://ldap-1.example.com ldap://ldap-2.example.com" + +or multi server LDAP URL with Netscape based LDAP library: + +passdb backend = ldapsam:"ldap://ldap-1.example.com ldap-2.example.com" + + + +smbpasswd + diff --git a/docs-xml/smbdotconf/security/passdbexpandexplicit.xml b/docs-xml/smbdotconf/security/passdbexpandexplicit.xml new file mode 100644 index 0000000000..08c893191a --- /dev/null +++ b/docs-xml/smbdotconf/security/passdbexpandexplicit.xml @@ -0,0 +1,15 @@ + + + + This parameter controls whether Samba substitutes %-macros in the passdb fields if they are explicitly set. We + used to expand macros here, but this turned out to be a bug because the Windows client can expand a variable + %G_osver% in which %G would have been substituted by the user's primary group. + + + +no + diff --git a/docs-xml/smbdotconf/security/passwdchat.xml b/docs-xml/smbdotconf/security/passwdchat.xml new file mode 100644 index 0000000000..da18142dfa --- /dev/null +++ b/docs-xml/smbdotconf/security/passwdchat.xml @@ -0,0 +1,60 @@ + + + This string controls the "chat" + conversation that takes places between smbd + 8 and the local password changing + program to change the user's password. The string describes a + sequence of response-receive pairs that smbd + 8 uses to determine what to send to the + and what to expect back. If the expected output is not + received then the password is not changed. + + This chat sequence is often quite site specific, depending + on what local methods are used for password control (such as NIS + etc). + + Note that this parameter only is only used if the parameter is set to yes. This sequence is + then called AS ROOT when the SMB password in the + smbpasswd file is being changed, without access to the old password + cleartext. This means that root must be able to reset the user's password without + knowing the text of the previous password. In the presence of + NIS/YP, this means that the must + be executed on the NIS master. + + + The string can contain the macro %n which is substituted + for the new password. The old passsword (%o) is only available when + has been disabled. + The chat sequence can also contain the standard macros + \n, \r, \t and \s to give line-feed, carriage-return, tab + and space. The chat sequence string can also contain + a '*' which matches any sequence of characters. Double quotes can + be used to collect strings with spaces in them into a single + string. + + If the send string in any part of the chat sequence is a full + stop ".", then no string is sent. Similarly, if the + expect string is a full stop then no string is expected. + + If the parameter is set to yes, the + chat pairs may be matched in any order, and success is determined by the PAM result, not any particular + output. The \n macro is ignored for PAM conversions. + + + + +unix password sync +passwd program +passwd chat debug +pam password change + +*new*password* %n\n*new*password* %n\n *changed* +"*Enter NEW password*" %n\n "*Reenter NEW password*" %n\n "*Password changed*" + diff --git a/docs-xml/smbdotconf/security/passwdchatdebug.xml b/docs-xml/smbdotconf/security/passwdchatdebug.xml new file mode 100644 index 0000000000..24bcbdba10 --- /dev/null +++ b/docs-xml/smbdotconf/security/passwdchatdebug.xml @@ -0,0 +1,27 @@ + + + This boolean specifies if the passwd chat script + parameter is run in debug mode. In this mode the + strings passed to and received from the passwd chat are printed + in the smbd + 8 log with a + + of 100. This is a dangerous option as it will allow plaintext passwords + to be seen in the smbd log. It is available to help + Samba admins debug their passwd chat scripts + when calling the passwd program and should + be turned off after this has been done. This option has no effect if the + + parameter is set. This parameter is off by default. + + +passwd chat +pam password change +passwd program + +no + diff --git a/docs-xml/smbdotconf/security/passwdchattimeout.xml b/docs-xml/smbdotconf/security/passwdchattimeout.xml new file mode 100644 index 0000000000..c371aa2c88 --- /dev/null +++ b/docs-xml/smbdotconf/security/passwdchattimeout.xml @@ -0,0 +1,14 @@ + + + This integer specifies the number of seconds smbd will wait for an initial + answer from a passwd chat script being run. Once the initial answer is received + the subsequent answers must be received in one tenth of this time. The default it + two seconds. + + +2 + diff --git a/docs-xml/smbdotconf/security/passwdprogram.xml b/docs-xml/smbdotconf/security/passwdprogram.xml new file mode 100644 index 0000000000..4158c1b7a6 --- /dev/null +++ b/docs-xml/smbdotconf/security/passwdprogram.xml @@ -0,0 +1,37 @@ + + + The name of a program that can be used to set + UNIX user passwords. Any occurrences of %u + will be replaced with the user name. The user name is checked for + existence before calling the password changing program. + + Also note that many passwd programs insist in reasonable + passwords, such as a minimum length, or the inclusion + of mixed case chars and digits. This can pose a problem as some clients + (such as Windows for Workgroups) uppercase the password before sending + it. + + Note that if the unix + password sync parameter is set to yes + then this program is called AS ROOT + before the SMB password in the smbpasswd + file is changed. If this UNIX password change fails, then + smbd will fail to change the SMB password also + (this is by design). + + If the unix password sync parameter + is set this parameter MUST USE ABSOLUTE PATHS + for ALL programs called, and must be examined + for security implications. Note that by default unix + password sync is set to no. + + + unix password symc + + +/bin/passwd %u + diff --git a/docs-xml/smbdotconf/security/passwordlevel.xml b/docs-xml/smbdotconf/security/passwordlevel.xml new file mode 100644 index 0000000000..1da11e406b --- /dev/null +++ b/docs-xml/smbdotconf/security/passwordlevel.xml @@ -0,0 +1,48 @@ + + + Some client/server combinations have difficulty + with mixed-case passwords. One offending client is Windows for + Workgroups, which for some reason forces passwords to upper + case when using the LANMAN1 protocol, but leaves them alone when + using COREPLUS! Another problem child is the Windows 95/98 + family of operating systems. These clients upper case clear + text passwords even when NT LM 0.12 selected by the protocol + negotiation request/response. + + This parameter defines the maximum number of characters + that may be upper case in passwords. + + For example, say the password given was "FRED". If + password level is set to 1, the following combinations + would be tried if "FRED" failed: + + "Fred", "fred", "fRed", "frEd","freD" + + If password level was set to 2, + the following combinations would also be tried: + + "FRed", "FrEd", "FreD", "fREd", "fReD", "frED", .. + + And so on. + + The higher value this parameter is set to the more likely + it is that a mixed case password will be matched against a single + case password. However, you should be aware that use of this + parameter reduces security and increases the time taken to + process a new connection. + + A value of zero will cause only two attempts to be + made - the password as is and the password in all-lower case. + + This parameter is used only when using plain-text passwords. It is + not at all used when encrypted passwords as in use (that is the default + since samba-3.0.0). Use this only when No. + + +0 +4 + diff --git a/docs-xml/smbdotconf/security/passwordserver.xml b/docs-xml/smbdotconf/security/passwordserver.xml new file mode 100644 index 0000000000..188cea88d1 --- /dev/null +++ b/docs-xml/smbdotconf/security/passwordserver.xml @@ -0,0 +1,99 @@ + + + By specifying the name of another SMB server + or Active Directory domain controller with this option, + and using security = [ads|domain|server] + it is possible to get Samba to + to do all its username/password validation using a specific remote server. + + 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. + + If parameter is a name, it is looked up using the + parameter and so may resolved + by any method and order described in that parameter. + + 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. + + Using a password server means your UNIX box (running + Samba) is only as secure as your password server. DO NOT + CHOOSE A PASSWORD SERVER THAT YOU DON'T COMPLETELY TRUST. + + + Never point a Samba server at itself for password serving. + This will cause a loop and could lock up your Samba server! + + The name of the password server takes the standard + substitutions, but probably the only useful one is %m + , 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! + + If the security parameter is set to + domain or ads, 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 + security = domain is that if you list several hosts in the + password server option then smbd + will try each in turn till it finds one that responds. This + is useful in case your primary server goes down. + + If the password server 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 WORKGROUP<1C> + and then contacting each server returned in the list of IP + addresses from the name resolution source. + + 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. + + If the security parameter is + set to server, then there are different + restrictions that security = domain doesn't + suffer from: + + + + You may list several password servers in + the password server parameter, however if an + smbd makes a connection to a password server, + and then the password server fails, no more users will be able + to be authenticated from this smbd. This is a + restriction of the SMB/CIFS protocol when in security = server + mode and cannot be fixed in Samba. + + + + 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 + security = server mode the network logon will appear to + come from there rather than from the users workstation. + + + + +security + +NT-PDC, NT-BDC1, NT-BDC2, * +windc.mydomain.com:389 192.168.1.101 * +* + diff --git a/docs-xml/smbdotconf/security/preloadmodules.xml b/docs-xml/smbdotconf/security/preloadmodules.xml new file mode 100644 index 0000000000..1d985a1995 --- /dev/null +++ b/docs-xml/smbdotconf/security/preloadmodules.xml @@ -0,0 +1,14 @@ + + + This is a list of paths to modules that should + be loaded into smbd before a client connects. This improves + the speed of smbd when reacting to new connections somewhat. + + + +/usr/lib/samba/passdb/mysql.so + diff --git a/docs-xml/smbdotconf/security/printeradmin.xml b/docs-xml/smbdotconf/security/printeradmin.xml new file mode 100644 index 0000000000..a0dd9929c0 --- /dev/null +++ b/docs-xml/smbdotconf/security/printeradmin.xml @@ -0,0 +1,27 @@ + + + + This lists users who can do anything to printers + via the remote administration interfaces offered + by MS-RPC (usually using a NT workstation). + This parameter can be set per-share or globally. + Note: The root user always has admin rights. Use + caution with use in the global stanza as this can + cause side effects. + + + + This parameter has been marked deprecated in favor + of using the SePrintOperatorPrivilege and individual + print security descriptors. It will be removed in a future release. + + + + + +admin, @staff + diff --git a/docs-xml/smbdotconf/security/privatedir.xml b/docs-xml/smbdotconf/security/privatedir.xml new file mode 100644 index 0000000000..d0cbcfad59 --- /dev/null +++ b/docs-xml/smbdotconf/security/privatedir.xml @@ -0,0 +1,14 @@ + + + This parameters defines the directory + smbd will use for storing such files as smbpasswd + and secrets.tdb. + + + +${prefix}/private + diff --git a/docs-xml/smbdotconf/security/readlist.xml b/docs-xml/smbdotconf/security/readlist.xml new file mode 100644 index 0000000000..df6b4f129b --- /dev/null +++ b/docs-xml/smbdotconf/security/readlist.xml @@ -0,0 +1,22 @@ + + + + This is a list of users that are given read-only access to a service. If the connecting user is in this list + then they will not be given write access, no matter what the option is set + to. The list can include group names using the syntax described in the + parameter. + + + This parameter will not work with the share in + Samba 3.0. This is by design. + + +write list +invalid users + + +mary, @students + diff --git a/docs-xml/smbdotconf/security/readonly.xml b/docs-xml/smbdotconf/security/readonly.xml new file mode 100644 index 0000000000..6e1f6dd2b8 --- /dev/null +++ b/docs-xml/smbdotconf/security/readonly.xml @@ -0,0 +1,19 @@ + + + An inverted synonym is . + + If this parameter is yes, then users + of a service may not create or modify files in the service's + directory. + + Note that a printable service (printable = yes) + will ALWAYS allow writing to the directory + (user privileges permitting), but only via spooling operations. + + +yes + diff --git a/docs-xml/smbdotconf/security/renameuserscript.xml b/docs-xml/smbdotconf/security/renameuserscript.xml new file mode 100644 index 0000000000..1ec1dcb6eb --- /dev/null +++ b/docs-xml/smbdotconf/security/renameuserscript.xml @@ -0,0 +1,33 @@ + + + + This is the full pathname to a script that will be run as root by smbd + 8 under special circumstances described below. + + + + When a user with admin authority or SeAddUserPrivilege rights renames a user (e.g.: from the NT4 User Manager + for Domains), this script will be run to rename the POSIX user. Two variables, %uold and + %unew, will be substituted with the old and new usernames, respectively. The script should + return 0 upon successful completion, and nonzero otherwise. + + + + The script has all responsibility to rename all the necessary data that is accessible in this posix method. + This can mean different requirements for different backends. The tdbsam and smbpasswd backends will take care + of the contents of their respective files, so the script is responsible only for changing the POSIX username, and + other data that may required for your circumstances, such as home directory. Please also consider whether or + not you need to rename the actual home directories themselves. The ldapsam backend will not make any changes, + because of the potential issues with renaming the LDAP naming attribute. In this case the script is + responsible for changing the attribute that samba uses (uid) for locating users, as well as any data that + needs to change for other applications using the same directory. + + + + +no + diff --git a/docs-xml/smbdotconf/security/restrictanonymous.xml b/docs-xml/smbdotconf/security/restrictanonymous.xml new file mode 100644 index 0000000000..1fbf983d54 --- /dev/null +++ b/docs-xml/smbdotconf/security/restrictanonymous.xml @@ -0,0 +1,38 @@ + + + The setting of this parameter determines whether user and + group list information is returned for an anonymous connection. + and mirrors the effects of the + +HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ + Control\LSA\RestrictAnonymous + + registry key in Windows 2000 and Windows NT. When set to 0, user + and group list information is returned to anyone who asks. When set + to 1, only an authenticated user can retrive user and + group list information. For the value 2, supported by + Windows 2000/XP and Samba, no anonymous connections are allowed at + all. This can break third party and Microsoft + applications which expect to be allowed to perform + operations anonymously. + + + The security advantage of using restrict anonymous = 1 is dubious, + as user and group list information can be obtained using other + means. + + + + + The security advantage of using restrict anonymous = 2 is removed + by setting yes on any share. + + + + +0 + diff --git a/docs-xml/smbdotconf/security/rootdirectory.xml b/docs-xml/smbdotconf/security/rootdirectory.xml new file mode 100644 index 0000000000..8736598001 --- /dev/null +++ b/docs-xml/smbdotconf/security/rootdirectory.xml @@ -0,0 +1,35 @@ + +root +root dir + + The server will chroot() (i.e. + Change its root directory) to this directory on startup. This is + not strictly necessary for secure operation. Even without it the + server will deny access to files not in one of the service entries. + It may also check for, and deny access to, soft links to other + parts of the filesystem, or attempts to use ".." in file names + to access other directories (depending on the setting of the + parameter). + + + Adding a root directory entry other + than "/" adds an extra level of security, but at a price. It + absolutely ensures that no access is given to files not in the + sub-tree specified in the root directory + option, including some files needed for + complete operation of the server. To maintain full operability + of the server you will need to mirror some system files + into the root directory tree. In particular + you will need to mirror /etc/passwd (or a + subset of it), and any binaries or configuration files needed for + printing (if required). The set of files that must be mirrored is + operating system dependent. + + +/ +/homes/smb + diff --git a/docs-xml/smbdotconf/security/security.xml b/docs-xml/smbdotconf/security/security.xml new file mode 100644 index 0000000000..3ad5175712 --- /dev/null +++ b/docs-xml/smbdotconf/security/security.xml @@ -0,0 +1,250 @@ + + + /(yes|true)/ + + + This option affects how clients respond to + Samba and is one of the most important settings in the + smb.conf file. + + The option sets the "security mode bit" in replies to + protocol negotiations with smbd + 8 to turn share level security on or off. Clients decide + based on this bit whether (and how) to transfer user and password + information to the server. + + + The default is security = user, as this is + the most common setting needed when talking to Windows 98 and + Windows NT. + + The alternatives are security = share, + security = server or security = domain + . + + In versions of Samba prior to 2.0.0, the default was + security = share mainly because that was + the only option at one stage. + + 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. + + If your PCs use usernames that are the same as their + usernames on the UNIX machine then you will want to use + security = user. If you mostly use usernames + that don't exist on the UNIX box then use security = + share. + + You should also use security = share 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 security = user, see + the parameter for details. + + It is possible to use smbd in a + hybrid mode where it is offers both user and share + level security under different . + + The different settings will now be explained. + + + SECURITY = SHARE + + 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 security = share + server). Instead, the clients send authentication information + (passwords) on a per-share basis, at the time they attempt to connect + to that share. + + Note that smbd ALWAYS + uses a valid UNIX user to act on behalf of the client, even in + security = share level security. + + As clients are not required to send a username to the server + in share level security, smbd uses several + techniques to determine the correct UNIX user to use on behalf + of the client. + + A list of possible UNIX usernames to match with the given + client password is constructed using the following methods : + + + + If the parameter is set, then all the other + stages are missed and only the username is checked. + + + + + Is a username is sent with the share connection + request, then this username (after mapping - see ), + is added as a potential username. + + + + + If the client did a previous logon + request (the SessionSetup SMB call) then the + username sent in this SMB will be added as a potential username. + + + + + The name of the service the client requested is + added as a potential username. + + + + + The NetBIOS name of the client is added to + the list as a potential username. + + + + + Any users on the list are added as potential usernames. + + + + + If the guest only parameter is + not set, then this list is then tried with the supplied password. + The first user for whom the password matches will be used as the + UNIX user. + + If the guest only parameter is + set, or no username can be determined then if the share is marked + as available to the guest account, then this + guest user will be used, otherwise access is denied. + + Note that it can be very confusing + in share-level security as to which UNIX username will eventually + be used in granting access. + + See also the section + NOTE ABOUT USERNAME/PASSWORD VALIDATION. + + SECURITY = USER + + 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 + parameter). Encrypted passwords (see the parameter) can also + be used in this security mode. Parameters such as and 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. + + Note that the name of the resource being + requested is not 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 . + See the parameter for details on doing this. + + See also the section NOTE ABOUT USERNAME/PASSWORD VALIDATION. + + SECURITY = DOMAIN + + This mode will only work correctly if net + 8 has been used to add this + machine into a Windows NT Domain. It expects the + parameter to be set to yes. 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. + + Note 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. + + Note that from the client's point + of view security = domain is the same + as security = user. It only + affects how the server deals with the authentication, + it does not in any way affect what the client sees. + + Note that the name of the resource being + requested is not 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 . + See the parameter for details on doing this. + + See also the section + NOTE ABOUT USERNAME/PASSWORD VALIDATION. + + See also the parameter and + the parameter. + + SECURITY = SERVER + + + 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 security = user. It expects the + parameter to be set to yes, unless the remote + server does not support them. However note that if encrypted passwords have been negotiated then Samba cannot + revert back to checking the UNIX password file, it must have a valid smbpasswd file to check users against. See the chapter about the User Database in + the Samba HOWTO Collection for details on how to set this up. + + + 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). + + + From the client's point of + view security = server is the + same as security = user. It + only affects how the server deals with the authentication, it does + not in any way affect what the client sees. + + Note that the name of the resource being + requested is not 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 . + See the parameter for details on doing this. + + See also the section + NOTE ABOUT USERNAME/PASSWORD VALIDATION. + + See also the parameter and the + parameter. + + SECURITY = ADS + + In this mode, Samba will act as a domain member in an ADS realm. To operate + in this mode, the machine running Samba will need to have Kerberos installed + and configured and Samba will need to be joined to the ADS realm using the + net utility. + + Note that this mode does NOT make Samba operate as a Active Directory Domain + Controller. + + Read the chapter about Domain Membership in the HOWTO for details. + + +realm +encrypt passwords + +USER +DOMAIN + diff --git a/docs-xml/smbdotconf/security/securitymask.xml b/docs-xml/smbdotconf/security/securitymask.xml new file mode 100644 index 0000000000..23bc2808db --- /dev/null +++ b/docs-xml/smbdotconf/security/securitymask.xml @@ -0,0 +1,39 @@ + + + + This parameter controls what UNIX permission bits will be set when a Windows NT client is manipulating the + UNIX permission on a file using the native NT security dialog box. + + + + This parameter is applied as a mask (AND'ed with) to the incoming permission bits, thus resetting + any bits not in this mask. Make sure not to mix up this parameter with , which works in a manner similar to this one but uses a logical OR instead of an AND. + + + + Essentially, all bits set to zero in this mask will result in setting to zero the corresponding bits on the + file permissions regardless of the previous status of this bits on the file. + + + + If not set explicitly this parameter is 0777, allowing a user to set all the user/group/world permissions on a file. + + + + Note that users who can access the Samba server through other means can easily bypass this + restriction, so it is primarily useful for standalone "appliance" systems. Administrators of + most normal systems will probably want to leave it set to 0777. + + + +force directory security mode +directory security mask +force security mode + +0777 +0770 + diff --git a/docs-xml/smbdotconf/security/serverschannel.xml b/docs-xml/smbdotconf/security/serverschannel.xml new file mode 100644 index 0000000000..6317448fb6 --- /dev/null +++ b/docs-xml/smbdotconf/security/serverschannel.xml @@ -0,0 +1,23 @@ + + + + This controls whether the server offers or even demands the use of the netlogon schannel. + no does not offer the schannel, auto offers the schannel but does not enforce it, and yes denies access if the client is not able to speak netlogon schannel. + This is only the case for Windows NT4 before SP4. + + + + Please note that with this set to no you will have to apply the WindowsXP + WinXP_SignOrSeal.reg registry patch found in the docs/registry subdirectory of the Samba distribution tarball. + + + +auto +yes + diff --git a/docs-xml/smbdotconf/security/serversigning.xml b/docs-xml/smbdotconf/security/serversigning.xml new file mode 100644 index 0000000000..f2f5629586 --- /dev/null +++ b/docs-xml/smbdotconf/security/serversigning.xml @@ -0,0 +1,20 @@ + + + + This controls whether the server offers or requires + the client it talks to to use SMB signing. Possible values + are auto, mandatory + and disabled. + + + When set to auto, SMB signing is offered, but not enforced. + When set to mandatory, SMB signing is required and if set + to disabled, SMB signing is not offered either. + + +Disabled + diff --git a/docs-xml/smbdotconf/security/smbencrypt.xml b/docs-xml/smbdotconf/security/smbencrypt.xml new file mode 100644 index 0000000000..eb91ce51fa --- /dev/null +++ b/docs-xml/smbdotconf/security/smbencrypt.xml @@ -0,0 +1,45 @@ + + + + This is a new feature introduced with Samba 3.2 and above. It is an + extension to the SMB/CIFS protocol negotiated as part of the UNIX extensions. + SMB encryption uses the GSSAPI (SSPI on Windows) ability to encrypt + and sign every request/response in a SMB protocol stream. When + enabled it provides a secure method of SMB/CIFS communication, + similar to an ssh protected session, but using SMB/CIFS authentication + to negotiate encryption and signing keys. Currently this is only + supported by Samba 3.2 smbclient, and hopefully soon Linux CIFSFS + and MacOS/X clients. Windows clients do not support this feature. + + + This controls whether the server offers or requires + the client it talks to to use SMB encryption. Possible values + are auto, mandatory + and disabled. This may be set on a per-share + basis, but clients may chose to encrypt the entire session, not + just traffic to a specific share. If this is set to mandatory + then all traffic to a share must must + be encrypted once the connection has been made to the share. + The server would return "access denied" to all non-encrypted + requests on such a share. Selecting encrypted traffic reduces + throughput as smaller packet sizes must be used (no huge UNIX + style read/writes allowed) as well as the overhead of encrypting + and signing all the data. + + + If SMB encryption is selected, Windows style SMB signing (see + the option) is no longer necessary, + as the GSSAPI flags use select both signing and sealing of the data. + + + When set to auto, SMB encryption is offered, but not enforced. + When set to mandatory, SMB encryption is required and if set + to disabled, SMB encryption can not be negotiated. + + +auto + diff --git a/docs-xml/smbdotconf/security/smbpasswdfile.xml b/docs-xml/smbdotconf/security/smbpasswdfile.xml new file mode 100644 index 0000000000..209fa74422 --- /dev/null +++ b/docs-xml/smbdotconf/security/smbpasswdfile.xml @@ -0,0 +1,19 @@ + + + This option sets the path to the encrypted smbpasswd file. By + default the path to the smbpasswd file is compiled into Samba. + + + An example of use is: + +smb passwd file = /etc/samba/smbpasswd + + + + +${prefix}/private/smbpasswd + diff --git a/docs-xml/smbdotconf/security/unixpasswordsync.xml b/docs-xml/smbdotconf/security/unixpasswordsync.xml new file mode 100644 index 0000000000..7f30c47d90 --- /dev/null +++ b/docs-xml/smbdotconf/security/unixpasswordsync.xml @@ -0,0 +1,21 @@ + + + This boolean parameter controls whether Samba + attempts to synchronize the UNIX password with the SMB password + when the encrypted SMB password in the smbpasswd file is changed. + If this is set to yes the program specified in the passwd + programparameter is called AS ROOT - + to allow the new UNIX password to be set without access to the + old UNIX password (as the SMB password change code has no + access to the old password cleartext, only the new). + + +passwd program +passwd chat + +no + diff --git a/docs-xml/smbdotconf/security/updateencrypted.xml b/docs-xml/smbdotconf/security/updateencrypted.xml new file mode 100644 index 0000000000..da493665cf --- /dev/null +++ b/docs-xml/smbdotconf/security/updateencrypted.xml @@ -0,0 +1,34 @@ + + + + + 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 atabase) 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 no. + + + + In order for this parameter to be operative the parameter must + be set to no. The default value of Yes. Note: This must be set to no for this to work. + + + + Note that even when this parameter is set a user authenticating to smbd + must still enter a valid password in order to connect correctly, and to update their hashed (smbpasswd) + passwords. + + + +no + diff --git a/docs-xml/smbdotconf/security/usekerberoskeytab.xml b/docs-xml/smbdotconf/security/usekerberoskeytab.xml new file mode 100644 index 0000000000..ad6cc88278 --- /dev/null +++ b/docs-xml/smbdotconf/security/usekerberoskeytab.xml @@ -0,0 +1,23 @@ + + + + Specifies whether Samba should attempt to maintain service principals in the systems + keytab file for host/FQDN and cifs/FQDN. + + + + When you are using the heimdal Kerberos libraries, you must also specify the following in + /etc/krb5.conf: + +[libdefaults] +default_keytab_name = FILE:/etc/krb5.keytab + + + + + +False + diff --git a/docs-xml/smbdotconf/security/username.xml b/docs-xml/smbdotconf/security/username.xml new file mode 100644 index 0000000000..3a45d4d72f --- /dev/null +++ b/docs-xml/smbdotconf/security/username.xml @@ -0,0 +1,65 @@ + +user +users + + Multiple users may be specified in a comma-delimited + list, in which case the supplied password will be tested against + each username in turn (left to right). + + The username line is needed only when + the PC is unable to supply its own username. This is the case + for the COREPLUS protocol or where your users have different WfWg + usernames to UNIX usernames. In both these cases you may also be + better using the \\server\share%user syntax instead. + + The username line is not a great + solution in many cases as it means Samba will try to validate + the supplied password against each of the usernames in the + username line in turn. This is slow and + a bad idea for lots of users in case of duplicate passwords. + You may get timeouts or security breaches using this parameter + unwisely. + + Samba relies on the underlying UNIX security. This + parameter does not restrict who can login, it just offers hints + to the Samba server as to what usernames might correspond to the + supplied password. Users can login as whoever they please and + they will be able to do no more damage than if they started a + telnet session. The daemon runs as the user that they log in as, + so they cannot do anything that user cannot do. + + To restrict a service to a particular set of users you + can use the parameter. + + If any of the usernames begin with a '@' then the name + will be looked up first in the NIS netgroups list (if Samba + is compiled with netgroup support), followed by a lookup in + the UNIX groups database and will expand to a list of all users + in the group of that name. + + If any of the usernames begin with a '+' then the name + will be looked up only in the UNIX groups database and will + expand to a list of all users in the group of that name. + + If any of the usernames begin with a '&' then the name + will be looked up only in the NIS netgroups database (if Samba + is compiled with netgroup support) and will expand to a list + of all users in the netgroup group of that name. + + Note that searching though a groups database can take + quite some time, and some clients may time out during the + search. + + See the section NOTE ABOUT + USERNAME/PASSWORD VALIDATION for more information on how + this parameter determines access to the services. + + +The guest account if a guest service, + else <empty string>. + +fred, mary, jack, jane, @users, @pcgroup + diff --git a/docs-xml/smbdotconf/security/usernamelevel.xml b/docs-xml/smbdotconf/security/usernamelevel.xml new file mode 100644 index 0000000000..adb00134d7 --- /dev/null +++ b/docs-xml/smbdotconf/security/usernamelevel.xml @@ -0,0 +1,27 @@ + + + This option helps Samba to try and 'guess' at + the real UNIX username, as many DOS clients send an all-uppercase + username. By default Samba tries all lowercase, followed by the + username with the first letter capitalized, and fails if the + username is not found on the UNIX machine. + + If this parameter is set to non-zero the behavior changes. + This parameter is a number that specifies the number of uppercase + combinations to try while trying to determine the UNIX user name. The + higher the number the more combinations will be tried, but the slower + the discovery of usernames will be. Use this parameter when you have + strange usernames on your UNIX machine, such as AstrangeUser + . + + This parameter is needed only on UNIX systems that have case + sensitive usernames. + + +0 +5 + diff --git a/docs-xml/smbdotconf/security/usernamemap.xml b/docs-xml/smbdotconf/security/usernamemap.xml new file mode 100644 index 0000000000..54179690be --- /dev/null +++ b/docs-xml/smbdotconf/security/usernamemap.xml @@ -0,0 +1,130 @@ + + + + This option allows you to specify a file containing a mapping of usernames from the clients to the server. + This can be used for several purposes. The most common is to map usernames that users use on DOS or Windows + machines to those that the UNIX box uses. The other is to map multiple users to a single username so that they + can more easily share files. + + + + Please note that for user or share mode security, the username map is applied prior to validating the user + credentials. Domain member servers (domain or ads) apply the username map after the user has been + successfully authenticated by the domain controller and require fully qualified enties in the map table (e.g. + biddle = DOMAIN\foo). + + + + The map file is parsed line by line. Each line should contain a single UNIX username on the left then a '=' + followed by a list of usernames on the right. The list of usernames on the right may contain names of the form + @group in which case they will match any UNIX username in that group. The special client name '*' is a + wildcard and matches any name. Each line of the map file may be up to 1023 characters long. + + + + The file is processed on each line by taking the supplied username and comparing it with each username on the + right hand side of the '=' signs. If the supplied name matches any of the names on the right hand side then it + is replaced with the name on the left. Processing then continues with the next line. + + + + If any line begins with a '#' or a ';' then it is ignored. + + + + If any line begins with an '!' then the processing will stop after that line if a mapping was done by the + line. Otherwise mapping continues with every line being processed. Using '!' is most useful when you have a + wildcard mapping line later in the file. + + + + For example to map from the name admin or administrator to the UNIX + name root you would use: + +root = admin administrator + + Or to map anyone in the UNIX group system to the UNIX name sys you would use: + +sys = @system + + + + + You can have as many mappings as you like in a username map file. + + + + + If your system supports the NIS NETGROUP option then the netgroup database is checked before the /etc/group database for matching groups. + + + + You can map Windows usernames that have spaces in them by using double quotes around the name. For example: + +tridge = "Andrew Tridgell" + + would map the windows username "Andrew Tridgell" to the unix username "tridge". + + + + The following example would map mary and fred to the unix user sys, and map the rest to guest. Note the use of the + '!' to tell Samba to stop processing if it gets a match on that line: + +!sys = mary fred +guest = * + + + + + Note that the remapping is applied to all occurrences of usernames. Thus if you connect to \\server\fred and + fred is remapped to mary then you will actually be connecting to + \\server\mary and will need to supply a password suitable for mary not + fred. The only exception to this is the username passed to the (if you have one). The password server will receive whatever username the client + supplies without modification. + + + + Also note that no reverse mapping is done. The main effect this has is with printing. Users who have been + mapped may have trouble deleting print jobs as PrintManager under WfWg will think they don't own the print + job. + + + + Samba versions prior to 3.0.8 would only support reading the fully qualified username + (e.g.: DOMAIN\user) from + the username map when performing a kerberos login from a client. However, when looking up a map entry for a + user authenticated by NTLM[SSP], only the login name would be used for matches. This resulted in inconsistent + behavior sometimes even on the same server. + + + + The following functionality is obeyed in version 3.0.8 and later: + + + + When performing local authentication, the username map is applied to the login name before attempting to authenticate + the connection. + + + + When relying upon a external domain controller for validating authentication requests, smbd will apply the username map + to the fully qualified username (i.e. DOMAIN\user) only after the user has been successfully authenticated. + + + + An example of use is: + +username map = /usr/local/samba/lib/users.map + + + + + +no username map + diff --git a/docs-xml/smbdotconf/security/usernamemapscript.xml b/docs-xml/smbdotconf/security/usernamemapscript.xml new file mode 100644 index 0000000000..6df134c257 --- /dev/null +++ b/docs-xml/smbdotconf/security/usernamemapscript.xml @@ -0,0 +1,19 @@ + + + This script is a mutually exclusive alternative to the + parameter. This parameter + specifies and external program or script that must accept a single + command line option (the username transmitted in the authentication + request) and return a line line on standard output (the name to which + the account should mapped). In this way, it is possible to store + username map tables in an LDAP or NIS directory services. + + + + +/etc/samba/scripts/mapusers.sh + diff --git a/docs-xml/smbdotconf/security/validusers.xml b/docs-xml/smbdotconf/security/validusers.xml new file mode 100644 index 0000000000..313739d7c1 --- /dev/null +++ b/docs-xml/smbdotconf/security/validusers.xml @@ -0,0 +1,28 @@ + + + + This is a list of users that should be allowed to login to this service. Names starting with + '@', '+' and '&' are interpreted using the same rules as described in the + invalid users parameter. + + + + If this is empty (the default) then any user can login. If a username is in both this list + and the invalid users list then access is denied + for that user. + + + + The current servicename is substituted for %S. + This is useful in the [homes] section. + + + +invalid users + +No valid users list (anyone can login) +greg, @pcusers + diff --git a/docs-xml/smbdotconf/security/writeable.xml b/docs-xml/smbdotconf/security/writeable.xml new file mode 100644 index 0000000000..f811c47e5c --- /dev/null +++ b/docs-xml/smbdotconf/security/writeable.xml @@ -0,0 +1,9 @@ + +writable + + Inverted synonym for . + + diff --git a/docs-xml/smbdotconf/security/writelist.xml b/docs-xml/smbdotconf/security/writelist.xml new file mode 100644 index 0000000000..60db3f19f0 --- /dev/null +++ b/docs-xml/smbdotconf/security/writelist.xml @@ -0,0 +1,29 @@ + + + + This is a list of users that are given read-write access to a service. If the + connecting user is in this list then they will be given write access, no matter + what the option is set to. The list can + include group names using the @group syntax. + + + + Note that if a user is in both the read list and the write list then they will be + given write access. + + + + By design, this parameter will not work with the + share in Samba 3.0. + + + + +read list + + +admin, root, @staff + -- cgit