1 files changed, 0 insertions, 234 deletions
diff --git a/docs/htmldocs/securitylevels.html b/docs/htmldocs/securitylevels.html
deleted file mode 100644
index f1b9967540..0000000000
--- a/docs/htmldocs/securitylevels.html
+++ /dev/null
@@ -1,234 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->User and Share security level (for servers not in a domain)</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
-"><LINK
-REL="HOME"
-TITLE="SAMBA Project Documentation"
-HREF="samba-howto-collection.html"><LINK
-REL="UP"
-TITLE="Type of installation"
-HREF="type.html"><LINK
-REL="PREVIOUS"
-TITLE="Type of installation"
-HREF="type.html"><LINK
-REL="NEXT"
-TITLE="How to Configure Samba as a NT4 Primary Domain Controller"
-HREF="samba-pdc.html"></HEAD
-><BODY
-CLASS="CHAPTER"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><DIV
-CLASS="NAVHEADER"
-><TABLE
-SUMMARY="Header navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TH
-COLSPAN="3"
-ALIGN="center"
->SAMBA Project Documentation</TH
-></TR
-><TR
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="bottom"
-><A
-HREF="type.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="80%"
-ALIGN="center"
-VALIGN="bottom"
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="bottom"
-><A
-HREF="samba-pdc.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-></TABLE
-><HR
-ALIGN="LEFT"
-WIDTH="100%"></DIV
-><DIV
-CLASS="CHAPTER"
-><H1
-><A
-NAME="SECURITYLEVELS">Chapter 5. User and Share security level (for servers not in a domain)</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
-><P
->"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="NAVFOOTER"
-><HR
-ALIGN="LEFT"
-WIDTH="100%"><TABLE
-SUMMARY="Footer navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
-><A
-HREF="type.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="samba-howto-collection.html"
-ACCESSKEY="H"
->Home</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="samba-pdc.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
->Type of installation</TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="type.html"
-ACCESSKEY="U"
->Up</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
->How to Configure Samba as a NT4 Primary Domain Controller</TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
-\ No newline at end of file