From 510064b14e8fddafe615f8c707023fcc3f84f094 Mon Sep 17 00:00:00 2001 From: Gerald Carter Date: Fri, 10 Oct 2003 16:21:39 +0000 Subject: removing docs from HEAD (This used to be commit 820903ef5a062b4b9824c33ee035c68a39c8eeb0) --- docs/docbook/smbdotconf/security/security.xml | 270 -------------------------- 1 file changed, 270 deletions(-) delete mode 100644 docs/docbook/smbdotconf/security/security.xml (limited to 'docs/docbook/smbdotconf/security/security.xml') diff --git a/docs/docbook/smbdotconf/security/security.xml b/docs/docbook/smbdotconf/security/security.xml deleted file mode 100644 index 030abc1de1..0000000000 --- a/docs/docbook/smbdotconf/security/security.xml +++ /dev/null @@ -1,270 +0,0 @@ - - - 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 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 map to guest - 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 - NetBIOS aliases. - - 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 guest - only parameter is set, then all the other - stages are missed and only the - guest account username is checked. - - - - - Is a username is sent with the share connection - request, then this username (after mapping - see - username map), - 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 - user 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 - username map - parameter). Encrypted passwords (see the - encrypted passwords parameter) can also - be used in this security mode. Parameters such as - user and - guest only 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 - guest account. - See the map to guest - 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 - encrypted passwords - 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 - guest account. - See the map to guest - parameter for details on doing this. - - See also the section - NOTE ABOUT USERNAME/PASSWORD VALIDATION. - - See also the password - server parameter and the - encrypted passwords - 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 - encrypted passwords 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, due to the fact that is activly initiates a - man-in-the-middle attack on the remote SMB server. 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 authenticaions 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 - guest account. - See the map to guest - parameter for details on doing this. - - See also the section - NOTE ABOUT USERNAME/PASSWORD VALIDATION. - - See also the password - server parameter and the - encrypted passwords 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. - - See also the ads server - parameter, the realm - paramter and the - encrypted passwords parameter. - - Default: security = USER - Example: security = DOMAIN - - - -- cgit