From d7bb961859a3501aec4d28842bfffb6190d19a73 Mon Sep 17 00:00:00 2001 From: Andrew Bartlett Date: Fri, 3 Feb 2012 18:03:10 +1100 Subject: s3-auth: Remove security=share (depricated since 3.6). This patch removes security=share, which Samba implemented by matching the per-share password provided by the client in the Tree Connect with a selection of usernames supplied by the client, the smb.conf or guessed from the environment. The rationale for the removal is that for the bulk of security=share users, we just we need a very simple way to run a 'trust the network' Samba server, where users mark shares as guest ok. This is still supported, and the smb.conf options are documented at https://wiki.samba.org/index.php/Public_Samba_Server At the same time, this closes the door on one of the most arcane areas of Samba authentication. Naturally, full user-name/password authentication remain available in security=user and above. This includes documentation updates for username and only user, which now only do a small amount of what they used to do. Andrew Bartlett -------------- / \ / REST \ / IN \ / PEACE \ / \ | SEC_SHARE | | security=share | | | | | | 5 March | | | | 2012 | *| * * * | * _________)/\\_//(\/(/\)/\//\/\///|_)_______ --- docs-xml/smbdotconf/security/security.xml | 109 +----------------------------- 1 file changed, 2 insertions(+), 107 deletions(-) (limited to 'docs-xml/smbdotconf/security/security.xml') diff --git a/docs-xml/smbdotconf/security/security.xml b/docs-xml/smbdotconf/security/security.xml index 74ea569b86..2575d77b99 100644 --- a/docs-xml/smbdotconf/security/security.xml +++ b/docs-xml/smbdotconf/security/security.xml @@ -11,34 +11,18 @@ 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 most common setting, used for a standalone file server or a DC. The alternatives are security = ads or security = domain - , which support joining Samba to a Windows domain, along with security = share and security = server, both of which are deprecated. - - In versions of Samba prior to 2.0.0, the default was - security = share mainly because that was - the only option at one stage. + , which support joining Samba to a Windows domain, along with security = server, which is deprecated. You should use security = user and if you want to mainly setup shares without a password (guest shares). This is commonly used for a shared printer server. - 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. @@ -65,8 +49,6 @@ 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 @@ -94,93 +76,9 @@ 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 = SHARE - - This option is deprecated as it is incompatible with SMB2 - - 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 = SERVER @@ -221,9 +119,6 @@ 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. -- cgit