-
-
-
-
-
-<html><head><title>Joining an NT Domain with Samba 2.0</title>
-
-<link rev="made" href="mailto:samba-bugs@samba.anu.edu.au">
-</head>
-<body>
-
-<hr>
-
-<h1>Joining an NT Domain with Samba 2.0</h1>
-<h2>Jeremy Allison, Samba Team</h2>
-<h2>11th November 1998</h2>
-
-
-
-<p><hr><p><br>
-<p><br><center>Joining an NT Domain with Samba 2.0 </center>
-<center>----------------------------------- </center>
-<p><br>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.
-<p><br>Assume you have a Samba-2 server with a NetBIOS name of <code>SERV1</code> and are
-joining an NT domain called <code>DOM</code>, which has a PDC with a NetBIOS name
-of <code>DOMPDC</code> and two backup domain controllers with NetBIOS names <code>DOMBDC1</code>
-and <code>DOMBDC2</code>.
-<p><br>In order to join the domain, first stop all Samba daemons and run the
-command
-<p><br><code>smbpasswd -j DOM -r DOMPDC</code>
-<p><br>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). If this is
-successful you will see the message:
-<p><br><code>smbpasswd: Joined domain DOM.</code>
-<p><br>in your terminal window. See the <a href="smbpasswd.8.html"><strong>smbpasswd</strong></a>
-man page for more details.
-<p><br>This command goes through the machine account password change
-protocol, then writes the new (random) machine account password for
-this Samba server into the a file in the same directory in which an
-smbpasswd file would be stored (normally :
-<p><br><code>/usr/local/samba/private</code>
-<p><br>The filename looks like this:
-<p><br><code><NT DOMAIN NAME>.<Samba Server Name>.mac</code>
-<p><br>The <code>.mac</code> suffix stands for machine account password file. So in
-our example above, the file would be called:
-<p><br><code>DOM.SERV1.mac</code>
-<p><br>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><br>Now, before restarting the Samba daemons you must edit your
-<a href="smb.conf.5.html"><strong>smb.conf</strong></a> file to tell Samba it should now
-use domain security.
-<p><br>Change (or add) your
-<p><br><a href="smb.conf.5.html#security"><strong>"security ="</strong></a>
-<p><br>line in the <a href="smb.conf.5.html#global"><strong>[global]</strong></a> section of your
-<a href="smb.conf.5.html"><strong>smb.conf</strong></a> to read:
-<p><br><code>security = domain</code>
-<p><br>Next change the
-<p><br><a href="smb.conf.5.html#workgroup"><strong>"workgroup ="</strong></a>
-<p><br>line in the <a href="smb.conf.5.html#global"><strong>[global]</strong></a> section to read:
-<p><br><code>workgroup = DOM</code>
-<p><br>as this is the name of the domain we are joining.
-<p><br>Finally, add (or modify) a:
-<p><br><a href="smb.conf.5.html#passwordserver"><strong>"password server ="</strong></a>
-<p><br>line in the <a href="smb.conf.5.html#global"><strong>[global]</strong></a> section to read:
-<p><br><code>password server = DOMPDC DOMBDC1 DOMBDC2</code>
-<p><br>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><br>Currently, Samba requires that a defined list of domain controllers be
-listed in this parameter in order to authenticate with domain-level
-security. NT does not use this method, and will either broadcast or
-use a WINS database in order to find domain controllers to
-authenticate against.
-<p><br>Originally, I considered this idea for Samba, but dropped it because
-it seemed so insecure. However several Samba-2 alpha users have
-requested that this feature be added to make Samba more NT-like, so
-I'll probably add a special name of <code>'*'</code> (which means: act like NT
-when looking for domain controllers) in a future release of the
-code. At present, however, you need to know where your domain
-controllers are.
-<p><br>Finally, restart your Samba daemons and get ready for clients to begin
-using domain security!
-<p><br><center>Why is this better than security = server? </center>
-<center>------------------------------------------ </center>
-<p><br>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 <code>DOM\fred</code> 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#securityequalserver"><strong>"security=server"</strong></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><br>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><br>In addition, with <a href="smb.conf.5.html#securityequalserver"><strong>"security=server"</strong></a> 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 <a href="smb.conf.5.html#securityequaldomain"><strong>"security =domain"</strong></a>, 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><br>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><br><em>NOTE:</em> Much of the text of this document was first published in the
-Web magazine <a href="http://www.linuxworld.com"><strong>"LinuxWorld"</strong></a> as the article <a href="http://www.linuxworld.com/linuxworld/lw-1998-10/lw-10-samba.html"><strong>"Doing the NIS/NT Samba"</strong></a>.
-</body>
-</html>
+<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
+><NT DOMAIN NAME></I
+></TT
+>.<TT
+CLASS="REPLACEABLE"
+><I
+><Samba
+ Server Name></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
git.samba.org / samba.git / blobdiff