diff options
Diffstat (limited to 'docs/Samba-Guide')
| -rw-r--r-- | docs/Samba-Guide/SBE-AddingUNIXClients.xml | 347 |
1 files changed, 139 insertions, 208 deletions
diff --git a/docs/Samba-Guide/SBE-AddingUNIXClients.xml b/docs/Samba-Guide/SBE-AddingUNIXClients.xml index 28311f0a9a..8950cdb714 100644 --- a/docs/Samba-Guide/SBE-AddingUNIXClients.xml +++ b/docs/Samba-Guide/SBE-AddingUNIXClients.xml @@ -190,41 +190,32 @@ casual user. </para></listitem> - <listitem><para><indexterm> - <primary>winbind enable local accounts</primary> - </indexterm><indexterm> - <primary>Domain Member</primary> - <secondary>servers</secondary> - </indexterm><indexterm> - <primary>Domain Controllers</primary> - </indexterm> + <listitem><para> + <indexterm><primary>winbind enable local accounts</primary></indexterm> + <indexterm><primary>Domain Member</primary><secondary>servers</secondary></indexterm> + <indexterm><primary>Domain Controllers</primary></indexterm> If you wish to make use of accounts (users and/or groups) that are local to (i.e., capable of being resolved using) the NSS facility, it is imperative to use the <smbconfoption name="winbind enable local accounts">Yes</smbconfoption> in the &smb.conf; file. This parameter specifically applies only to domain controllers, not to domain member servers. </para></listitem> + </itemizedlist> - <para><indexterm> - <primary>Posix accounts</primary> - </indexterm><indexterm> - <primary>Samba accounts</primary> - </indexterm><indexterm> - <primary>LDAP</primary> - </indexterm> + <para> + <indexterm><primary>Posix accounts</primary></indexterm> + <indexterm><primary>Samba accounts</primary></indexterm> + <indexterm><primary>LDAP</primary></indexterm> For many administrators, it should be plain that the use of an LDAP-based repository for all network accounts (both for POSIX accounts and for Samba accounts) provides the most elegant and controllable facility. You eventually appreciate the decision to use LDAP. </para> - <para><indexterm> - <primary>nss_ldap</primary> - </indexterm><indexterm> - <primary>identifiers</primary> - </indexterm><indexterm> - <primary>resolve</primary> - </indexterm> + <para> + <indexterm><primary>nss_ldap</primary></indexterm> + <indexterm><primary>identifiers</primary></indexterm> + <indexterm><primary>resolve</primary></indexterm> If your network account information resides in an LDAP repository, you should use it ahead of any alternative method. This means that if it is humanly possible to use the <command>nss_ldap</command> tools to resolve UNIX account UIDs/GIDs via LDAP, this is the preferred solution, because it provides @@ -232,20 +223,13 @@ throughout the network. </para> - <para><indexterm> - <primary>Domain Member</primary> - <secondary>server</secondary> - </indexterm><indexterm> - <primary>winbind trusted domains only</primary> - </indexterm><indexterm> - <primary>getpwnam</primary> - </indexterm><indexterm> - <primary>smbd</primary> - </indexterm><indexterm> - <primary>Trusted Domains</primary> - </indexterm><indexterm> - <primary>External Domains</primary> - </indexterm> + <para> + <indexterm><primary>Domain Member</primary><secondary>server</secondary></indexterm> + <indexterm><primary>winbind trusted domains only</primary></indexterm> + <indexterm><primary>getpwnam</primary></indexterm> + <indexterm><primary>smbd</primary></indexterm> + <indexterm><primary>Trusted Domains</primary></indexterm> + <indexterm><primary>External Domains</primary></indexterm> In the situation where UNIX accounts are held on the domain member server itself, the only effective way to use them involves the &smb.conf; entry <smbconfoption name="winbind trusted domains only">Yes</smbconfoption>. This forces @@ -254,17 +238,12 @@ disables the use of Samba with trusted domains (i.e., external domains). </para> - <para><indexterm> - <primary>appliance mode</primary> - </indexterm><indexterm> - <primary>Domain Member</primary> - <secondary>server</secondary> - </indexterm><indexterm> - <primary>winbindd</primary> - </indexterm><indexterm> - <primary>automatically allocate</primary> - </indexterm> - Winbind can be used to create an appliance mode domain member server. In this capacity, <command>winbindd</command> + <para> + <indexterm><primary>appliance mode</primary></indexterm> + <indexterm><primary>Domain Member</primary><secondary>server</secondary></indexterm> + <indexterm><primary>winbindd</primary></indexterm> + <indexterm><primary>automatically allocate</primary></indexterm> + Winbind can be used to create an appliance mode domain member server. In this capacity, <command>winbindd</command> is configured to automatically allocate UIDs/GIDs from numeric ranges set in the &smb.conf; file. The allocation is made for all accounts that connect to that domain member server, whether within its own domain or from trusted domains. If not stored in an LDAP backend, each domain member maintains its own unique mapping database. @@ -273,9 +252,8 @@ is stored in the <filename>winbindd_idmap.tdb</filename> and <filename>winbindd_cache.tdb</filename> files. </para> - <para><indexterm> - <primary>mapping</primary> - </indexterm> + <para> + <indexterm><primary>mapping</primary></indexterm> The use of an LDAP backend for the Winbind IDMAP facility permits Windows domain SIDs mappings to UIDs/GIDs to be stored centrally. The result is a consistent mapping across all domain member servers so configured. This solves one of the major headaches for network administrators who need to copy @@ -287,16 +265,11 @@ <sect2> <title>Political Issues</title> - <para><indexterm> - <primary>OpenLDAP</primary> - </indexterm><indexterm> - <primary>NIS</primary> - </indexterm><indexterm> - <primary>yellow pages</primary> - <see>NIS</see> - </indexterm><indexterm> - <primary>identity management</primary> - </indexterm> + <para> + <indexterm><primary>OpenLDAP</primary></indexterm> + <indexterm><primary>NIS</primary></indexterm> + <indexterm><primary>yellow pages</primary><see>NIS</see></indexterm> + <indexterm><primary>identity management</primary></indexterm> One of the most fierce conflicts recently being waged is resistance to the adoption of LDAP, in particular OpenLDAP, as a replacement for UNIX NIS (previously called Yellow Pages). Let's face it, LDAP is different and requires a new approach to the need for a better identity management solution. The more @@ -311,11 +284,9 @@ commercial integration products. But it's not what Active Directory was designed for. </para> - <para><indexterm> - <primary>directory</primary> - </indexterm><indexterm> - <primary>management</primary> - </indexterm> + <para> + <indexterm><primary>directory</primary></indexterm> + <indexterm><primary>management</primary></indexterm> A number of long-term UNIX devotees have recently commented in various communications that the Samba Team is the first application group to almost force network administrators to use LDAP. It should be pointed out that we resisted this for as long as we could. It is not out of laziness or malice that LDAP has @@ -330,25 +301,18 @@ <sect1> <title>Implementation</title> - <para><indexterm> - <primary>Domain Member</primary> - <secondary>server</secondary> - </indexterm><indexterm> - <primary>Domain Member</primary> - <secondary>client</secondary> - </indexterm><indexterm> - <primary>Domain Controller</primary> - </indexterm> + <para> + <indexterm><primary>Domain Member</primary><secondary>server</secondary></indexterm> + <indexterm><primary>Domain Member</primary><secondary>client</secondary></indexterm> + <indexterm><primary>Domain Controller</primary></indexterm> The domain member server and the domain member client are at the center of focus in this chapter. Configuration of Samba-3 domain controller is covered in earlier chapters, so if your interest is in domain controller configuration, you will not find that here. You will find good oil that helps you to add domain member servers and clients. </para> - <para><indexterm> - <primary>Domain Member</primary> - <secondary>workstations</secondary> - </indexterm> + <para> + <indexterm><primary>Domain Member</primary><secondary>workstations</secondary></indexterm> In practice, domain member servers and domain member workstations are very different entities, but in terms of technology they share similar core infrastructure. A technologist would argue that servers and workstations are identical. Many users would argue otherwise, given that in a well-disciplined @@ -357,22 +321,18 @@ but a server is viewed as a core component of the business. </para> - <para><indexterm> - <primary>workstation</primary> - </indexterm> + <para> + <indexterm><primary>workstation</primary></indexterm> We can look at this another way. If a workstation breaks down, one user is affected, but if a server breaks down, hundreds of users may not be able to work. The services that a workstation must provide are document- and file-production oriented; a server provides information storage and is distribution oriented. </para> - <para><indexterm> - <primary>authentication process</primary> - </indexterm><indexterm> - <primary>logon process</primary> - </indexterm><indexterm> - <primary>user identities</primary> - </indexterm> + <para> + <indexterm><primary>authentication process</primary></indexterm> + <indexterm><primary>logon process</primary></indexterm> + <indexterm><primary>user identities</primary></indexterm> <emphasis>Why is this important?</emphasis> For starters, we must identify what components of the operating system and its environment must be configured. Also, it is necessary to recognize where the interdependencies between the various services to be used are. @@ -388,52 +348,52 @@ </para> <sect2 id="sdcsdmldap"> - <title>Samba Domain with Samba Domain Member Server &smbmdash; Using LDAP</title> + <title>Samba Domain with Samba Domain Member Server &smbmdash; Using NSS LDAP</title> - <para><indexterm> - <primary>ldapsam</primary> - </indexterm><indexterm> - <primary>ldapsam backend</primary> - </indexterm><indexterm> - <primary>IDMAP</primary> - </indexterm><indexterm> - <primary>mapping</primary> - <secondary>consistent</secondary> - </indexterm><indexterm> - <primary>winbindd</primary> - </indexterm><indexterm> - <primary>foreign SID</primary> - </indexterm> + <para> + <indexterm><primary>ldapsam</primary></indexterm> + <indexterm><primary>ldapsam backend</primary></indexterm> + <indexterm><primary>IDMAP</primary></indexterm> + <indexterm><primary>mapping</primary><secondary>consistent</secondary></indexterm> + <indexterm><primary>winbindd</primary></indexterm> + <indexterm><primary>foreign SID</primary></indexterm> In this example, it is assumed that you have Samba PDC/BDC servers. This means you are using an LDAP ldapsam backend. We are adding to the LDAP backend database (directory) containers for use by the IDMAP facility. This makes it possible to have globally consistent - mapping of SIDs to and from UIDs and GIDs. This means that you are running <command>winbindd</command> - as part of your configuration. The primary purpose of running <command>winbindd</command> (within - this operational context) is to permit mapping of foreign SIDs (those not originating from our - own domain). Foreign SIDs can come from any external domain or from Windows clients that do not - belong to a domain. + mapping of SIDs to and from UIDs and GIDs. This means that it is necessary to run + <command>winbindd</command> as part of your configuration. The primary purpose of running + <command>winbindd</command> (within this operational context) is to permit mapping of foreign + SIDs (those not originating from the the local Samba server). Foreign SIDs can come from any + domain member client or server, or from Windows clients that do not belong to a domain. Another + way to explain the necessity to run <command>winbindd</command> is that Samba can locally + resolve only accounts that belong to the security context of its own machine SID. Winbind + handles all non-local SIDs and maps them to a local UID/GID value. The UID and GID are allocated + from the parameter values set in the &smb.conf; file for the <parameter>idmap uid</parameter> and + <parameter>idmap gid</parameter> ranges. Where LDAP is used, the mappings can be stored in LDAP + so that all domain member servers can use a consistent mapping. </para> - <para><indexterm> - <primary>winbindd</primary> - </indexterm><indexterm> - <primary>getpwnam</primary> - </indexterm><indexterm> - <primary>NSS</primary> - </indexterm> - If your installation is accessed only from clients that are members of your own domain, then - it is not necessary to run <command>winbindd</command> as long as all users can be resolved - locally via the <command>getpwnam()</command> system call. On NSS-enabled systems, this condition - is met by having + <para> + <indexterm><primary>winbindd</primary></indexterm> + <indexterm><primary>getpwnam</primary></indexterm> + <indexterm><primary>NSS</primary></indexterm> + If your installation is accessed only from clients that are members of your own domain, and all + user accounts are present in a local passdb backend then it is not necessary to run + <command>winbindd</command>. The local passdb backend can be in smbpasswd, tdbsam, or in ldapsam. + </para> + + <para> + It is possible to use a local passdb backend with any convenient means of resolving the POSIX + user and group account information. The POSIX information is usually obtained using the + <command>getpwnam()</command> system call. On NSS-enabled systems, the actual POSIX account + source can be provided from </para> <itemizedlist> - <listitem><para><indexterm> - <primary>/etc/passwd</primary> - </indexterm><indexterm> - <primary>/etc/group</primary> - </indexterm> - All accounts in <filename>/etc/passwd</filename> or in <filename>/etc/group</filename>. + <listitem><para> + <indexterm><primary>/etc/passwd</primary></indexterm> + <indexterm><primary>/etc/group</primary></indexterm> + Accounts in <filename>/etc/passwd</filename> or in <filename>/etc/group</filename>. </para></listitem> <listitem><para> @@ -455,6 +415,12 @@ </para></listitem> </itemizedlist> + <note><para> + To advoid confusion the use of the term <literal>local passdb backend</literal> means that + the user account backend is not shared by any other Samba server &smbmdash; instead, it is + used only locally on the Samba domain member server under discussion. + </para></note> + <para> <indexterm><primary>Identity resolution</primary></indexterm> The diagram in <link linkend="ch9-sambadc"/> demonstrates the relationship of Samba and system @@ -467,11 +433,9 @@ <imagefile scale="60">chap9-SambaDC</imagefile> </image> - <para><indexterm> - <primary>IDMAP</primary> - </indexterm><indexterm> - <primary>foreign</primary> - </indexterm> + <para> + <indexterm><primary>IDMAP</primary></indexterm> + <indexterm><primary>foreign</primary></indexterm> In this example configuration, Samba will directly search the LDAP-based passwd backend ldapsam to obtain authentication and user identity information. The IDMAP information is stored in the LDAP backend so that it can be shared by all domain member servers so that every user will have a @@ -487,16 +451,15 @@ </para> <procedure> - <title>Configuration of LDAP-Based Identity Resolution</title> + <title>Configuration of NSS_LDAP-Based Identity Resolution</title> <step><para> Create the &smb.conf; file as shown in <link linkend="ch9-sdmsdc"/>. Locate this file in the directory <filename>/etc/samba</filename>. </para></step> - <step><para><indexterm> - <primary>ldap.conf</primary> - </indexterm> + <step><para> + <indexterm><primary>ldap.conf</primary></indexterm> Configure the file that will be used by <constant>nss_ldap</constant> to locate and communicate with the LDAP server. This file is called <filename>ldap.conf</filename>. If your implementation of <constant>nss_ldap</constant> is consistent with @@ -517,11 +480,9 @@ in <link linkend="ch9-sdmnss"/>. </para></step> - <step><para><indexterm> - <primary>Identity resolution</primary> - </indexterm><indexterm> - <primary>getent</primary> - </indexterm> + <step><para> + <indexterm><primary>Identity resolution</primary></indexterm> + <indexterm><primary>getent</primary></indexterm> Before proceeding to configure Samba, validate the operation of the NSS identity resolution via LDAP by executing: <screen> @@ -556,13 +517,9 @@ Finances:x:1001: PIOps:x:1002: sammy:x:4321: </screen> - <indexterm> - <primary>secondary group</primary> - </indexterm><indexterm> - <primary>primary group</primary> - </indexterm><indexterm> - <primary>group membership</primary> - </indexterm> + <indexterm><primary>secondary group</primary></indexterm> + <indexterm><primary>primary group</primary></indexterm> + <indexterm><primary>group membership</primary></indexterm> This shows that all is working as it should be. Notice that in the LDAP database the users' primary and secondary group memberships are identical. It is not necessary to add secondary group memberships (in the group database) if the @@ -571,9 +528,8 @@ sammy:x:4321: doubling up of group memberships and may break winbind under certain conditions. </para></step> - <step><para><indexterm> - <primary>slapcat</primary> - </indexterm> + <step><para> + <indexterm><primary>slapcat</primary></indexterm> The LDAP directory must have a container object for IDMAP data. There are several ways you can check that your LDAP database is able to receive IDMAP information. One of the simplest is to execute: @@ -582,11 +538,10 @@ sammy:x:4321: dn: ou=Idmap,dc=abmas,dc=biz ou: idmap </screen> - <indexterm> - <primary>ldapadd</primary> - </indexterm> - If the execution of this command does not return IDMAP entries, you need to create an LDIF - template file (see <link linkend="ch9-ldifadd"/>). You can add the required entries using the following command: + <indexterm><primary>ldapadd</primary></indexterm> + If the execution of this command does not return IDMAP entries, you need to create an LDIF + template file (see <link linkend="ch9-ldifadd"/>). You can add the required entries using + the following command: <screen> &rootprompt; ldapadd -x -D "cn=Manager,dc=abmas,dc=biz" \ -w not24get < /etc/openldap/idmap.LDIF @@ -594,13 +549,9 @@ ou: idmap Samba automatically populates this LDAP directory container when it needs to. </para></step> - <step><para><indexterm> - <primary>net</primary> - <secondary>rpc</secondary> - <tertiary>join</tertiary> - </indexterm><indexterm> - <primary>Domain join</primary> - </indexterm> + <step><para> + <indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>join</tertiary></indexterm> + <indexterm><primary>Domain join</primary></indexterm> The system is ready to join the domain. Execute the following: <screen> &rootprompt; net rpc join -U root%not24get @@ -817,16 +768,14 @@ aliases: files domain and/or does not use LDAP. </para> - <note><para><indexterm> - <primary>duplicate accounts</primary> - </indexterm> + <note><para> + <indexterm><primary>duplicate accounts</primary></indexterm> If you use <command>winbind</command> for identity resolution, make sure that there are no duplicate accounts. </para> - <para><indexterm> - <primary>/etc/passwd</primary> - </indexterm> + <para> + <indexterm><primary>/etc/passwd</primary></indexterm> For example, do not have more than one account that has UID=0 in the password database. If there is an account called <constant>root</constant> in the <filename>/etc/passwd</filename> database, it is okay to have an account called <constant>root</constant> in the LDAP ldapsam or in the @@ -835,29 +784,20 @@ aliases: files <constant>root</constant>. </para> - <para><indexterm> - <primary>/etc/passwd</primary> - </indexterm><indexterm> - <primary>ldapsam</primary> - </indexterm><indexterm> - <primary>tdbsam</primary> - </indexterm> + <para> + <indexterm><primary>/etc/passwd</primary></indexterm> + <indexterm><primary>ldapsam</primary></indexterm> + <indexterm><primary>tdbsam</primary></indexterm> Winbind will break if there is an account in <filename>/etc/passwd</filename> that has the same UID as an account that is in LDAP ldapsam (or in tdbsam) but that differs in name only. </para></note> - <para><indexterm> - <primary>credentials</primary> - </indexterm><indexterm> - <primary>traverse</primary> - </indexterm><indexterm> - <primary>wide-area</primary> - </indexterm><indexterm> - <primary>network</primary> - <secondary>wide-area</secondary> - </indexterm><indexterm> - <primary>tdbdump</primary> - </indexterm> + <para> + <indexterm><primary>credentials</primary></indexterm> + <indexterm><primary>traverse</primary></indexterm> + <indexterm><primary>wide-area</primary></indexterm> + <indexterm><primary>network</primary><secondary>wide-area</secondary></indexterm> + <indexterm><primary>tdbdump</primary></indexterm> The following configuration uses CIFS/SMB protocols alone to obtain user and group credentials. The winbind information is locally cached in the <filename>winbindd_cache.tdb winbindd_idmap.tdb</filename> files. This provides considerable performance benefits compared with the LDAP solution, particularly @@ -874,18 +814,14 @@ aliases: files shown in <link linkend="ch0-NT4DSDM"/>. </para></step> - <step><para><indexterm> - <primary>/etc/nsswitch.conf</primary> - </indexterm> + <step><para> + <indexterm><primary>/etc/nsswitch.conf</primary></indexterm> Edit the <filename>/etc/nsswitch.conf</filename> so it has the entries shown in <link linkend="ch9-sdmnss"/>. </para></step> - <step><para><indexterm> - <primary>net</primary> - <secondary>rpc</secondary> - <tertiary>join</tertiary> - </indexterm> + <step><para> + <indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>join</tertiary></indexterm> The system is ready to join the domain. Execute the following: <screen> net rpc join -U root%not2g4et @@ -895,11 +831,8 @@ Joined domain MEGANET2. </para></step> - <step><para><indexterm> - <primary>winbind</primary> - </indexterm><indexterm> - <primary>wbinfo</primary> - </indexterm> + <step><para> + <indexterm><primary>winbind</primary></indexterm><indexterm><primary>wbinfo</primary></indexterm> Validate operation of <command>winbind</command> using the <command>wbinfo</command> tool as follows: <screen> @@ -977,6 +910,7 @@ MEGANET2+PIOps:x:10005: <step><para> The Samba member server of a Windows NT4 domain is ready for use. </para></step> + </procedure> <smbconfexample id="ch0-NT4DSDM"> @@ -1059,7 +993,7 @@ MEGANET2+PIOps:x:10005: net rpc join -U root%not24get Joined domain MEGANET2. </screen> - This indicates that the domain join succeed. + This indicates that the domain join succeed. </para></step> <step><para> @@ -1174,9 +1108,8 @@ Joined domain MEGANET2. <procedure> <title>Joining a Samba Server as an ADS Domain Member</title> - <step><para><indexterm> - <primary>smbd</primary> - </indexterm> + <step><para> + <indexterm><primary>smbd</primary></indexterm> Before you try to use Samba-3, you want to know for certain that your executables have support for Kerberos and for LDAP. Execute the following to identify whether or not this build is perhaps suitable for use: @@ -1492,11 +1425,8 @@ Server time offset: 2 In any case, the output we obtained confirms that all systems are operational. </para></step> - <step><para><indexterm> - <primary>net</primary> - <secondary>ads</secondary> - <tertiary>status</tertiary> - </indexterm> + <step><para> + <indexterm><primary>net</primary><secondary>ads</secondary><tertiary>status</tertiary></indexterm> There is one more action you elect to take, just because you are paranoid and disbelieving, so you execute the following command: <programlisting> @@ -1577,6 +1507,7 @@ Permissions: called <constant>FRAN</constant> is able to communicate fully with the ADS domain controllers. </para></step> + </procedure> |