Basic doc changes to keep up to date.

[kai/samba.git] / docs / textdocs / security_level.txt

diff --git a/docs/textdocs/security_level.txt b/docs/textdocs/security_level.txt
index b565ea79668ede7b070b4129bb26582a8099e734..34d7ce70932961701a6d96fada0d421f9f5a2ed6 100644 (file)
--- 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.