diff options
| author | Gerald Carter <jerry@samba.org> | 2003-10-10 16:46:22 +0000 |
|---|---|---|
| committer | Gerald Carter <jerry@samba.org> | 2003-10-10 16:46:22 +0000 |
| commit | fec4b31bc1a76e408732e1a80b366d97fcf38143 (patch) | |
| tree | e23398c2bcc4e3b2da28c8007ca453228aefb44f /docs/htmldocs/domain-member.html | |
| parent | 20c7b998a38424e8e7b4d218f923937b9e8862d4 (diff) | |
| download | samba-fec4b31bc1a76e408732e1a80b366d97fcf38143.tar.gz samba-fec4b31bc1a76e408732e1a80b366d97fcf38143.tar.bz2 samba-fec4b31bc1a76e408732e1a80b366d97fcf38143.zip | |
removing docs tree from 3.0
(This used to be commit 0a3eb5574c91685ab07436c67b031266fb329693)
Diffstat (limited to 'docs/htmldocs/domain-member.html')
| -rw-r--r-- | docs/htmldocs/domain-member.html | 609 |
1 files changed, 0 insertions, 609 deletions
diff --git a/docs/htmldocs/domain-member.html b/docs/htmldocs/domain-member.html deleted file mode 100644 index 2d73b7c616..0000000000 --- a/docs/htmldocs/domain-member.html +++ /dev/null @@ -1,609 +0,0 @@ -<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> |