From 0dbf84b8666f053bcd1cef8d5389c7cb5ca7cbd6 Mon Sep 17 00:00:00 2001 From: John Terpstra Date: Wed, 2 Apr 2003 00:04:36 +0000 Subject: More of the documentation overhaul. More to follow. (This used to be commit 8333c4709e239a7b8bef6f7a5050a7f8a1ffbe7d) --- docs/docbook/projdoc/security_level.sgml | 222 ++++++++++++++++++++++++++++++- 1 file changed, 221 insertions(+), 1 deletion(-) (limited to 'docs/docbook/projdoc/security_level.sgml') diff --git a/docs/docbook/projdoc/security_level.sgml b/docs/docbook/projdoc/security_level.sgml index 00dcc6e83b..fd0fef90fe 100644 --- a/docs/docbook/projdoc/security_level.sgml +++ b/docs/docbook/projdoc/security_level.sgml @@ -8,8 +8,15 @@ +Samba as Stand-Alone ServerSamba as Stand-Alone server (User and Share security level) + +In this section the function and purpose of Samba's security +modes are described. + + + +User and Share security level A SMB server tells the client at startup what "security level" it is @@ -23,6 +30,9 @@ can only tell the client what is available and whether an action is allowed. + +User Level Security + I'll describe user level security first, as its simpler. In user level security the client will send a "session setup" command directly after @@ -53,6 +63,11 @@ maintain multiple authentication contexts in this way (WinDD is an example of an application that does this) + + + +Share Level Security> + <para> Ok, now for share level security. In share level security the client authenticates itself separately for each share. It will send a @@ -79,6 +94,11 @@ usernames". If a match is found then the client is authenticated as that user. </para> +</sect2> + +<sect2> +<title>Server Level Security + Finally "server level" security. In server level security the samba server reports to the client that it is in user level security. The @@ -113,4 +133,204 @@ That real authentication server can be another Samba server or can be a Windows NT server, the later natively capable of encrypted password support. + +Configuring Samba for Seemless Windows Network Integration + + +MS Windows clients may use encrypted passwords as part of a challenege/response +authentication model (a.k.a. NTLMv1) or alone, or clear text strings for simple +password based authentication. It should be realized that with the SMB protocol +the password is passed over the network either in plain text or encrypted, but +not both in the same authentication requests. + + + +When encrypted passwords are used a password that has been entered by the user +is encrypted in two ways: + + + + An MD4 hash of the UNICODE of the password + string. This is known as the NT hash. + + + The password is converted to upper case, + and then padded or trucated to 14 bytes. This string is + then appended with 5 bytes of NULL characters and split to + form two 56 bit DES keys to encrypt a "magic" 8 byte value. + The resulting 16 bytes for the LanMan hash. + + + + +MS Windows 95 pre-service pack 1, MS Windows NT versions 3.x and version 4.0 +pre-service pack 3 will use either mode of password authentication. All +versions of MS Windows that follow these versions no longer support plain +text passwords by default. + + + +MS Windows clients have a habit of dropping network mappings that have been idle +for 10 minutes or longer. When the user attempts to use the mapped drive +connection that has been dropped, the client re-establishes the connection using +a cached copy of the password. + + + +When Microsoft changed the default password mode, support was dropped for caching +of the plain text password. This means that when the registry parameter is changed +to re-enable use of plain text passwords it appears to work, but when a dropped +service connection mapping attempts to revalidate it will fail if the remote +authentication server does not support encrypted passwords. This means that it +is definitely not a good idea to re-enable plain text password support in such clients. + + + +The following parameters can be used to work around the issue of Windows 9x client +upper casing usernames and password before transmitting them to the SMB server +when using clear text authentication. + + + + passsword level = integer + username level = integer + + + +By default Samba will lower case the username before attempting to lookup the user +in the database of local system accounts. Because UNIX usernames conventionally +only contain lower case character, the username level parameter +is rarely needed. + + + +However, passwords on UNIX systems often make use of mixed case characters. +This means that in order for a user on a Windows 9x client to connect to a Samba +server using clear text authentication, the password level +must be set to the maximum number of upper case letter which could +appear is a password. Note that is the server OS uses the traditional DES version +of crypt(), then a password level of 8 will result in case +insensitive passwords as seen from Windows users. This will also result in longer +login times as Samba hash to compute the permutations of the password string and +try them one by one until a match is located (or all combinations fail). + + + +The best option to adopt is to enable support for encrypted passwords +where ever Samba is used. There are three configuration possibilities +for support of encrypted passwords: + + + + +Use MS Windows NT as an authentication server + + +This method involves the additions of the following parameters in the smb.conf file: + + + + encrypt passwords = Yes + security = server + password server = "NetBIOS_name_of_PDC" + + + + +There are two ways of identifying whether or not a username and +password pair was valid or not. One uses the reply information provided +as part of the authentication messaging process, the other uses +just and error code. + + + +The down-side of this mode of configuration is the fact that +for security reasons Samba will send the password server a bogus +username and a bogus password and if the remote server fails to +reject the username and password pair then an alternative mode +of identification of validation is used. Where a site uses password +lock out after a certain number of failed authentication attempts +this will result in user lockouts. + + + +Use of this mode of authentication does require there to be +a standard Unix account for the user, this account can be blocked +to prevent logons by other than MS Windows clients. + + + + + + +Domain Level Security + + +When samba is operating in security = domain mode this means that +the Samba server has a domain security trust account (a machine account) and will cause +all authentication requests to be passed through to the domain controllers. + + + +Samba as a member of an MS Windows NT security domain + + +This method involves additon of the following paramters in the smb.conf file: + + + + encrypt passwords = Yes + security = domain + workgroup = "name of NT domain" + password server = * + + + +The use of the "*" argument to "password server" will cause samba to locate the +domain controller in a way analogous to the way this is done within MS Windows NT. +This is the default behaviour. + + + +In order for this method to work the Samba server needs to join the +MS Windows NT security domain. This is done as follows: + + + + On the MS Windows NT domain controller using + the Server Manager add a machine account for the Samba server. + + + Next, on the Linux system execute: + smbpasswd -r PDC_NAME -j DOMAIN_NAME + + + + +Use of this mode of authentication does require there to be a standard Unix account +for the user in order to assign a uid once the account has been authenticated by +the remote Windows DC. This account can be blocked to prevent logons by other than +MS Windows clients by things such as setting an invalid shell in the +/etc/passwd entry. + + + +An alternative to assigning UIDs to Windows users on a Samba member server is +presented in the Winbind Overview chapter +in this HOWTO collection. + + + + + + +ADS Level Security + + +For information about the configuration option please refer to the entire section entitled +Samba as an ADS Domain Member. + + + + -- cgit