diff options
Diffstat (limited to 'docs/htmldocs/domain-member.html')
| -rw-r--r-- | docs/htmldocs/domain-member.html | 532 |
1 files changed, 0 insertions, 532 deletions
diff --git a/docs/htmldocs/domain-member.html b/docs/htmldocs/domain-member.html deleted file mode 100644 index 19f8fd8677..0000000000 --- a/docs/htmldocs/domain-member.html +++ /dev/null @@ -1,532 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> -<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 7. Domain Membership</title><link rel="stylesheet" href="samba.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.60.1"><link rel="home" href="index.html" title="SAMBA Project Documentation"><link rel="up" href="type.html" title="Part II. Server Configuration Basics"><link rel="previous" href="samba-bdc.html" title="Chapter 6. Backup Domain Control"><link rel="next" href="StandAloneServer.html" title="Chapter 8. Stand-Alone Servers"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 7. Domain Membership</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="samba-bdc.html">Prev</a> </td><th width="60%" align="center">Part II. Server Configuration Basics</th><td width="20%" align="right"> <a accesskey="n" href="StandAloneServer.html">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="domain-member"></a>Chapter 7. Domain Membership</h2></div><div><div class="author"><h3 class="author"><span class="firstname">John</span> <span class="othername">H.</span> <span class="surname">Terpstra</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><tt class="email"><<a href="mailto:jht@samba.org">jht@samba.org</a>></tt></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Jeremy</span> <span class="surname">Allison</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><tt class="email"><<a href="mailto:jra@samba.org">jra@samba.org</a>></tt></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Gerald</span> <span class="othername">(Jerry)</span> <span class="surname">Carter</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><tt class="email"><<a href="mailto:jerry@samba.org">jerry@samba.org</a>></tt></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Andrew</span> <span class="surname">Tridgell</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><tt class="email"><<a href="mailto:tridge@samba.org">tridge@samba.org</a>></tt></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Jelmer</span> <span class="othername">R.</span> <span class="surname">Vernooij</span></h3><div class="affiliation"><span class="orgname">The Samba Team<br></span><div class="address"><p><tt class="email"><<a href="mailto:jelmer@samba.org">jelmer@samba.org</a>></tt></p></div></div></div></div></div><div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><a href="domain-member.html#id2895232">Features and Benefits</a></dt><dt><a href="domain-member.html#id2894803">MS Windows Workstation/Server Machine Trust Accounts</a></dt><dd><dl><dt><a href="domain-member.html#id2894963">Manual Creation of Machine Trust Accounts</a></dt><dt><a href="domain-member.html#id2896748">Using NT4 Server Manager to Add Machine Accounts to the Domain</a></dt><dt><a href="domain-member.html#id2896944">"On-the-Fly" Creation of Machine Trust Accounts</a></dt><dt><a href="domain-member.html#id2897000">Making an MS Windows Workstation or Server a Domain Member</a></dt></dl></dd><dt><a href="domain-member.html#domain-member-server">Domain Member Server</a></dt><dd><dl><dt><a href="domain-member.html#id2897196">Joining an NT4 type Domain with Samba-3</a></dt><dt><a href="domain-member.html#id2899872">Why is this better than security = server?</a></dt></dl></dd><dt><a href="domain-member.html#ads-member">Samba ADS Domain Membership</a></dt><dd><dl><dt><a href="domain-member.html#id2900011">Setup your smb.conf</a></dt><dt><a href="domain-member.html#id2900094">Setup your /etc/krb5.conf</a></dt><dt><a href="domain-member.html#ads-create-machine-account">Create the computer account</a></dt><dt><a href="domain-member.html#ads-test-server">Test your server setup</a></dt><dt><a href="domain-member.html#ads-test-smbclient">Testing with smbclient</a></dt><dt><a href="domain-member.html#id2900442">Notes</a></dt></dl></dd><dt><a href="domain-member.html#id2900464">Common Errors</a></dt><dd><dl><dt><a href="domain-member.html#id2900491">Can Not Add Machine Back to Domain</a></dt><dt><a href="domain-member.html#id2900523">Adding Machine to Domain Fails</a></dt></dl></dd></dl></div><p> -Domain Membership is a subject of vital concern, Samba must be able to -participate as a member server in a Microsoft Domain security context, and -Samba must be capable of providing Domain machine member trust accounts, -otherwise it would not be capable of offering a viable option for many users. -</p><p> -This chapter covers background information pertaining to domain membership, -Samba configuration for it, and MS Windows client procedures for joining a -domain. Why is this necessary? Because both are areas in which there exists -within the current MS Windows networking world and particularly in the -Unix/Linux networking and administration world, a considerable level of -mis-information, incorrect understanding, and a lack of knowledge. Hopefully -this chapter will fill the voids. -</p><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2895232"></a>Features and Benefits</h2></div></div><div></div></div><p> -MS Windows workstations and servers that want to participate in domain -security need to -be made Domain members. Participating in Domain security is often called -<span class="emphasis"><em>Single Sign On</em></span> or <span class="acronym">SSO</span> for short. This -chapter describes the process that must be followed to make a workstation -(or another server - be it an <span class="application">MS Windows NT4 / 200x</span> -server) or a Samba server a member of an MS Windows Domain security context. -</p><p> -Samba-3 can join an MS Windows NT4 style domain as a native member server, an -MS Windows Active Directory Domain as a native member server, or a Samba Domain -Control network. -</p><p> -Domain membership has many advantages: -</p><div class="itemizedlist"><ul type="disc"><li><p> - MS Windows workstation users get the benefit of SSO - </p></li><li><p> - Domain user access rights and file ownership / access controls can be set - from the single Domain SAM (Security Account Manager) database - (works with Domain member servers as well as with MS Windows workstations - that are domain members) - </p></li><li><p> - Only <span class="application">MS Windows NT4 / 200x / XP Professional</span> - workstations that are Domain members - can use network logon facilities - </p></li><li><p> - Domain Member workstations can be better controlled through the use of - Policy files (<tt class="filename">NTConfig.POL</tt>) and Desktop Profiles. - </p></li><li><p> - Through the use of logon scripts, users can be given transparent access to network - applications that run off application servers - </p></li><li><p> - Network administrators gain better application and user access management - abilities because there is no need to maintain user accounts on any network - client or server, other than the central Domain database - (either NT4/Samba SAM style Domain, NT4 Domain that is back ended with an - LDAP directory, or via an Active Directory infrastructure) - </p></li></ul></div></div><div xmlns:ns7="" class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2894803"></a>MS Windows Workstation/Server Machine Trust Accounts</h2></div></div><div></div></div><p> -A machine trust account is an account that is used to authenticate a client -machine -(rather than a user) to the Domain Controller server. In Windows terminology, -this is known as a "Computer Account." -</p><p> -The password of a machine trust account acts as the shared secret for -secure communication with the Domain Controller. This is a security -feature to prevent an unauthorized machine with the same NetBIOS name -from joining the domain and gaining access to domain user/group -accounts. Windows NT, 200x, XP Professional clients use machine trust -accounts, but Windows 9x / Me / XP Home clients do not. Hence, a -Windows 9x / Me / XP Home client is never a true member of a domain -because it does not possess a machine trust account, and thus has no -shared secret with the domain controller. -</p><p> -A Windows NT4 PDC stores each machine trust account in the Windows Registry. -The introduction of MS Windows 2000 saw the introduction of Active Directory, -the new repository for machine trust accounts. -</p><ns7:p> -A Samba PDC, however, stores each machine trust account in two parts, -as follows: - -</ns7:p><div class="itemizedlist"><ul type="disc"><li><p> - A Domain Security Account (stored in the - <i class="parameter"><tt>passdb backend</tt></i> that has been configured in the - <tt class="filename">smb.conf</tt> file. The precise nature of the account information that is - stored depends on the type of backend database that has been chosen. - </p><p> - The older format of this data is the <tt class="filename">smbpasswd</tt> database - which contains the unix login ID, the Unix user identifier (UID), and the - LanMan and NT encrypted passwords. There is also some other information in - this file that we do not need to concern ourselves with here. - </p><p> - The two newer database types are called <span class="emphasis"><em>ldapsam</em></span>, - <span class="emphasis"><em>tdbsam</em></span>. Both store considerably more data than the - older <tt class="filename">smbpasswd</tt> file did. The extra information - enables new user account controls to be used. - </p></li><li><p> - A corresponding Unix account, typically stored in - <tt class="filename">/etc/passwd</tt>. Work is in progress to allow a - simplified mode of operation that does not require Unix user accounts, but - this may not be a feature of the early releases of Samba-3. - </p></li></ul></div><ns7:p> -</ns7:p><p> -There are three ways to create machine trust accounts: -</p><div class="itemizedlist"><ul type="disc"><li><p> - Manual creation from the Unix/Linux command line. Here, both the Samba and - corresponding Unix account are created by hand. - </p></li><li><p> - Using the MS Windows NT4 Server Manager (either from an NT4 Domain member - server, or using the Nexus toolkit available from the Microsoft web site. - This tool can be run from any MS Windows machine so long as the user is - logged on as the administrator account. - </p></li><li><p> - "On-the-fly" creation. The Samba machine trust account is automatically - created by Samba at the time the client is joined to the domain. - (For security, this is the recommended method.) The corresponding Unix - account may be created automatically or manually. - </p></li></ul></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2894963"></a>Manual Creation of Machine Trust Accounts</h3></div></div><div></div></div><p> -The first step in manually creating a machine trust account is to manually -create the corresponding Unix account in <tt class="filename">/etc/passwd</tt>. -This can be done using <b class="command">vipw</b> or another 'add user' command -that is normally used to create new Unix accounts. The following is an example for a Linux based Samba server: -</p><p> -<tt class="prompt">root# </tt><b class="userinput"><tt>/usr/sbin/useradd -g 100 -d /dev/null -c <i class="replaceable"><tt>"machine nickname"</tt></i> -s /bin/false <i class="replaceable"><tt>machine_name</tt></i>$ </tt></b> -</p><p> -<tt class="prompt">root# </tt><b class="userinput"><tt>passwd -l <i class="replaceable"><tt>machine_name</tt></i>$</tt></b> -</p><p> -On *BSD systems, this can be done using the <b class="command">chpass</b> utility: -</p><p> -<tt class="prompt">root# </tt><b class="userinput"><tt>chpass -a "<i class="replaceable"><tt>machine_name</tt></i>$:*:101:100::0:0:Workstation <i class="replaceable"><tt>machine_name</tt></i>:/dev/null:/sbin/nologin"</tt></b> -</p><p> -The <tt class="filename">/etc/passwd</tt> entry will list the machine name -with a "$" appended, won't have a password, will have a null shell and no -home directory. For example a machine named 'doppy' would have an -<tt class="filename">/etc/passwd</tt> entry like this: -</p><pre class="programlisting"> -doppy$:x:505:501:<i class="replaceable"><tt>machine_nickname</tt></i>:/dev/null:/bin/false -</pre><p> -Above, <i class="replaceable"><tt>machine_nickname</tt></i> can be any -descriptive name for the client, i.e., BasementComputer. -<i class="replaceable"><tt>machine_name</tt></i> absolutely must be the NetBIOS -name of the client to be joined to the domain. The "$" must be -appended to the NetBIOS name of the client or Samba will not recognize -this as a machine trust account. -</p><p> -Now that the corresponding Unix account has been created, the next step is to create -the Samba account for the client containing the well-known initial -machine trust account password. This can be done using the <a href="smbpasswd.8.html" target="_top"><b class="command">smbpasswd(8)</b></a> command -as shown here: -</p><ns7:p> -</ns7:p><pre class="screen"> -<tt class="prompt">root# </tt><b class="userinput"><tt>smbpasswd -a -m <i class="replaceable"><tt>machine_name</tt></i></tt></b> -</pre><ns7:p> -</ns7:p><p> -where <i class="replaceable"><tt>machine_name</tt></i> is the machine's NetBIOS -name. The RID of the new machine account is generated from the UID of -the corresponding Unix account. -</p><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Join the client to the domain immediately</h3><p> - Manually creating a machine trust account using this method is the - equivalent of creating a machine trust account on a Windows NT PDC using - the <span class="application">Server Manager</span>. From the time at which the - account is created to the time which the client joins the domain and - changes the password, your domain is vulnerable to an intruder joining - your domain using a machine with the same NetBIOS name. A PDC inherently - trusts members of the domain and will serve out a large degree of user - information to such clients. You have been warned! - </p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2896748"></a>Using NT4 Server Manager to Add Machine Accounts to the Domain</h3></div></div><div></div></div><p> -If the machine from which you are trying to manage the domain is an -<span class="application">MS Windows NT4 workstation</span> -then the tool of choice is the package called <b class="command">SRVTOOLS.EXE</b>. -When executed in the target directory this will unpack -<b class="command">SrvMge.exe</b> and <b class="command">UsrMgr.exe</b> (both are -Domain Management tools for MS Windows NT4 workstation. -</p><p> -If your workstation is any other MS Windows product you should download the -<b class="command">Nexus.exe</b> package from the Microsoft web site. When executed -from the target directory this will unpack the same tools but for use on -<span class="application">MS Windows 9x/Me/200x/XP</span>. -</p><p> -Launch the <b class="command">srvmgr.exe</b> (Server Manager for Domains) and follow these steps: -</p><div class="procedure"><p class="title"><b>Procedure 7.1. Server Manager Account Machine Account Management</b></p><ol type="1"><li><p> - From the menu select <span class="guimenu">Computer</span> - </p></li><li><p> - Click on <span class="guimenuitem">Select Domain</span> - </p></li><li><p> - Click on the name of the domain you wish to administer in the - <span class="guilabel">Select Domain</span> panel and then click - <span class="guibutton">OK</span>. - </p></li><li><p> - Again from the menu select <span class="guimenu">Computer</span> - </p></li><li><p> - Select <span class="guimenuitem">Add to Domain</span> - </p></li><li><p> - In the dialog box, click on the radio button to - <span class="guilabel">Add NT Workstation of Server</span>, then - enter the machine name in the field provided, then click the - <span class="guibutton">Add</span> button. - </p></li></ol></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2896944"></a>"On-the-Fly" Creation of Machine Trust Accounts</h3></div></div><div></div></div><p> -The second (and recommended) way of creating machine trust accounts is -simply to allow the Samba server to create them as needed when the client -is joined to the domain. -</p><p>Since each Samba machine trust account requires a corresponding Unix account, a method -for automatically creating the Unix account is usually supplied; this requires configuration of the -<a href="smb.conf.5.html#ADDMACHINESCRIPT" target="_top">add machine script</a> option in -<tt class="filename">smb.conf</tt>. This method is not required, however; corresponding Unix -accounts may also be created manually. -</p><p> -Below is an example for a RedHat Linux system. -</p><pre class="programlisting"> -[global] - # <...remainder of parameters...> - add machine script = /usr/sbin/useradd -d /dev/null -g 100 -s /bin/false -M %u -</pre></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2897000"></a>Making an MS Windows Workstation or Server a Domain Member</h3></div></div><div></div></div><p> -The procedure for making an MS Windows workstation of server a member of the domain varies -with the version of Windows: -</p><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2897012"></a>Windows 200x XP Professional</h4></div></div><div></div></div><p> - When the user elects to make the client a domain member, Windows 200x prompts for - an account and password that has privileges to create machine accounts in the domain. - A Samba administrative account (i.e., a Samba account that has root privileges on the - Samba server) must be entered here; the operation will fail if an ordinary user - account is given. - </p><p> - Note: For security reasons the password for this administrative account should be set - to a password that is other than that used for the root user in the - <tt class="filename">/etc/passwd</tt>. - </p><p> - The name of the account that is used to create domain member machine accounts can be - anything the network administrator may choose. If it is other than <span class="emphasis"><em>root</em></span> - then this is easily mapped to root using the file pointed to be the <tt class="filename">smb.conf</tt> parameter - <i class="parameter"><tt>username map = /etc/samba/smbusers</tt></i>. - </p><p> - The session key of the Samba administrative account acts as an - encryption key for setting the password of the machine trust - account. The machine trust account will be created on-the-fly, or - updated if it already exists. - </p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2897081"></a>Windows NT4</h4></div></div><div></div></div><p> - If the machine trust account was created manually, on the - Identification Changes menu enter the domain name, but do not - check the box <span class="guilabel">Create a Computer Account in the Domain</span>. - In this case, the existing machine trust account is used to join the machine - to the domain. - </p><p> - If the machine trust account is to be created - on-the-fly, on the Identification Changes menu enter the domain - name, and check the box <span class="guilabel">Create a Computer Account in the - Domain</span>. In this case, joining the domain proceeds as above - for Windows 2000 (i.e., you must supply a Samba administrative account when - prompted). - </p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2897121"></a>Samba</h4></div></div><div></div></div><p>Joining a Samba client to a domain is documented in - the <a href="domain-member.html#domain-member-server" title="Domain Member Server">Domain Member Server</a> section of this chapter chapter. - </p></div></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="domain-member-server"></a>Domain Member Server</h2></div></div><div></div></div><p> -This mode of server operation involves the Samba machine being made a member -of a domain security context. This means by definition that all user -authentication will be done from a centrally defined authentication regime. -The authentication regime may come from an NT3/4 style (old domain technology) -server, or it may be provided from an Active Directory server (ADS) running on -MS Windows 2000 or later. -</p><p> -<span class="emphasis"><em> -Of course it should be clear that the authentication back end itself could be -from any distributed directory architecture server that is supported by Samba. -This can be LDAP (from OpenLDAP), or Sun's iPlanet, of NetWare Directory -Server, etc. -</em></span> -</p><p> -Please refer to the <a href="samba-pdc.html" title="Chapter 5. Domain Control">Domain Control chapter</a> -for more information regarding how to create a domain -machine account for a domain member server as well as for information -regarding how to enable the Samba domain member machine to join the domain and -to be fully trusted by it. -</p><div xmlns:ns8="" class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2897196"></a>Joining an NT4 type Domain with Samba-3</h3></div></div><div></div></div><ns8:p> - </ns8:p><div class="table"><a name="id2897206"></a><p class="title"><b>Table 7.1. Assumptions</b></p><table summary="Assumptions" border="1"><colgroup><col><col></colgroup><tbody><tr><td align="left">NetBIOS name:</td><td align="left">SERV1</td></tr><tr><td align="left">Win2K/NT domain name:</td><td align="left">DOM</td></tr><tr><td align="left">Domain's PDC NetBIOS name:</td><td align="left">DOMPDC</td></tr><tr><td align="left">Domain's BDC NetBIOS names:</td><td align="left">DOMBDC1 and DOMBDC2</td></tr></tbody></table></div><ns8:p> -</ns8:p><p> -First, you must edit your <tt class="filename">smb.conf</tt> 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"> -<i class="parameter"><tt>security</tt></i></a> line in the [global] section -of your <tt class="filename">smb.conf</tt> to read: -</p><ns8:p> -</ns8:p><pre class="programlisting"> -security = domain -</pre><ns8:p> -</ns8:p><p> -Next change the <a href="smb.conf.5.html#WORKGROUP" target="_top"><i class="parameter"><tt> -workgroup</tt></i></a> line in the <i class="parameter"><tt>[global]</tt></i> -section to read: -</p><ns8:p> -</ns8:p><pre class="programlisting"> -workgroup = DOM -</pre><ns8:p> -</ns8: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"> -<i class="parameter"><tt>encrypt passwords</tt></i></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"> -<i class="parameter"><tt>password server</tt></i></a> line in the [global] -section to read: -</p><ns8:p> -</ns8:p><pre class="programlisting"> -password server = DOMPDC DOMBDC1 DOMBDC2 -</pre><ns8:p> -</ns8: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><ns8:p> -</ns8:p><pre class="programlisting"> -password server = * -</pre><ns8:p> -</ns8:p><p> -This method 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> -In order to actually join the domain, you must run this command: -</p><ns8:p> -</ns8:p><pre class="screen"> -<tt class="prompt">root# </tt><b class="userinput"><tt>net join -S DOMPDC -U<i class="replaceable"><tt>Administrator%password</tt></i></tt></b> -</pre><ns8:p> -</ns8:p><p> -If the <tt class="option">-S DOMPDC</tt> argument is not given then -the domain name will be obtained from <tt class="filename">smb.conf</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, we use it for the <tt class="option">-S</tt> option. -The <i class="replaceable"><tt>Administrator%password</tt></i> 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">Joined domain DOM.</tt> -or <tt class="computeroutput">Joined 'SERV1' to realm 'MYREALM'</tt> -</p><p> -in your terminal window. See the <a href="net.8.html" target="_top"> -net(8)</a> man page for more details. -</p><p> -This process joins the server to the domain without having to create the machine -trust account on the PDC beforehand. -</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/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> -Finally, restart your Samba daemons and get ready for -clients to begin using domain security! -</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2899872"></a>Why is this better than security = server?</h3></div></div><div></div></div><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" title="Chapter 21. Integrated Logon Support using Winbind">Winbind</a> chapter -for information on a system to automatically -assign UNIX uids and gids to Windows NT Domain users and groups. -</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 <i class="parameter"><tt>security = server</tt></i> 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 <i class="parameter"><tt>security = domain</tt></i>, -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. -</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> -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></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="ads-member"></a>Samba ADS Domain Membership</h2></div></div><div></div></div><p> -This is a rough guide to setting up Samba 3.0 with Kerberos authentication against a -Windows2000 KDC. A familiarity with Kerberos is assumed. -</p><div xmlns:ns9="" class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2900011"></a>Setup your <tt class="filename">smb.conf</tt></h3></div></div><div></div></div><p> -You must use at least the following 3 options in <tt class="filename">smb.conf</tt>: -</p><pre class="programlisting"> - realm = your.kerberos.REALM - security = ADS - encrypt passwords = yes -</pre><ns9:p> -In case samba can't figure out your ads server using your realm name, use the -<i class="parameter"><tt>ads server</tt></i> option in <tt class="filename">smb.conf</tt>: -</ns9:p><pre class="programlisting"> - ads server = your.kerberos.server -</pre><ns9:p> -</ns9:p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> -You do <span class="emphasis"><em>not</em></span> need a smbpasswd file, and older clients will be authenticated as -if <i class="parameter"><tt>security = domain</tt></i>, although it won't do any harm and -allows you to have local users not in the domain. It is expected that the above -required options will change soon when active directory integration will get -better. -</p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2900094"></a>Setup your <tt class="filename">/etc/krb5.conf</tt></h3></div></div><div></div></div><p> -The minimal configuration for <tt class="filename">krb5.conf</tt> is: -</p><pre class="programlisting"> - [libdefaults] - default_realm = YOUR.KERBEROS.REALM - - [realms] - YOUR.KERBEROS.REALM = { - kdc = your.kerberos.server - } -</pre><p> -Test your config by doing a <b class="userinput"><tt>kinit -<i class="replaceable"><tt>USERNAME</tt></i>@<i class="replaceable"><tt>REALM</tt></i></tt></b> and -making sure that your password is accepted by the Win2000 KDC. -</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> -The realm must be uppercase or you will get <span class="errorname">Cannot find KDC for -requested realm while getting initial credentials</span> error. -</p></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> -Time between the two servers must be synchronized. You will get a -<span class="errorname">kinit(v5): Clock skew too great while getting initial credentials</span> -if the time difference is more than five minutes. -</p></div><p> -You also must ensure that you can do a reverse DNS lookup on the IP -address of your KDC. Also, the name that this reverse lookup maps to -must either be the NetBIOS name of the KDC (ie. the hostname with no -domain attached) or it can alternatively be the NetBIOS name -followed by the realm. -</p><p> -The easiest way to ensure you get this right is to add a -<tt class="filename">/etc/hosts</tt> entry mapping the IP address of your KDC to -its NetBIOS name. If you don't get this right then you will get a -<span class="errorname">local error</span> when you try to join the realm. -</p><p> -If all you want is Kerberos support in <span class="application">smbclient</span> then you can skip -straight to <a href="domain-member.html#ads-test-smbclient" title="Testing with smbclient">Test with <span class="application">smbclient</span></a> now. -<a href="domain-member.html#ads-create-machine-account" title="Create the computer account">Creating a computer account</a> -and <a href="domain-member.html#ads-test-server" title="Test your server setup">testing your servers</a> -is only needed if you want Kerberos support for <span class="application">smbd</span> and <span class="application">winbindd</span>. -</p></div><div xmlns:ns10="" class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="ads-create-machine-account"></a>Create the computer account</h3></div></div><div></div></div><ns10:p> -As a user that has write permission on the Samba private directory -(usually root) run: -</ns10:p><pre class="programlisting"> - <tt class="prompt">root# </tt><b class="userinput"><tt>net join -U Administrator%password</tt></b> -</pre><ns10:p> -</ns10:p><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2900292"></a>Possible errors</h4></div></div><div></div></div><ns10:p> -</ns10:p><div class="variablelist"><dl><dt><span class="term"><span class="errorname">ADS support not compiled in</span></span></dt><dd><p>Samba must be reconfigured (remove config.cache) and recompiled - (make clean all install) after the Kerberos libs and headers are installed. - </p></dd><dt><span class="term"><span class="errorname">net join prompts for user name</span></span></dt><dd><p>You need to login to the domain using <b class="userinput"><tt>kinit - <i class="replaceable"><tt>USERNAME</tt></i>@<i class="replaceable"><tt>REALM</tt></i></tt></b>. - <i class="replaceable"><tt>USERNAME</tt></i> must be a user who has rights to add a machine - to the domain. </p></dd></dl></div><ns10:p> -</ns10:p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="ads-test-server"></a>Test your server setup</h3></div></div><div></div></div><p> -If the join was successful, you will see a new computer account with the -NetBIOS name of your Samba server in Active Directory (in the "Computers" -folder under Users and Computers. -</p><p> -On a Windows 2000 client try <b class="userinput"><tt>net use * \\server\share</tt></b>. You should -be logged in with Kerberos without needing to know a password. If -this fails then run <b class="userinput"><tt>klist tickets</tt></b>. Did you get a ticket for the -server? Does it have an encoding type of DES-CBC-MD5 ? -</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="ads-test-smbclient"></a>Testing with <span class="application">smbclient</span></h3></div></div><div></div></div><p> -On your Samba server try to login to a Win2000 server or your Samba -server using <span class="application">smbclient</span> and Kerberos. Use <span class="application">smbclient</span> as usual, but -specify the <i class="parameter"><tt>-k</tt></i> option to choose Kerberos authentication. -</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2900442"></a>Notes</h3></div></div><div></div></div><p> -You must change administrator password at least once after DC -install, to create the right encoding types -</p><p> -W2k doesn't seem to create the _kerberos._udp and _ldap._tcp in -their defaults DNS setup. Maybe fixed in service packs? -</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2900464"></a>Common Errors</h2></div></div><div></div></div><p> -In the process of adding / deleting / re-adding domain member machine accounts there are -many traps for the unwary player and there are many “<span class="quote">little</span>” things that can go wrong. -It is particularly interesting how often subscribers on the samba mailing list have concluded -after repeated failed attempts to add a machine account that it is necessary to "re-install" -MS Windows on t he machine. In truth, it is seldom necessary to reinstall because of this type -of problem. The real solution is often very simple, and with understanding of how MS Windows -networking functions. easily overcome. -</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2900491"></a>Can Not Add Machine Back to Domain</h3></div></div><div></div></div><p> -<span class="emphasis"><em>Problem:</em></span> A Windows workstation was reinstalled. The original domain machine -account was deleted and added immediately. The workstation will not join the domain if I use -the same machine name. Attempts to add the machine fail with a message that the machine already -exists on the network - I know it doesn't. Why is this failing? -</p><p> -The original name is still in the NetBIOS name cache and must expire after machine account -deletion BEFORE adding that same name as a domain member again. The best advice is to delete -the old account and then to add the machine with a new name. -</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2900523"></a>Adding Machine to Domain Fails</h3></div></div><div></div></div><p> -Adding a Windows 200x or XP Professional machine to the Samba PDC Domain fails with a -message that, <span class="errorname">The machine could not be added at this time, there is a network problem. -Please try again later.</span> Why? -</p><p> -You should check that there is an <i class="parameter"><tt>add machine script</tt></i> in your <tt class="filename">smb.conf</tt> -file. If there is not, please add one that is appropriate for your OS platform. If a script -has been defined you will need to debug it's operation. Increase the <i class="parameter"><tt>log level</tt></i> -in the <tt class="filename">smb.conf</tt> file to level 10, then try to rejoin the domain. Check the logs to see which -operation is failing. -</p><p> -Possible causes include: -</p><div class="itemizedlist"><ul type="disc"><li><p> - The script does not actually exist, or could not be located in the path specified. - </p><p> - <span class="emphasis"><em>Corrective Action:</em></span> Fix it. Make sure that when run manually - that the script will add both the Unix system account _and_ the Samba SAM account. - </p></li><li><p> - The machine could not be added to the Unix system accounts file <tt class="filename">/etc/passwd</tt> - </p><p> - <span class="emphasis"><em>Corrective Action:</em></span> Check that the machine name is a legal Unix - system account name. ie: If the Unix utility <b class="command">useradd</b> is called - then make sure that the machine name you are trying to add can be added using this - tool. <b class="command">Useradd</b> on some systems will not allow any upper case characters - nor will it allow spaces in the name. - </p></li></ul></div></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="samba-bdc.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="type.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="StandAloneServer.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 6. Backup Domain Control </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 8. Stand-Alone Servers</td></tr></table></div></body></html> |