diff options
Diffstat (limited to 'docs/htmldocs/domain-member.html')
| -rw-r--r-- | docs/htmldocs/domain-member.html | 609 |
1 files changed, 609 insertions, 0 deletions
diff --git a/docs/htmldocs/domain-member.html b/docs/htmldocs/domain-member.html new file mode 100644 index 0000000000..2d73b7c616 --- /dev/null +++ b/docs/htmldocs/domain-member.html @@ -0,0 +1,609 @@ +<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 class="author"><h3 class="author"><span class="firstname">Guenther</span> <span class="surname">Deschner</span></h3><span class="contrib">LDAP updates</span><div class="affiliation"><span class="orgname">SuSE<br></span><div class="address"><p><tt class="email"><<a href="mailto:gd@suse.de">gd@suse.de</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#id2893185">Features and Benefits</a></dt><dt><a href="domain-member.html#machine-trust-accounts">MS Windows Workstation/Server Machine Trust Accounts</a></dt><dd><dl><dt><a href="domain-member.html#id2893524">Manual Creation of Machine Trust Accounts</a></dt><dt><a href="domain-member.html#id2893846">Managing Domain Machine Accounts using NT4 Server Manager</a></dt><dt><a href="domain-member.html#id2894113">On-the-Fly Creation of Machine Trust Accounts</a></dt><dt><a href="domain-member.html#id2894194">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#id2894418">Joining an NT4-type Domain with Samba-3</a></dt><dt><a href="domain-member.html#id2894926">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#id2895131">Configure smb.conf</a></dt><dt><a href="domain-member.html#id2895267">Configure /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">Testing Server Setup</a></dt><dt><a href="domain-member.html#ads-test-smbclient">Testing with smbclient</a></dt><dt><a href="domain-member.html#id2895840">Notes</a></dt></dl></dd><dt><a href="domain-member.html#id2895877">Sharing User ID Mappings between Samba Domain Members</a></dt><dt><a href="domain-member.html#id2896009">Common Errors</a></dt><dd><dl><dt><a href="domain-member.html#id2896038">Cannot Add Machine Back to Domain</a></dt><dt><a href="domain-member.html#id2896072">Adding Machine to Domain Fails</a></dt><dt><a href="domain-member.html#id2896237">I Can't Join a Windows 2003 PDC</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 able to offer a viable option for many users. +</p><p> +This chapter covers background information pertaining to Domain Membership, +the 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 +misinformation, 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="id2893185"></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> +<a class="indexterm" name="id2893226"></a> +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. Domain Membership has many advantages: +</p><div class="itemizedlist"><ul type="disc"><li><p> +<a class="indexterm" name="id2893250"></a> + 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 Security Account Manager (SAM) 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 backended with an + LDAP directory, or via an Active Directory infrastructure). + </p></li></ul></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="machine-trust-accounts"></a>MS Windows Workstation/Server Machine Trust Accounts</h2></div></div><div></div></div><p> +<a class="indexterm" name="id2893338"></a> +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 “<span class="quote">Computer Account.</span>” The purpose of the machine account +is to prevent a rogue user and Domain Controller from colluding to gain access to a +domain member workstation. +</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. A Samba PDC, however, stores +each Machine Trust Account in two parts, +as follows: + +</p><div class="itemizedlist"><ul type="disc"><li><p> + A Domain Security Account (stored in the + <a class="indexterm" name="id2893387"></a><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 + that 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 ldapsam, and + tdbsam. 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 implemented. + </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><p> +</p><p> +<a class="indexterm" name="id2893465"></a> +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> + <a class="indexterm" name="id2893494"></a> + 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 as long as the user is + logged on as the administrator account. + </p></li><li><p> + “<span class="quote">On-the-fly</span>” 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="id2893524"></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 “<span class="quote">add user</span>” command +that is normally used to create new UNIX accounts. The following is an example for +a Linux-based Samba server: +</p><p> +<a class="indexterm" name="id2893561"></a> +<a class="indexterm" name="id2893570"></a> +</p><pre class="screen"> +<tt class="prompt">root# </tt><b class="userinput"><tt>/usr/sbin/useradd -g machines -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> + +<tt class="prompt">root# </tt><b class="userinput"><tt>passwd -l <i class="replaceable"><tt>machine_name</tt></i>$</tt></b> +</pre><p> +</p><p>In the above example above there is an existing system group “<span class="quote">machines</span>” which is used +as the primary group for all machine accounts. In the following examples the “<span class="quote">machines</span>” group has +numeric GID equal 100.</p><p> +<a class="indexterm" name="id2893643"></a> +On *BSD systems, this can be done using the <b class="command">chpass</b> utility: +</p><p> +</p><pre class="screen"> +<tt class="prompt">root# </tt><b class="userinput"><tt>chpass -a \ +'<i class="replaceable"><tt>machine_name</tt></i>$:*:101:100::0:0:Windows <i class="replaceable"><tt>machine_name</tt></i>:/dev/null:/sbin/nologin'</tt></b> +</pre><p> +</p><p> +The <tt class="filename">/etc/passwd</tt> entry will list the machine name +with a “<span class="quote">$</span>” appended, will not have a password, will have a null shell and no +home directory. For example, a machine named “<span class="quote">doppy</span>” would have an +<tt class="filename">/etc/passwd</tt> entry like this: +</p><pre class="programlisting"> +doppy$:x:505:100:<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 “<span class="quote">$</span>” 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 +<b class="command">smbpasswd</b> command +as shown here: +</p><p> +</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><p> +</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 +<a class="indexterm" name="id2893821"></a> +the <span class="application">Server Manager</span>. From the time at which the +account is created to the time 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="id2893846"></a>Managing Domain Machine Accounts using NT4 Server Manager</h3></div></div><div></div></div><p> +A working <a class="indexterm" name="id2893857"></a><i class="parameter"><tt>add machine script</tt></i> script is essential +for machine trust accounts to be automatically created. This applies no matter whether +one uses automatic account creation, or if one wishes to use the NT4 Domain Server Manager. +</p><p> +<a class="indexterm" name="id2893879"></a> +If the machine from which you are trying to manage the domain is an +<span class="application">MS Windows NT4 workstation or MS Windows 200x/XP Professional</span>, +the tool of choice is the package called <b class="command">SRVTOOLS.EXE</b>. +When executed in the target directory it will unpack <b class="command">SrvMgr.exe</b> +and <b class="command">UsrMgr.exe</b> (both are domain management tools for MS Windows NT4 workstation). +</p><p> +<a class="indexterm" name="id2893924"></a> +If your workstation is a <span class="application">Microsoft Windows 9x/Me</span> family 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 +this platform. +</p><p> +Further information about these tools may be obtained from the following locations: +</p><p> +</p><table class="simplelist" border="0" summary="Simple list"><tr><td><ulink url="http://support.microsoft.com/default.aspx?scid=kb;en-us;173673">http://support.microsoft.com/default.aspx?scid=kb;en-us;173673</ulink></td></tr><tr><td><ulink url="http://support.microsoft.com/default.aspx?scid=kb;en-us;172540">http://support.microsoft.com/default.aspx?scid=kb;en-us;172540</ulink></td></tr></table><p> +</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 <span class="guimenuitem">Select Domain</span>. + </p></li><li><p> + Click 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 the radio button to + <span class="guilabel">Add NT Workstation of Server</span>, then + enter the machine name in the field provided, and 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="id2894113"></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 +add machine script option in <tt class="filename">smb.conf</tt>. This method is not required, however, corresponding UNIX +accounts may also be created manually. +</p><p> +Here is an example for a Red Hat Linux system. +</p><table class="simplelist" border="0" summary="Simple list"><tr><td> </td></tr><tr><td><i class="parameter"><tt>[global]</tt></i></td></tr><tr><td># <...remainder of parameters...></td></tr><tr><td><i class="parameter"><tt>add machine script = /usr/sbin/useradd -d /dev/null -g 100 \</tt></i></td></tr><tr><td><i class="parameter"><tt> -s /bin/false -M %u</tt></i></td></tr></table></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2894194"></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 or 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="id2894206"></a>Windows 200x/XP Professional Client</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 Administrator Account (i.e., a Samba account that has <tt class="constant">root</tt> privileges on the + Samba server) must be entered here; the operation will fail if an ordinary user + account is given. + </p><p> + For security reasons, the password for this Administrator Account should be set + to a password that is other than that used for the root user in <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 <tt class="constant">root</tt> + then this is easily mapped to <tt class="constant">root</tt> in the file named in the <tt class="filename">smb.conf</tt> parameter + <a class="indexterm" name="id2894264"></a><i class="parameter"><tt>username map</tt></i> = /etc/samba/smbusers. + </p><p> + The session key of the Samba Administrator 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="id2894288"></a>Windows NT4 Client</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 Administrator Account when + prompted). + </p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2894329"></a>Samba Client</h4></div></div><div></div></div><p>Joining a Samba client to a domain is documented in + <link linkend="domain-member-server">. + </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 backend itself could be +from any distributed directory architecture server that is supported by Samba. +This can be LDAP (from OpenLDAP), or Sun's iPlanet, or NetWare Directory +Server, and so on. +</em></span> +</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3> +When Samba is configured to use an LDAP, or other identity management and/or +directory service, it is Samba that continues to perform user and machine +authentication. It should be noted that the LDAP server does not perform +authentication handling in place of what Samba is designed to do. +</div><p> +Please refer to <link linkend="samba-pdc">, for more information regarding +how to create a domain machine account for a Domain Member server as well as for +information on how to enable the Samba Domain Member machine to join the domain +and be fully trusted by it. +</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2894418"></a>Joining an NT4-type Domain with Samba-3</h3></div></div><div></div></div><p><link linkend="assumptions"> lists names that have been used in the remainder of this chapter.</p><div class="table"><a name="assumptions"></a><p class="title"><b>Table 7.1. Assumptions</b></p><table summary="Assumptions" border="1"><colgroup><col align="right"><col align="left"></colgroup><tbody><tr><td align="right">NetBIOS name:</td><td align="left">SERV1</td></tr><tr><td align="right">Windows 200x/NT domain name:</td><td align="left">MIDEARTH</td></tr><tr><td align="right">Domain's PDC NetBIOS name:</td><td align="left">DOMPDC</td></tr><tr><td align="right">Domain's BDC NetBIOS names:</td><td align="left">DOMBDC1 and DOMBDC2</td></tr></tbody></table></div><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 class="indexterm" name="id2894532"></a><i class="parameter"><tt>security</tt></i> line in the [global] section +of your <tt class="filename">smb.conf</tt> to read: +</p><p> +</p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>security = domain</tt></i></td></tr></table><p> +</p><p> +Next change the <a class="indexterm" name="id2894576"></a><i class="parameter"><tt>workgroup</tt></i> line in the <i class="parameter"><tt>[global]</tt></i> +section to read: +</p><p> +</p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>workgroup = MIDEARTH</tt></i></td></tr></table><p> +</p><p> +This is the name of the domain we are joining. +</p><p> +You must also have the parameter <a class="indexterm" name="id2894625"></a><i class="parameter"><tt>encrypt passwords</tt></i> +set to <tt class="constant">yes</tt> in order for your users to authenticate to the NT PDC. +This is the defaulty setting if this parameter is not specified. There is no need to specify this +parameter, but if it is specified in the <tt class="filename">smb.conf</tt> file, it must be set to <tt class="constant">Yes</tt>. +</p><p> +Finally, add (or modify) a <a class="indexterm" name="id2894664"></a><i class="parameter"><tt>password server</tt></i> line in the [global] +section to read: +</p><p> +</p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>password server = DOMPDC DOMBDC1 DOMBDC2</tt></i></td></tr></table><p> +</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> +Alternately, 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> +</p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>password server = *</tt></i></td></tr></table><p> +</p><p> +This method allows Samba to use exactly the same mechanism that NT does. The +method either uses broadcast-based name resolution, performs a WINS database +lookup in order to find a Domain Controller against which to authenticate, +or locates the Domain Controller using DNS name resolution. +</p><p> +To join the domain, run this command: +</p><p> +</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><p> +</p><p> +If the <tt class="option">-S DOMPDC</tt> argument is not given, the domain name will be obtained from <tt class="filename">smb.conf</tt>. +</p><p> +The machine is joining the domain DOM, and the PDC for that domain (the only machine +that has write access to the domain SAM database) is DOMPDC, therefore use 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 that has the necessary privilege to add machines to the +domain. If this is successful, you will see the message in your terminal window the +text shown below. Where the older NT4 style domain architecture is used: +</p><pre class="screen"> +<tt class="computeroutput">Joined domain DOM.</tt> +</pre><p> +</p><p> +Where Active Directory is used: +</p><pre class="screen"> +<tt class="computeroutput">Joined SERV1 to realm MYREALM.</tt> +</pre><p> +</p><p> +Refer to the <b class="command">net</b> man page for further information. +</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 a smbpasswd file would be normally stored: +</p><pre class="screen"> +<tt class="filename">/usr/local/samba/private/secrets.tdb</tt> +or +<tt class="filename">/etc/samba/secrets.tdb</tt>. +</pre><p> +</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. The way you can restart your Samba daemons depends on your distribution, +but in most cases the following will suffice: +</p><pre class="screen"> +<tt class="prompt">root# </tt>/etc/init.d/samba restart +</pre><p> +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2894926"></a>Why Is This Better Than <i class="parameter"><tt>security = server</tt></i>?</h3></div></div><div></div></div><p> +Currently, domain security in Samba does not 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 +file system. This is similar to the older Samba security mode +<a class="indexterm" name="id2894953"></a><i class="parameter"><tt>security</tt></i> = 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. +</p><p> +Please refer to <link linkend="winbind">, 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 <a class="indexterm" name="id2894999"></a><i class="parameter"><tt>security</tt></i> = 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 <a class="indexterm" name="id2895018"></a><i class="parameter"><tt>security</tt></i> = 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. +</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, and so on. +</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 +<ulink url="http://www.linuxworld.com">LinuxWorld</ulink> as the article <ulink url="http://www.linuxworld.com/linuxworld/lw-1998-10/lw-10-samba.html">http://www.linuxworld.com/linuxworld/lw-1998-10/lw-10-samba.html</ulink> +<span class="emphasis"><em>Doing the NIS/NT Samba</em></span>. +</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> +<a class="indexterm" name="id2895091"></a> +<a class="indexterm" name="id2895100"></a> +<a class="indexterm" name="id2895111"></a> +<a class="indexterm" name="id2895119"></a> +This is a rough guide to setting up Samba-3 with Kerberos authentication against a +Windows 200x KDC. A familiarity with Kerberos is assumed. +</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2895131"></a>Configure <tt class="filename">smb.conf</tt></h3></div></div><div></div></div><p> +You must use at least the following three options in <tt class="filename">smb.conf</tt>: +</p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>realm = your.kerberos.REALM</tt></i></td></tr><tr><td><i class="parameter"><tt>security = ADS</tt></i></td></tr><tr><td># The following parameter need only be specified if present.</td></tr><tr><td># The default setting is not present is Yes.</td></tr><tr><td><i class="parameter"><tt>encrypt passwords = yes</tt></i></td></tr></table><p> +In case samba cannot correctly identify the appropriate ADS server using the realm name, use the +<a class="indexterm" name="id2895201"></a><i class="parameter"><tt>password server</tt></i> option in <tt class="filename">smb.conf</tt>: +</p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>password server = your.kerberos.server</tt></i></td></tr></table><p> +</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 <a class="indexterm" name="id2895249"></a><i class="parameter"><tt>security</tt></i> = domain, although it will not do any harm and +allows you to have local users not in the domain. +</p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2895267"></a>Configure <tt class="filename">/etc/krb5.conf</tt></h3></div></div><div></div></div><p> +<a class="indexterm" name="id2895283"></a> +<a class="indexterm" name="id2895292"></a> +With both MIT and Heimdal Kerberos, this is unnecessary, and may be detrimental. All ADS +domains will automatically create SRV records in the DNS zone <i class="parameter"><tt>_kerberos.REALM.NAME</tt></i> for +each KDC in the realm. MIT's, as well as Heimdal's, KRB5 libraries default to checking +for these records, so they will automatically find the KDCs. In addition, +<tt class="filename">krb5.conf</tt> only allows specifying a single KDC, even there if there is more +than one. Using the DNS lookup allows the KRB5 libraries to use whichever KDCs are available. +</p><p> +When manually configuring <tt class="filename">krb5.conf</tt>, the minimal configuration is: +</p><pre class="programlisting"> +[libdefaults] + default_realm = YOUR.KERBEROS.REALM + + [realms] + YOUR.KERBEROS.REALM = { + kdc = your.kerberos.server + } +</pre><p> +When using Heimdal versions before 0.6 use the following configuration settings: +</p><pre class="screen"> +[libdefaults] + default_realm = YOUR.KERBEROS.REALM + default_etypes = des-cbc-crc des-cbc-md5 + default_etypes_des = des-cbc-crc des-cbc-md5 + + [realms] + YOUR.KERBEROS.REALM = { + kdc = your.kerberos.server + } +</pre><p> +</p><p> +<a class="indexterm" name="id2895372"></a> +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><p> +With Heimdal versions earlier than 0.6.x you only can use newly created accounts +in ADS or accounts that have had the password changed once after migration, or +in case of <tt class="constant">Administrator</tt> after installation. At the +moment, a Windows 2003 KDC can only be used with a Heimdal releases later than 0.6 +(and no default etypes in krb5.conf). Unfortunatly this whole area is still +in a state of flux. +</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> +The realm must be in uppercase or you will get “<span class="quote"><span class="errorname">Cannot find KDC for +requested realm while getting initial credentials</span></span>” error (Kerberos +is case-sensitive!). +</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="quote"><span class="errorname">kinit(v5): Clock skew too great while getting initial credentials</span></span>” +if the time difference is more than five minutes. +</p></div><p> +Clock skew limits are configurable in the Kerberos protocols. The default setting is +five minutes. +</p><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 (i.e., the hostname with no +domain attached) or it can alternately 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 do not get this correct 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 +directly to <link linkend="ads-test-smbclient"> now. +<link linkend="ads-create-machine-account"> and <link linkend="ads-test-server"> +are needed only if you want Kerberos support for <span class="application">smbd</span> and <span class="application">winbindd</span>. +</p></div><div 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><p> +As a user who has write permission on the Samba private directory (usually root), run: +</p><pre class="screen"> +<tt class="prompt">root# </tt> <b class="userinput"><tt>net ads join -U Administrator%password</tt></b> +</pre><p> +</p><p> +When making a Windows client a member of an ADS domain within a complex organization, you +may want to create the machine account within a particular organizational unit. Samba-3 permits +this to be done using the following syntax: +</p><pre class="screen"> +<tt class="prompt">root# </tt> <b class="userinput"><tt>kinit Administrator@your.kerberos.REALM</tt></b> +<tt class="prompt">root# </tt> <b class="userinput"><tt>net ads join “<span class="quote">organizational_unit</span>”</tt></b> +</pre><p> +</p><p> +For example, you may want to create the machine account in a container called “<span class="quote">Servers</span>” +under the organizational directory “<span class="quote">Computers\BusinessUnit\Department</span>” like this: +</p><pre class="screen"> +<tt class="prompt">root# </tt> <b class="userinput"><tt>net ads join "Computers\BusinessUnit\Department\Servers"</tt></b> +</pre><p> +</p><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2895653"></a>Possible Errors</h4></div></div><div></div></div><p> +</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 libiraries and headers files are installed. + </p></dd><dt><span class="term"><span class="errorname">net ads 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><dt><span class="term">Unsupported encryption/or checksum types</span></dt><dd><p> + Make sure that the <tt class="filename">/etc/krb5.conf</tt> is correctly configured + for the type and version of Kerberos installed on the system. + </p></dd></dl></div><p> +</p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="ads-test-server"></a>Testing 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 “<span class="quote">Computers</span>” +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 encryption type of DES-CBC-MD5? +</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3> +Samba can use both DES-CBC-MD5 encryption as well as ARCFOUR-HMAC-MD5 encoding. +</div></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> +<a class="indexterm" name="id2895811"></a> +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 <tt class="option">-k</tt> option to choose Kerberos authentication. +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2895840"></a>Notes</h3></div></div><div></div></div><p> +You must change administrator password at least once after DC +install, to create the right encryption types. +</p><p> +Windows 200x does not seem to create the <i class="parameter"><tt>_kerberos._udp</tt></i> and <i class="parameter"><tt>_ldap._tcp</tt></i> in +the default DNS setup. Perhaps this will be fixed later in service packs. +</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2895877"></a>Sharing User ID Mappings between Samba Domain Members</h2></div></div><div></div></div><p> +Samba maps UNIX users and groups (identified by UIDs and GIDs) to Windows users and groups (identified by SIDs). +These mappings are done by the <i class="parameter"><tt>idmap</tt></i> subsystem of Samba. +</p><p> +In some cases it is useful to share these mappings between Samba Domain Members, +so <span class="emphasis"><em>name->id</em></span> mapping is identical on all machines. +This may be needed in particular when sharing files over both CIFS and NFS. +</p><p>To use the <span class="emphasis"><em>LDAP</em></span> <i class="parameter"><tt>ldap idmap suffix</tt></i>, set:</p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>ldap idmap suffix = ou=Idmap,dc=quenya,dc=org</tt></i></td></tr></table><p>See the <tt class="filename">smb.conf</tt> man page entry for the <a class="indexterm" name="id2895952"></a><i class="parameter"><tt>ldap idmap suffix</tt></i> +parameter for further information.</p><p> +Do not forget to specify also the <a class="indexterm" name="id2895971"></a><i class="parameter"><tt>ldap admin dn</tt></i> +and to make certain to set the LDAP administrative password into the <tt class="filename">secrets.tdb</tt> using: +</p><pre class="screen"> +<tt class="prompt">root# </tt> smbpasswd -w ldap-admin-password +</pre></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2896009"></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 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 “<span class="quote">re-install</span>” +MS Windows on the machine. In truth, it is seldom necessary to reinstall because of this type +of problem. The real solution is often quite simple and with an understanding of how MS Windows +networking functions, it is easy to overcome. +</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2896038"></a>Cannot Add Machine Back to Domain</h3></div></div><div></div></div><p> +“<span class="quote">A Windows workstation was re-installed. 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 does not. Why is this failing?</span>” +</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 add the machine with a new name. +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2896072"></a>Adding Machine to Domain Fails</h3></div></div><div></div></div><p> +“<span class="quote">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?</span>” +</p><p> +You should check that there is an <a class="indexterm" name="id2896099"></a><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 its operation. Increase the <a class="indexterm" name="id2896124"></a><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 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. 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><p> +The <a class="indexterm" name="id2896217"></a><i class="parameter"><tt>add machine script</tt></i> does not create the +machine account in the Samba backend database, it is there only to create a UNIX system +account to which the Samba backend database account can be mapped. +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2896237"></a>I Can't Join a Windows 2003 PDC</h3></div></div><div></div></div><p>Windows 2003 requires SMB signing. Client side SMB signing has been implemented in Samba-3.0. + Set <a class="indexterm" name="id2896249"></a><i class="parameter"><tt>client use spnego</tt></i> = yes when communicating + with a Windows 2003 server.</p></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> |