summaryrefslogtreecommitdiff
path: root/docs/htmldocs/DOMAIN_MEMBER.html
diff options
context:
space:
mode:
Diffstat (limited to 'docs/htmldocs/DOMAIN_MEMBER.html')
-rw-r--r--docs/htmldocs/DOMAIN_MEMBER.html372
1 files changed, 0 insertions, 372 deletions
diff --git a/docs/htmldocs/DOMAIN_MEMBER.html b/docs/htmldocs/DOMAIN_MEMBER.html
deleted file mode 100644
index b7ef4c9a61..0000000000
--- a/docs/htmldocs/DOMAIN_MEMBER.html
+++ /dev/null
@@ -1,372 +0,0 @@
-<HTML
-><HEAD
-><TITLE
->security = domain in Samba 2.x</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="DOMAIN-SECURITY"
->security = domain in Samba 2.x</A
-></H1
-><HR></DIV
-><DIV
-CLASS="SECT1"
-><H1
-CLASS="SECT1"
-><A
-NAME="AEN3"
->Joining an NT Domain with Samba 2.2</A
-></H1
-><P
->Assume you have a Samba 2.x server with a NetBIOS name of
- <TT
-CLASS="CONSTANT"
->SERV1</TT
-> and are joining an NT domain called
- <TT
-CLASS="CONSTANT"
->DOM</TT
->, which has a PDC with a NetBIOS name
- of <TT
-CLASS="CONSTANT"
->DOMPDC</TT
-> and two backup domain controllers
- with NetBIOS names <TT
-CLASS="CONSTANT"
->DOMBDC1</TT
-> and <TT
-CLASS="CONSTANT"
->DOMBDC2
- </TT
->.</P
-><P
->In order to join the domain, first stop all Samba daemons
- and run the command:</P
-><P
-><TT
-CLASS="PROMPT"
->root# </TT
-><TT
-CLASS="USERINPUT"
-><B
->smbpasswd -j DOM -r DOMPDC
- -U<TT
-CLASS="REPLACEABLE"
-><I
->Administrator%password</I
-></TT
-></B
-></TT
-></P
-><P
->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. The <TT
-CLASS="REPLACEABLE"
-><I
->Administrator%password</I
-></TT
-> is
- the login name and password for an account which has the necessary
- privilege to add machines to the domain. If this is successful
- you will see the message:</P
-><P
-><TT
-CLASS="COMPUTEROUTPUT"
->smbpasswd: Joined domain DOM.</TT
->
- </P
-><P
->in your terminal window. See the <A
-HREF="smbpasswd.8.html"
-TARGET="_top"
-> smbpasswd(8)</A
-> man page for more details.</P
-><P
->There is existing development code to join a domain
- without having to create the machine trust account on the PDC
- beforehand. This code will hopefully be available soon
- in release branches as well.</P
-><P
->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 :</P
-><P
-><TT
-CLASS="FILENAME"
->/usr/local/samba/private</TT
-></P
-><P
->In Samba 2.0.x, the filename looks like this:</P
-><P
-><TT
-CLASS="FILENAME"
-><TT
-CLASS="REPLACEABLE"
-><I
->&lt;NT DOMAIN NAME&gt;</I
-></TT
->.<TT
-CLASS="REPLACEABLE"
-><I
->&lt;Samba
- Server Name&gt;</I
-></TT
->.mac</TT
-></P
-><P
->The <TT
-CLASS="FILENAME"
->.mac</TT
-> suffix stands for machine account
- password file. So in our example above, the file would be called:</P
-><P
-><TT
-CLASS="FILENAME"
->DOM.SERV1.mac</TT
-></P
-><P
->In Samba 2.2, this file has been replaced with a TDB
- (Trivial Database) file named <TT
-CLASS="FILENAME"
->secrets.tdb</TT
->.
- </P
-><P
->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.</P
-><P
->Now, before restarting the Samba daemons you must
- edit your <A
-HREF="smb.conf.5.html"
-TARGET="_top"
-><TT
-CLASS="FILENAME"
->smb.conf(5)</TT
->
- </A
-> file to tell Samba it should now use domain security.</P
-><P
->Change (or add) your <A
-HREF="smb.conf.5.html#SECURITY"
-TARGET="_top"
-> <TT
-CLASS="PARAMETER"
-><I
->security =</I
-></TT
-></A
-> line in the [global] section
- of your smb.conf to read:</P
-><P
-><B
-CLASS="COMMAND"
->security = domain</B
-></P
-><P
->Next change the <A
-HREF="smb.conf.5.html#WORKGROUP"
-TARGET="_top"
-><TT
-CLASS="PARAMETER"
-><I
-> workgroup =</I
-></TT
-></A
-> line in the [global] section to read: </P
-><P
-><B
-CLASS="COMMAND"
->workgroup = DOM</B
-></P
-><P
->as this is the name of the domain we are joining. </P
-><P
->You must also have the parameter <A
-HREF="smb.conf.5.html#ENCRYPTPASSWORDS"
-TARGET="_top"
-> <TT
-CLASS="PARAMETER"
-><I
->encrypt passwords</I
-></TT
-></A
-> set to <TT
-CLASS="CONSTANT"
->yes
- </TT
-> in order for your users to authenticate to the NT PDC.</P
-><P
->Finally, add (or modify) a <A
-HREF="smb.conf.5.html#PASSWORDSERVER"
-TARGET="_top"
-> <TT
-CLASS="PARAMETER"
-><I
->password server =</I
-></TT
-></A
-> line in the [global]
- section to read: </P
-><P
-><B
-CLASS="COMMAND"
->password server = DOMPDC DOMBDC1 DOMBDC2</B
-></P
-><P
->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.</P
-><P
->Alternatively, if you want smbd to automatically determine
- the list of Domain controllers to use for authentication, you may
- set this line to be :</P
-><P
-><B
-CLASS="COMMAND"
->password server = *</B
-></P
-><P
->This method, which was introduced in Samba 2.0.6,
- 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.</P
-><P
->Finally, restart your Samba daemons and get ready for
- clients to begin using domain security!</P
-></DIV
-><DIV
-CLASS="SECT1"
-><HR><H1
-CLASS="SECT1"
-><A
-NAME="AEN67"
->Samba and Windows 2000 Domains</A
-></H1
-><P
->Many people have asked regarding the state of Samba's ability to participate in
-a Windows 2000 Domain. Samba 2.2 is able to act as a member server of a Windows
-2000 domain operating in mixed or native mode.</P
-><P
->There is much confusion between the circumstances that require a "mixed" mode
-Win2k DC and a when this host can be switched to "native" mode. A "mixed" mode
-Win2k domain controller is only needed if Windows NT BDCs must exist in the same
-domain. By default, a Win2k DC in "native" mode will still support
-NetBIOS and NTLMv1 for authentication of legacy clients such as Windows 9x and
-NT 4.0. Samba has the same requirements as a Windows NT 4.0 member server.</P
-><P
->The steps for adding a Samba 2.2 host to a Win2k domain are the same as those
-for adding a Samba server to a Windows NT 4.0 domain. The only exception is that
-the "Server Manager" from NT 4 has been replaced by the "Active Directory Users and
-Computers" MMC (Microsoft Management Console) plugin.</P
-></DIV
-><DIV
-CLASS="SECT1"
-><HR><H1
-CLASS="SECT1"
-><A
-NAME="AEN72"
->Why is this better than security = server?</A
-></H1
-><P
->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 <TT
-CLASS="CONSTANT"
->DOM\fred
- </TT
-> 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
- <A
-HREF="smb.conf.5.html#SECURITYEQUALSSERVER"
-TARGET="_top"
->security = server</A
->,
- 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.
- </P
-><P
->Please refer to the <A
-HREF="winbind.html"
-TARGET="_top"
->Winbind
- paper</A
-> for information on a system to automatically
- assign UNIX uids and gids to Windows NT Domain users and groups.
- This code is available in development branches only at the moment,
- but will be moved to release branches soon.</P
-><P
->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.</P
-><P
->In addition, with <B
-CLASS="COMMAND"
->security = server</B
-> 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 <B
-CLASS="COMMAND"
->security = domain</B
->,
- 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.</P
-><P
->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.</P
-><P
-><I
-CLASS="EMPHASIS"
->NOTE:</I
-> Much of the text of this document
- was first published in the Web magazine <A
-HREF="http://www.linuxworld.com"
-TARGET="_top"
->
- LinuxWorld</A
-> as the article <A
-HREF="http://www.linuxworld.com/linuxworld/lw-1998-10/lw-10-samba.html"
-TARGET="_top"
->Doing
- the NIS/NT Samba</A
->.</P
-></DIV
-></DIV
-></BODY
-></HTML
-> \ No newline at end of file