Basic doc changes to keep up to date.

Dan
(This used to be commit 6d81d56f929e763bcf6b1f7a61aabaf884c4aad4)

1 files changed, 5 insertions, 4 deletions

diff --git a/docs/textdocs/security_level.txt b/docs/textdocs/security_level.txt
index b565ea7966..34d7ce7093 100644
--- a/docs/textdocs/security_level.txt
+++ b/docs/textdocs/security_level.txt
@@ -42,14 +42,14 @@ share. It will send a password along with each "tree connection"
 operation. The client is expecting a password to be associated with
 each share, independent of the user. This means that samba has to work
 out what username the client probably wants to use. It is never
-explicitly sent the username. A "real" SMB server like NT actually
-associates passwords directly with shares in share level security, but
+explicitly sent the username. Some commercial SMB servers such as NT actually
+associate passwords directly with shares in share level security, but
 samba always uses the unix authentication scheme where it is a
 username/password that is authenticated, not a "share/password".
 
 Many clients send a "session setup" even if the server is in share
 level security. They normally send a valid username but no
-password. Samba records this username is a list of "possible
+password. Samba records this username in a list of "possible
 usernames". When the client then does a "tree connection" it also adds
 to this list the name of the share they try to connect to (useful for
 home directories) and any users listed in the "user =" smb.conf
@@ -75,4 +75,5 @@ passwords in encrypted form. You have to compile samba with encryption
 enabled to support this feature, and you have to maintain a separate
 smbpasswd file with SMB style encrypted passwords. It is
 cryptographically impossible to translate from unix style encryption
-to SMB style encryption.
+to SMB style encryption, although there are some fairly simple management
+schemes by which the two could be kept in sync.