1 files changed, 0 insertions, 151 deletions
diff --git a/docs/textdocs/DOMAIN_MEMBER.txt b/docs/textdocs/DOMAIN_MEMBER.txt
deleted file mode 100644
index d58a8bc099..0000000000
--- a/docs/textdocs/DOMAIN_MEMBER.txt
+++ /dev/null
@@ -1,151 +0,0 @@
-
-TITLE INFORMATION: Joining an NT Domain with Samba 2.0 
-AUTHOR INFORMATION: Jeremy Allison, Samba Team 
-DATE INFORMATION: 7th October 1999 
-
-Table of Contents 
-
-Joining an NT Domain with Samba 2.0 
------------------------------------ 
-
-In order for a Samba-2 server to join an NT domain, you must first add
-the NetBIOS name of the Samba server to the NT domain on the PDC using
-Server Manager for Domains.  This creates the machine account in the
-domain (PDC) SAM. Note that you should add the Samba server as a "Windows
-NT Workstation or Server", NOT as a Primary or backup domain controller.
-
-Assume you have a Samba-2 server with a NetBIOS name of SERV1 and are
-joining an NT domain called DOM, which has a PDC with a NetBIOS name
-of DOMPDC and two backup domain controllers with NetBIOS names DOMBDC1
-and DOMBDC2.
-
-In order to join the domain, first stop all Samba daemons and run the
-command
-
-smbpasswd -j DOM -r DOMPDC
-
-as we are joining the domain DOM and the PDC for that domain (the only
-machine that has write access to the domain SAM database) is DOMPDC. If this is
-successful you will see the message:
-
-smbpasswd: Joined domain DOM.
-
-in your terminal window. See the smbpasswd
-man page for more details.
-
-This command goes through the machine account password change
-protocol, then writes the new (random) machine account password for
-this Samba server into a file in the same directory in which an
-smbpasswd file would be stored - normally :
-
-/usr/local/samba/private
-
-The filename looks like this:
-
-<NT DOMAIN NAME>.<Samba Server Name>.mac
-
-The .mac suffix stands for machine account password file. So in
-our example above, the file would be called:
-
-DOM.SERV1.mac
-
-This file is created and owned by root and is not readable by any
-other user. It is the key to the domain-level security for your
-system, and should be treated as carefully as a shadow password file.
-
-Now, before restarting the Samba daemons you must edit your
-smb.conf file to tell Samba it should now
-use domain security.
-
-Change (or add) your 
-
-"security ="
-
-line in the [global] section of your
-smb.conf to read:
-
-security = domain
-
-Next change the 
-
-"workgroup ="
-
-line in the [global] section to read: 
-
-workgroup = DOM
-
-as this is the name of the domain we are joining. 
-
-You must also have the parameter "encrypt passwords"
-set to "yes" in order for your users to authenticate to the
-NT PDC.
-
-Finally, add (or modify) a:
-
-"password server ="
-
-line in the [global] section to read: 
-
-password server = DOMPDC DOMBDC1 DOMBDC2
-
-These are the primary and backup domain controllers Samba will attempt
-to contact in order to authenticate users. Samba will try to contact
-each of these servers in order, so you may want to rearrange this list
-in order to spread out the authentication load among domain
-controllers.
-
-Alternatively, if you want smbd to automatically determine the
-list of Domain controllers to use for authentication, you may set this line to be :
-
-password server = *
-
-This method, which is new in Samba 2.0.6 and above, allows Samba
-to use exactly the same mechanism that NT does. This method either broadcasts or
-uses a WINS database in order to find domain controllers to
-authenticate against.
-
-Finally, restart your Samba daemons and get ready for clients to begin
-using domain security!
-
-Why is this better than security = server? 
------------------------------------------- 
-
-Currently, domain security in Samba doesn't free you from having to
-create local Unix users to represent the users attaching to your
-server. This means that if domain user DOM\fred attaches to your
-domain security Samba server, there needs to be a local Unix user fred
-to represent that user in the Unix filesystem. This is very similar to
-the older Samba security mode "security=server", where Samba would pass
-through the authentication request to a Windows NT server in the same
-way as a Windows 95 or Windows 98 server would.
-
-The advantage to domain-level security is that the authentication in
-domain-level security is passed down the authenticated RPC channel in
-exactly the same way that an NT server would do it. This means Samba
-servers now participate in domain trust relationships in exactly the
-same way NT servers do (i.e., you can add Samba servers into a
-resource domain and have the authentication passed on from a resource
-domain PDC to an account domain PDC.
-
-In addition, with "security=server" every Samba daemon on a
-server has to keep a connection open to the authenticating server for
-as long as that daemon lasts. This can drain the connection resources
-on a Microsoft NT server and cause it to run out of available
-connections. With "security =domain", however, the Samba
-daemons connect to the PDC/BDC only for as long as is necessary to
-authenticate the user, and then drop the connection, thus conserving
-PDC connection resources.
-
-And finally, acting in the same manner as an NT server authenticating
-to a PDC means that as part of the authentication reply, the Samba
-server gets the user identification information such as the user SID,
-the list of NT groups the user belongs to, etc. All this information
-will allow Samba to be extended in the future into a mode the
-developers currently call appliance mode. In this mode, no local Unix
-users will be necessary, and Samba will generate Unix uids and gids
-from the information passed back from the PDC when a user is
-authenticated, making a Samba server truly plug and play in an NT
-domain environment. Watch for this code soon.
-
-NOTE: Much of the text of this document was first published in the
-Web magazine "LinuxWorld" as the article "Doing the NIS/NT Samba".