diff options
Diffstat (limited to 'docs/htmldocs/security_level.html')
| -rw-r--r-- | docs/htmldocs/security_level.html | 169 |
1 files changed, 0 insertions, 169 deletions
diff --git a/docs/htmldocs/security_level.html b/docs/htmldocs/security_level.html deleted file mode 100644 index e26e1ea78bb..00000000000 --- a/docs/htmldocs/security_level.html +++ /dev/null @@ -1,169 +0,0 @@ -<HTML -><HEAD -><TITLE ->Security levels</TITLE -><META -NAME="GENERATOR" -CONTENT="Modular DocBook HTML Stylesheet Version 1.57"></HEAD -><BODY -CLASS="ARTICLE" -BGCOLOR="#FFFFFF" -TEXT="#000000" -LINK="#0000FF" -VLINK="#840084" -ALINK="#0000FF" -><DIV -CLASS="ARTICLE" -><DIV -CLASS="TITLEPAGE" -><H1 -CLASS="TITLE" -><A -NAME="SECURITY_LEVELS" ->Security levels</A -></H1 -><HR></DIV -><DIV -CLASS="SECT1" -><H1 -CLASS="SECT1" -><A -NAME="AEN3" ->Introduction</A -></H1 -><P ->Samba supports the following options to the global smb.conf parameter</P -><P -><PRE -CLASS="PROGRAMLISTING" ->[global] -<A -HREF="smb.conf.5.html#SECURITY" -TARGET="_top" -><TT -CLASS="PARAMETER" -><I ->security</I -></TT -></A -> = [share|user(default)|domain|ads]</PRE -></P -><P ->Please refer to the smb.conf man page for usage information and to the document -<A -HREF="DOMAIN_MEMBER.html" -TARGET="_top" ->DOMAIN_MEMBER.html</A -> for further background details -on domain mode security. The Windows 2000 Kerberos domain security model -(security = ads) is described in the <A -HREF="ADS-HOWTO.html" -TARGET="_top" ->ADS-HOWTO.html</A ->.</P -><P ->Of the above, "security = server" means that Samba reports to clients that -it is running in "user mode" but actually passes off all authentication -requests to another "user mode" server. This requires an additional -parameter "password server =" that points to the real authentication server. -That real authentication server can be another Samba server or can be a -Windows NT server, the later natively capable of encrypted password support.</P -></DIV -><DIV -CLASS="SECT1" -><HR><H1 -CLASS="SECT1" -><A -NAME="AEN14" ->More complete description of security levels</A -></H1 -><P ->A SMB server tells the client at startup what "security level" it is -running. There are two options "share level" and "user level". Which -of these two the client receives affects the way the client then tries -to authenticate itself. It does not directly affect (to any great -extent) the way the Samba server does security. I know this is -strange, but it fits in with the client/server approach of SMB. In SMB -everything is initiated and controlled by the client, and the server -can only tell the client what is available and whether an action is -allowed. </P -><P ->I'll describe user level security first, as its simpler. In user level -security the client will send a "session setup" command directly after -the protocol negotiation. This contains a username and password. The -server can either accept or reject that username/password -combination. Note that at this stage the server has no idea what -share the client will eventually try to connect to, so it can't base -the "accept/reject" on anything other than:</P -><P -></P -><OL -TYPE="1" -><LI -><P ->the username/password</P -></LI -><LI -><P ->the machine that the client is coming from</P -></LI -></OL -><P ->If the server accepts the username/password then the client expects to -be able to mount any share (using a "tree connection") without -specifying a password. It expects that all access rights will be as -the username/password specified in the "session setup". </P -><P ->It is also possible for a client to send multiple "session setup" -requests. When the server responds it gives the client a "uid" to use -as an authentication tag for that username/password. The client can -maintain multiple authentication contexts in this way (WinDD is an -example of an application that does this)</P -><P ->Ok, now for share level security. In share level security the client -authenticates itself separately for each share. It will send a -password along with each "tree connection" (share mount). It does not -explicitly send a username with this 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. 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".</P -><P ->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 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 -line. The password is then checked in turn against these "possible -usernames". If a match is found then the client is authenticated as -that user.</P -><P ->Finally "server level" security. In server level security the samba -server reports to the client that it is in user level security. The -client then does a "session setup" as described earlier. The samba -server takes the username/password that the client sends and attempts -to login to the "password server" by sending exactly the same -username/password that it got from the client. If that server is in -user level security and accepts the password then samba accepts the -clients connection. This allows the samba server to use another SMB -server as the "password server". </P -><P ->You should also note that at the very start of all this, where the -server tells the client what security level it is in, it also tells -the client if it supports encryption. If it does then it supplies the -client with a random "cryptkey". The client will then send all -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, although there are some fairly simple management -schemes by which the two could be kept in sync.</P -></DIV -></DIV -></BODY -></HTML ->
\ No newline at end of file |