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, 372 insertions, 0 deletions
diff --git a/docs/htmldocs/DOMAIN_MEMBER.html b/docs/htmldocs/DOMAIN_MEMBER.html
new file mode 100644
index 0000000000..b7ef4c9a61
--- /dev/null
+++ b/docs/htmldocs/DOMAIN_MEMBER.html
@@ -0,0 +1,372 @@
+<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