From 83a17815a7689f1f6f7ca57161a0e804277c75f9 Mon Sep 17 00:00:00 2001 From: Jelmer Vernooij Date: Sun, 20 Jun 2004 12:43:16 +0000 Subject: New structure for the docs: - Same name for a doc everywhere (howto -> Samba-HOWTO-Collection, etc) - Shorter and more clearly structured Makefile - Make it possible to change the paths for the images (This used to be commit 96f6c05f25acc8a9bb1977b8bd5cc97ce511b6b1) --- docs/Samba-Guide/Chap09-AddingUNIXClients.xml | 2516 +++++++++++++++++++++++++ 1 file changed, 2516 insertions(+) create mode 100644 docs/Samba-Guide/Chap09-AddingUNIXClients.xml (limited to 'docs/Samba-Guide/Chap09-AddingUNIXClients.xml') diff --git a/docs/Samba-Guide/Chap09-AddingUNIXClients.xml b/docs/Samba-Guide/Chap09-AddingUNIXClients.xml new file mode 100644 index 0000000000..e46fc22396 --- /dev/null +++ b/docs/Samba-Guide/Chap09-AddingUNIXClients.xml @@ -0,0 +1,2516 @@ + + + + %xinclude; + + + + %global_entities; + +]> + + + Adding UNIX/LINUX Servers and Clients + + + Open Magazine + + survey + + The most frequently discussed Samba subjects over the past two years have focused around Domain Control and printing. + It is well known that Samba is a file and print server. A recent survey conducted by Open Magazine found + that of all respondents: 97% use Samba for file and print services, and 68% use Samba for Domain Control. See the + Open-Mag + Web site for current information. The survey results as found on January 14, 2004, as shown in + . + + + + Open Magazine Samba Survey + openmag.png + + + + While Domain Control is an exciting subject, basic file and print sharing remains the staple bread-and-butter + function that Samba provides. Yet this book may give the appearance of having focused too much on more + exciting aspects of Samba deployment. This chapter directs your attention to provide important information on + the addition of Samba servers into your present Windows network &smbmdash; whatever the controlling technology + may be. So let's get back to Abmas and our good friends Bob Jordan and company. + + + + Introduction + + + Linux desktop + + Domain Member + server + + Bob Jordan looks back over the achievements of the past year or two. Daily events are rather straightforward + with not too many distractions or problems. Bob, your team is doing well, but a number of employees + are asking for Linux desktop systems. Your network has grown and demands additional Domain Member servers. Let's + get on with this; Christine and Stan are ready to go. + + + + Domain Member + desktop + + Stan Soroka is firmly in control of the Department of the Future, while Christine is enjoying a stable and + predictable network environment. It is time to add more servers and to add Linux desktops. It is + time to meet the demands of future growth and endure trial by fire. Go on, walk the steps + with Stan and Company. + + + + Assignment Tasks + + + Active Directory + + You must now add UNIX/Linux Domain Member servers to your network. You have a friend who has a Windows 2003 + Active Directory Domain network who wants to add a Samba/Linux server and has asked Christine to help him + out. Your real objective is to help Christine to see more of the way the Microsoft world lives and use + her help to get validation that Samba really does live up to expectations. + + + + Over the past six months, you have hired several new staff who want Linux on their desktops. You must integrate + these systems to make sure that Abmas is not building islands of technology. You ask Christine to + do likewise at Swodniw Biz NL (your friend's company) to help them to evaluate a Linux desktop. You want to make + the right decision, don't you? + + + + + + + Dissection and Discussion + + + winbind + + Recent Samba mailing list activity is witness to how many sites are using winbind. Some have no trouble + at all with it, yet to others the problems seem insurmountable. Periodically there are complaints concerning + an inability to achieve identical user and group IDs between Windows and UNIX environments. + + + + You provide step-by-step implementations of the various tools that can be used for identity + resolution. You also provide working examples of solutions for integrated authentication for + both UNIX/Linux and Windows environments. + + + + Technical Issues + + + One of the great challenges we face when people ask us, What is the best way to solve + this problem? is to get beyond the facts so we can not only clearly comprehend + the immediate technical problem, but also understand how needs may change. + + + + integrate + + There are a few facts we should note when dealing with the question of how best to + integrate UNIX/Linux clients and servers into a Windows networking environment: + + + + + Domain Controller + + authoritative + + accounts + authoritative + + PDC + + BDC + + A Domain Controller (PDC or BDC) is always authoritative for all accounts in its Domain. + This means that a BDC must (of necessity) be able to resolve all account UIDs and GIDs + to the same values that the PDC resolved them to. + + + + local accounts + + Domain Member + authoritative + local accounts + + Domain accounts + + winbindd + + A Domain Member can be authoritative for local accounts, but is never authoritative for + Domain accounts. If a user is accessing a Domain Member server and that user's account + is not known locally, the Domain Member server must resolve the identity of that user + from the Domain in which that user's account resides. It must then map that ID to a + UID/GID pair that it can use locally. This is handled by winbindd. + + + + Samba, when running on a Domain Member server, can resolve user identities from a + number of sources: + + + + getpwnam + + getgrnam + + NSS + + LDAP + + NIS + + By executing a system getpwnam() or getgrnam() call. + On systems that support it, this utilizes the name service switch (NSS) facility to + resolve names according to the configuration of the /etc/nsswitch.conf + file. NSS can be configured to use LDAP, winbind, NIS, or local files. + + + + passdb backend + + PADL + + nss_ldap + + Performing, via NSS, a direct LDAP search (where an LDAP passdb backend has been configured). + This requires the use of the PADL nss_ldap tool (or equivalent). + + + + winbindd + + SID + + winbindd_idmap.tdb + + winbindd_cache.tdb + + Directly by querying winbindd. The winbindd + contact a Domain Controller to attempt to resolve the identity of the user or group. It + receives the Windows networking security identifier (SID) for that appropriate + account and then allocates a local UID or GID from the range of available IDs and + creates an entry in its winbindd_idmap.tdb and + winbindd_cache.tdb files. + + + + idmap backend + + mapping + + If the parameter + idmap backendldap:ldap://myserver.domain + was specified and the LDAP server has been configured with a container in which it may + store the IDMAP entries, all Domain Members may share a common mapping. + + + + + + Irrespective of how &smb.conf; is configured, winbind creates and caches a local copy of + the ID mapping database. It uses the winbindd_idmap.tdb, and + winbindd_cache.tdb files to do this. + + + + Which of the above resolver methods is chosen is determined by the way that Samba is configured + in the &smb.conf; file. Some of the configuration options are rather less than obvious to the + casual user. + + + + winbind enable local accounts + + Domain Member + servers + + Domain Controllers + + If you wish to make use of accounts (users and/or groups) that are local to (i.e., capable + of being resolved using) the name service switch (NSS) facility, it is imperative to use the + winbind enable local accountsYes + in the &smb.conf; file. This parameter specifically applies only to Domain Controllers, + not to Domain Member servers. + + + + + Posix accounts + + Samba accounts + + LDAP + + For many administrators, it should be plain that the use of an LDAP-based repository for all network + accounts (both for Posix accounts as well as for Samba accounts) provides the most elegant and + controllable facility. You eventually appreciate the decision to use LDAP. + + + + nss_ldap + + identifiers + + resolve + + 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 nss_ldap + tools to resolve UNIX account UIDs/GIDs via LDAP, this is the preferred solution, as it provides + a more readily controllable method for asserting the exact same user and group identifiers + throughout the network. + + + + Domain Member + server + + winbind trusted domains only + + getpwnam + + smbd + + Trusted Domains + + External Domains + + 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 + winbind trusted domains onlyYes. This forces + Samba (smbd) to perform a getpwnam() system call that can + then be controlled via /etc/nsswitch.conf file settings. The use of this parameter + disables the use of Samba with Trusted Domains (i.e., External Domains). + + + + appliance mode + + Domain Member + server + + winbindd + + automatically allocate + + Winbind can be used to create an appliance mode Domain Member server. In this capacity, winbindd + 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. + This means that it is almost certain that a given user who accesses two Domain Member servers does not have the + same UID/GID on both servers &smbmdash; however, this is transparent to the Windows network user. This data + is stored in the winbindd_idmap.tdb and winbindd_cache.tdb files. + + + + mapping + + The use of an LDAP backend for the Winbind IDMAP facility permits Windows Domain security identifiers (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 + files between/across network file servers. + + + + + + Political Issues + + + OpenLDAP + + NIS + + yellow pages + NIS + + identity management + + One of the most fierce conflicts recently being waged is one of 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 + you work with LDAP, the more its power and flexibility emerges from its dark, cavernous chasm. + + + + LDAP is a most suitable solution for heterogenous environments. If you need crypto, add Kerberos. + The reason these are preferable is because they are heterogenous. Windows solutions of this sort are NOT + heterogenous by design. This is fundamental &smbmdash; it isn't religious or political. This also doesn't say that + you can't use Windows Active Directory in a heterogenous environment &smbmdash; it can be done, it just requires + commercial integration products &smbmdash; it's just not what Active Directory was designed for. + + + + directory + + management + + 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 as long as we could. It is not out of laziness or out of malice that LDAP has + finally emerged as the preferred identity management backend for Samba. We recommend LDAP for your total + organizational directory needs. + + + + + + + + Implementation + + + Domain Member + server + + Domain Member + client + + Domain Controller + + The Domain Member server and the Domain Member client are at the center of focus in this chapter. + Configuration of Samba-3 Domain Controller has been 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. + + + + Domain Member + workstations + + 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 + environment a workstation (client) is a device from which a user creates documents and files that + are located on servers. A workstation is frequently viewed as a disposable (easy to replace) item, + but a server is viewed as a core component of the business. + + + + workstation + + One 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. + + + + authentication process + + logon process + + user identities + + Why is this important? &smbmdash; 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. + In particular, it is important to understand the operation of each critical part of the + authentication process, the logon process, and how user identities get resolved and applied + within the operating system and applications (like Samba) that depend on this and may + actually contribute to it. + + + + So, while here we demonstrate how to implement the technology. It is done within a context of + what type of service need must be fulfilled. + + + + Samba Domain with Samba Domain Member Server &smbmdash; Using LDAP + + + ldapsam + + ldapsam backend + + IDMAP + + mapping + consistent + + winbindd + + foreign SID + + In this example, it is assumed that you have Samba PDC/BDC servers. This means you are using + an LDAP ldapsam backend. In this example, 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/from UIDs/GIDs. This means that you are running winbindd + as part of your configuration. The primary purpose of running winbindd (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. + + + + winbindd + + getpwnam + + NSS + + If your installation is accessed only from clients that are members of your own domain, then + it is not necessary to run winbindd as long as all users can be resolved + locally via the getpwnam() system call. On NSS-enabled systems, this condition + is met by having: + + + + + /etc/passwd + + /etc/group + + All accounts in /etc/passwd or in /etc/group. + + + + NSS + + compat + + compat + + ldap + + nis + + nisplus + + hesoid + + ldap + + nss_ldap + + PADL Software + + Resolution via NSS. On NSS-enabled systems, there is usually a facility to resolve IDs + via multiple methods. The methods typically include: files, compat, db, ldap, + nis, nisplus, hesoid. When correctly installed, Samba adds to this list + the winbindd facility. The ldap facility is frequently the nss_ldap + tool provided by PADL Software. + + + + + Identity resolution + + The diagram in demonstrates the relationship of samba and system + components that are involved in the Identity resolution process where Samba is used as a Domain + Member server within a Samba Domain Control network. + + + + Samba Domain: Samba Member Server + chap9-SambaDC.png + + + + IDMAP + + foreign + + 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 + consistent UID and GID across all of them. The IDMAP facility will be used for all foreign + (i.e., not having the same SID as the Domain it is a member of) Domains. The configuration of + NSS will ensure that all unix processes will obtain a consistent UID/GID. + + + + The instructions given here apply to the Samba environment as shown in Chapters 6 and 7. + If your network does not have an LDAP slave server (i.e., Chapter 6 configuration), you + must change the target LDAP server from lapdc to massive. + + + + Configuration of LDAP-Based Identity Resolution + + + Create the &smb.conf; file as shown in . Locate + this file in the directory /etc/samba. + + + + ldap.conf + + Configure the file that will be used by nss_ldap to + locate and communicate with the LDAP server. This file is called ldap.conf. + If your implementation of nss_ldap is consistent with + the defaults suggested by PADL (the authors), it will be located in the + /etc directory. On some systems, the default location is + the /etc/openldap directory. Change the parameters inside + the file that is located on your OS so it matches . + To find the correct location of this file, you can obtain this from the + library that will be used by executing the following: + +&rootprompt; strings /lib/libnss_ldap* | grep ldap.conf +/etc/ldap.conf + + + + + Configure the name service switch (NSS) control file so it matches the one shown + in . + + + + Identity resolution + + getent + + Before proceeding to configure Samba, validate the operation of the NSS Identity + resolution via LDAP by executing: + +&rootprompt; getent passwd +... +root:x:0:512:Netbios Domain Administrator:/root:/bin/false +nobody:x:999:514:nobody:/dev/null:/bin/false +bobj:x:1000:513:Robert Jordan:/home/bobj:/bin/bash +stans:x:1001:513:Stanley Soroka:/home/stans:/bin/bash +chrisr:x:1002:513:Christine Roberson:/home/chrisr:/bin/bash +maryv:x:1003:513:Mary Vortexis:/home/maryv:/bin/bash +jht:x:1004:513:John H Terpstra:/home/jht:/bin/bash +bldg1$:x:1006:553:bldg1$:/dev/null:/bin/false +temptation$:x:1009:553:temptation$:/dev/null:/bin/false +vaioboss$:x:1005:553:vaioboss$:/dev/null:/bin/false +fran$:x:1008:553:fran$:/dev/null:/bin/false +josephj:x:1007:513:Joseph James:/home/josephj:/bin/bash + + You should notice the location of the users' home directories. First, make certain that + the home directories exist on the Domain Member server; otherwise, the home directory + share is not available. The home directories could be mounted off a domain controller + using NFS, or by any other suitable means. Second, the absence of the Domain name in the + home directory path is indicative that Identity resolution is not being done via Winbind. + +&rootprompt; getent group +... +Domain Admins:x:512:root,jht +Domain Users:x:513:bobj,stans,chrisr,maryv,jht,josephj +Domain Guests:x:514: +Accounts:x:1000: +Finances:x:1001: +PIOps:x:1002: +sammy:x:4321: + + + secondary group + + primary group + + group membership + + This shows that all is working as it should. 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 + user is already a member via primary group membership in the password database. + When using winbind, it is in fact undesirable to do this as it results in + doubling up of group memberships and may break winbind under certain conditions. + + + + slapcat + + 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: + +&rootprompt; slapcat | grep -i idmap +dn: ou=Idmap,dc=abmas,dc=biz +ou: idmap + + + ldapadd + + If the execution of this command does not return IDMAP entries, you need to create an LDIF + template file (see ). You can add the required entries using the following command: + +&rootprompt; ldapadd -x -D "cn=Manager,dc=abmas,dc=biz" \ + -w not24get < /etc/openldap/idmap.LDIF + + Samba automatically populates this LDAP directory container when it needs to. + + + + net + rpc + join + + Domain join + + The system is ready to join the Domain. Execute the following: + +net rpc join -U root%not24et +Joined domain MEGANET2. + + This indicates that the Domain join succeeded. + + + + You may now start Samba in the usual manner and your Samba Domain Member server + is ready for use. Just add shares as required. + + + + + +Samba Domain Member in Samba Domain Control Context &smbmdash; &smb.conf; File +Global parameters +[global] +unix charsetLOCALE +workgroupMEGANET2 +securityDOMAIN +username map/etc/samba/smbusers +log level10 +syslog0 +log file/var/log/samba/%m +max log size50 +smb ports139 445 +name resolve orderwins bcast hosts +printcap nameCUPS +wins server192.168.2.1 +ldap suffixdc=abmas,dc=biz +ldap machine suffixou=People +ldap user suffixou=People +ldap group suffixou=Groups +ldap idmap suffixou=Idmap +ldap admin dncn=Manager,dc=abmas,dc=biz +idmap backendldap:ldap://lapdc.abmas.biz +idmap uid10000-20000 +idmap gid10000-20000 +winbind trusted domains onlyYes +printer adminroot +printingcups + +[homes] +commentHome Directories +valid users%S +read onlyNo +browseableNo + +[printers] +commentSMB Print Spool +path/var/spool/samba +guest okYes +printableYes +browseableNo + +[print$] +commentPrinter Drivers +path/var/lib/samba/drivers +admin usersroot, Administrator +write listroot + + + +LDIF IDMAP Add-On Load File &smbmdash; File: /etc/openldap/idmap.LDIF + +dn: ou=Idmap,dc=abmas,dc=biz +objectClass: organizationalUnit +ou: idmap +structuralObjectClass: organizationalUnit + + + + +Configuration File for NSS LDAP Support &smbmdash; <filename>/etc/ldap.conf</filename> + +URI ldap://massive.abmas.biz ldap://massive.abmas.biz:636 +host 192.168.2.1 +base dc=abmas,dc=biz +binddn cn=Manager,dc=abmas,dc=biz +bindpw not24get + +pam_password exop + +nss_base_passwd ou=People,dc=abmas,dc=biz?one +nss_base_shadow ou=People,dc=abmas,dc=biz?one +nss_base_group ou=Groups,dc=abmas,dc=biz?one +ssl no + + + + +NSS using LDAP for Identity Resolution &smbmdash; File: <filename>/etc/nsswitch.conf</filename> + +passwd: compat ldap +group: compat ldap + +hosts: files dns wins +networks: files dns + +services: files +protocols: files +rpc: files +ethers: files +netmasks: files +netgroup: files +publickey: files + +bootparams: files +automount: files +aliases: files + + + + + + + NT4/Samba Domain with Samba Domain Member Server &smbmdash; Using Winbind + + + You need to use this method for creating a Samba Domain Member server if any of the following conditions + prevail: + + + + + LDAP support (client) is not installed on the system. + + + + There are mitigating circumstances forcing a decision not to use LDAP. + + + + The Samba Domain Member server must be part of a Windows NT4 Domain. + + + + + Windows ADS Domain + + Samba Domain + + LDAP + + Later in the chapter, you can see how to configure a Samba Domain Member server for a Windows ADS Domain. + Right now your objective is to configure a Samba server that can be a member of a Windows NT4 style + Domain and/or does not use LDAP. + + + + duplicate accounts + + If you use winbind for Identity resolution, do make sure that there are no + duplicate accounts. + + + + /etc/passwd + + For example, do not have more than one account that has UID=0 in the password database. If there + is an account called root in the /etc/passwd database, + it is okay to have an account called root in the LDAP ldapsam or in the + tdbsam. But if there are two accounts in the passdb backend that have the same UID, winbind will + break. This means that the Administrator account must be called + root. + + + + /etc/passwd + + ldapsam + + tdbsam + + Winbind will break if there is an account in /etc/passwd that has + the same UID as an account that is in LDAP ldapsam (or in tdbsam) but that differs in name only. + + + + credentials + + traverse + + wide-area + + network + wide-area + + tdbdump + + The following configuration uses CIFS/SMB protocols alone to obtain user and group credentials. + The winbind information is locally cached in the winbindd_cache.tdb winbindd_idmap.tdb + files. This provides considerable performance benefits compared with the LDAP solution, particularly + where the LDAP lookups must traverse wide-area network links. You may examine the contents of these + files using the tool tdbdump, though you may have to build this from the Samba + source code if it has not been supplied as part of a binary package distribution that you may be using. + + + + Configuration of Winbind-Based Identity Resolution + + + Using your favorite text editor, create the &smb.conf; file so it has the contents + shown in . + + + + /etc/nsswitch.conf + + Edit the /etc/nsswitch.conf so it has the entries shown in + . + + + + net + rpc + join + + The system is ready to join the Domain. Execute the following: + +net rpc join -U root%not24et +Joined domain MEGANET2. + + This indicates that the Domain join succeed. + + + + + winbind + + wbinfo + + Validate operation of winbind using the wbinfo + tool as follows: + +&rootprompt; wbinfo -u +MEGANET2+root +MEGANET2+nobody +MEGANET2+jht +MEGANET2+maryv +MEGANET2+billr +MEGANET2+jelliott +MEGANET2+dbrady +MEGANET2+joeg +MEGANET2+balap + + This shows that Domain users have been listed correctly. + +&rootprompt; wbinfo -g +MEGANET2+Domain Admins +MEGANET2+Domain Users +MEGANET2+Domain Guests +MEGANET2+Accounts +MEGANET2+Finances +MEGANET2+PIOps + + This shows that Domain groups have been correctly obtained also. + + + + NSS + + getent + + winbind + + The next step verifies that NSS is able to obtain this information + correctly from winbind also. + +&rootprompt; getent passwd +... +MEGANET2+root:x:10000:10001:NetBIOS Domain Admin: + /home/MEGANET2/root:/bin/bash +MEGANET2+nobody:x:10001:10001:nobody: + /home/MEGANET2/nobody:/bin/bash +MEGANET2+jht:x:10002:10001:John H Terpstra: + /home/MEGANET2/jht:/bin/bash +MEGANET2+maryv:x:10003:10001:Mary Vortexis: + /home/MEGANET2/maryv:/bin/bash +MEGANET2+billr:x:10004:10001:William Randalph: + /home/MEGANET2/billr:/bin/bash +MEGANET2+jelliott:x:10005:10001:John G Elliott: + /home/MEGANET2/jelliott:/bin/bash +MEGANET2+dbrady:x:10006:10001:Darren Brady: + /home/MEGANET2/dbrady:/bin/bash +MEGANET2+joeg:x:10007:10001:Joe Green: + /home/MEGANET2/joeg:/bin/bash +MEGANET2+balap:x:10008:10001:Bala Pillay: + /home/MEGANET2/balap:/bin/bash + + The user account information has been correctly obtained. This information has + been merged with the winbind template information configured in the &smb.conf; file. + +&rootprompt;# getent group +... +MEGANET2+Domain Admins:x:10000:MEGANET2+root,MEGANET2+jht +MEGANET2+Domain Users:x:10001:MEGANET2+jht,MEGANET2+maryv,\ + MEGANET2+billr,MEGANET2+jelliott,MEGANET2+dbrady,\ + MEGANET2+joeg,MEGANET2+balap +MEGANET2+Domain Guests:x:10002:MEGANET2+nobody +MEGANET2+Accounts:x:10003: +MEGANET2+Finances:x:10004: +MEGANET2+PIOps:x:10005: + + + + + The Samba member server of a Windows NT4 Domain is ready for use. + + + + +Samba Domain Member Server &smb.conf; File for NT4 Domain +Global parameters +[global] +unix charsetLOCALE +workgroupMEGANET2 +securityDOMAIN +username map/etc/samba/smbusers +log level1 +syslog0 +log file/var/log/samba/%m +max log size0 +smb ports139 445 +name resolve orderwins bcast hosts +printcap nameCUPS +wins server192.168.2.1 +idmap uid10000-20000 +idmap gid10000-20000 +template primary group"Domain Users" +template shell/bin/bash +winbind separator+ +printer adminroot +hosts allow192.168.2., 192.168.3., 127. +printingcups + +[homes] +commentHome Directories +valid users%S +read onlyNo +browseableNo + +[printers] +commentSMB Print Spool +path/var/spool/samba +guest okYes +printableYes +browseableNo + +[print$] +commentPrinter Drivers +path/var/lib/samba/drivers +admin usersroot, Administrator +write listroot + + + +Name Service Switch Control File: <filename>/etc/nsswitch.conf</filename> + +# /etc/nsswitch.conf + +passwd: compat winbind +group: compat winbind + +hosts: files dns wins +networks: files dns + +services: files +protocols: files +rpc: files +ethers: files +netmasks: files +netgroup: files +publickey: files + +bootparams: files +automount: files +aliases: files + + + + + + + Active Directory Domain with Samba Domain Member Server + + + Active Directory + join + + Kerberos + + Domain Member + server + + One of the much-sought-after features new to Samba-3 is the ability to join an Active Directory + Domain using Kerberos protocols. This makes it possible to operate an entire Windows network + without the need to run NetBIOS over TCP/IP and permits more secure networking in general. An + exhaustively complete discussion of the protocols is not possible in this book; perhaps a + later book may explore the intricacies of the NetBIOS-less operation that Samba-3 can participate + in. For now, we simply focus on how a Samba-3 server can be made a Domain Member server. + + + + Active Directory + + LDAP + + Identity resolution + + Kerberos + + The diagram in demonstrates how Samba-3 interfaces with + Microsoft Active Directory components. It should be noted that if Microsoft Windows Services + for UNIX has been installed and correctly configured, it is possible to use client LDAP + for Identity resolution just as can be done with Samba-3 when using an LDAP passdb backend. + The UNIX tool that you need for this, as in the case of LDAP on UNIX/Linux, is the PADL + Software nss_ldap tool-set. Compared with use of winbind and Kerberos, the use of + LDAP-based Identity resolution is a little less secure. In view of the fact that this solution + requires additional software to be installed on the Windows 200x ADS Domain Controllers, + and that means more management overhead, it is likely that most Samba-3 ADS client sites + may elect to use winbind. + + + + Do not attempt to use this procedure if you are not 100 percent certain that the build of Samba-3 + you are using has been compiled and linked with all the tools necessary for this to work. + Given the importance of this step, you must first validate that the Samba-3 message block + daemon (smbd) has the necessary features. + + + + The hypothetical domain you are using in this example assumes that the Abmas London office + decided to take their own lead (some would say this is a typical behavior in a global + corporate world; besides, a little divergence and conflict makes for an interesting life). + The Windows Server 2003 ADS Domain is called london.abmas.biz and the + name of the server is W2K3S. In ADS realm terms, the Domain Controller + is known as w2k3s.london.abmas.biz. In NetBIOS nomenclature, the + Domain Name is LONDON and the server name is W2K3S. + + + + Active Directory Domain: Samba Member Server + chap9-ADSDC.png + + + + + smbd + + 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: + +&rootprompt; cd /usr/sbin +&rootprompt; smbd -b | grep KRB + HAVE_KRB5_H + HAVE_ADDR_TYPE_IN_KRB5_ADDRESS + HAVE_KRB5 + HAVE_KRB5_AUTH_CON_SETKEY + HAVE_KRB5_GET_DEFAULT_IN_TKT_ETYPES + HAVE_KRB5_GET_PW_SALT + HAVE_KRB5_KEYBLOCK_KEYVALUE + HAVE_KRB5_KEYTAB_ENTRY_KEYBLOCK + HAVE_KRB5_MK_REQ_EXTENDED + HAVE_KRB5_PRINCIPAL_GET_COMP_STRING + HAVE_KRB5_SET_DEFAULT_IN_TKT_ETYPES + HAVE_KRB5_STRING_TO_KEY + HAVE_KRB5_STRING_TO_KEY_SALT + HAVE_LIBKRB5 + + The above output was obtained on a SuSE Linux system and shows the output for + Samba that has been compiled and linked with the Heimdal Kerberos libraries. + The following is a typical output that will be found on a Red Hat Linux system that + has been linked with the MIT Kerberos libraries: + +&rootprompt; cd /usr/sbin +&rootprompt; smbd -b | grep KRB + HAVE_KRB5_H + HAVE_ADDRTYPE_IN_KRB5_ADDRESS + HAVE_KRB5 + HAVE_KRB5_AUTH_CON_SETUSERUSERKEY + HAVE_KRB5_ENCRYPT_DATA + HAVE_KRB5_FREE_DATA_CONTENTS + HAVE_KRB5_FREE_KTYPES + HAVE_KRB5_GET_PERMITTED_ENCTYPES + HAVE_KRB5_KEYTAB_ENTRY_KEY + HAVE_KRB5_LOCATE_KDC + HAVE_KRB5_MK_REQ_EXTENDED + HAVE_KRB5_PRINCIPAL2SALT + HAVE_KRB5_PRINC_COMPONENT + HAVE_KRB5_SET_DEFAULT_TGS_KTYPES + HAVE_KRB5_SET_REAL_TIME + HAVE_KRB5_STRING_TO_KEY + HAVE_KRB5_TKT_ENC_PART2 + HAVE_KRB5_USE_ENCTYPE + HAVE_LIBGSSAPI_KRB5 + HAVE_LIBKRB5 + + You can validate that Samba has been compiled and linked with LDAP support + by executing: + +&rootprompt; smbd -b | grep LDAP +massive:/usr/sbin # smbd -b | grep LDAP + HAVE_LDAP_H + HAVE_LDAP + HAVE_LDAP_DOMAIN2HOSTLIST + HAVE_LDAP_INIT + HAVE_LDAP_INITIALIZE + HAVE_LDAP_SET_REBIND_PROC + HAVE_LIBLDAP + LDAP_SET_REBIND_PROC_ARGS + + This does look promising; smbd has been built with Kerberos and LDAP + support. You are relieved to know that it is safe to progress. + + + + Kerberos + libraries + + MIT Kerberos + + Heimdal Kerberos + + Kerberos + MIT + + Kerberos + Heimdal + + Red Hat Linux + + SUSE Linux + + SerNet + + validated + + The next step is to identify which version of the Kerberos libraries have been used. + In order to permit Samba-3 to interoperate with Windows 2003 Active Directory, it is + essential that it has been linked with either MIT Kerberos version 1.3.1 or later, + or that it has been linked with Heimdal Kerberos 0.6 plus specific patches. You may + identify what version of the MIT Kerberos libraries are installed on your system by + executing (on Red Hat Linux): + +&rootprompt; rpm -q krb5 + + Or on SUSE Linux, execute: + +&rootprompt; rpm -q heimdal + + Please note that the RPMs provided by the Samba-Team are known to be working and have + been validated. Red Hat Linux RPMs may be obtained from the Samba FTP sites. SUSE + Linux RPMs may be obtained from Sernet in + Germany. + + + + From this point on, you are certain that the Samba-3 build you are using has the + necessary capabilities. You can now configure Samba-3 and the name service + switcher (NSS). + + + + Using you favorite editor, configure the &smb.conf; file that is located in the + /etc/samba directory so that it has the contents shown + in . + + + + Edit or create the NSS control file so it has the contents shown in . + + + + /etc/samba/secrets.tdb + + Delete the file /etc/samba/secrets.tdb, if it exists. Of course, you + do keep a backup, don't you? + + + + Delete the tdb files that cache Samba information. You keep a backup of the old + files, of course. You also remove all files to ensure that nothing can pollute your + nice, new configuration. Execute the following (example is for SUSE Linux): + +&rootprompt; rm /var/lib/samba/*tdb + + + + + testparm + + Validate your &smb.conf; file using testparm (as you have + done previously). Correct all errors reported before proceeding. The command you + execute is: + +&rootprompt; testparm -s | less + + Now that you are satisfied that your Samba server is ready to join the Windows + ADS Domain, let's move on. + + + + net + ads + join + + Kerberos + + This is a good time to double-check everything and then execute the following + command when everything you have done has checked out okay: + +&rootprompt; net ads join -UAdministrator%not24get +Using short domain name -- LONDON +Joined 'FRAN' to realm 'LONDON.ABMAS.BIZ' + + You have successfully made your Samba-3 server a member of the ADS Domain + using Kerberos protocols. + + + + silent return + + failed join + + In the event that you receive no output messages, a silent return means that the + Domain join failed. You should use ethereal to identify what + may be failing. Common causes of a failed join include: + + + + name resolution + Defective + + Defective or misconfigured DNS name resolution. + + + + Restrictive security + + Restrictive security settings on the Windows 200x ADS Domain controller + preventing needed communications protocols. You can check this by searching + the Windows Server 200x Event Viewer. + + + + Incorrectly configured &smb.conf; file settings. + + + + Lack of support of necessary Kerberos protocols because the version of MIT + Kerberos (or Heimdal) in use is not up to date enough to support the necessary + functionality. + + + + net + rpc + join + + RPC + + mixed mode + + In any case, never execute the net rpc join command in an attempt + to join the Samba server to the Domain, unless you wish not to use the Kerberos + security protocols. Use of the older RPC-based Domain join facility requires that + Windows Server 200x ADS has been configured appropriately for mixed mode operation. + + + + tdbdump + + /etc/samba/secrets.tdb + + If the tdbdump is installed on your system (not essential), + you can look inside the /etc/samba/secrets.tdb file. If + you wish to do this, execute: + +&rootprompt; tdbdump secrets.tdb +{ +key = "SECRETS/SID/LONDON" +data = "\01\04\00\00\00\00\00\05\15\00\00\00\EBw\86\F1\ED\BD\ + F6{\5C6\E5W\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\ + 00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\ + 00\00\00\00\00\00\00\00" +} +{ +key = "SECRETS/MACHINE_PASSWORD/LONDON" +data = "le3Q5FPnN5.ueC\00" +} +{ +key = "SECRETS/MACHINE_SEC_CHANNEL_TYPE/LONDON" +data = "\02\00\00\00" +} +{ +key = "SECRETS/MACHINE_LAST_CHANGE_TIME/LONDON" +data = "E\89\F6?" +} + + This is given to demonstrate to the skeptics that this process truly does work. + + + + It is now time to start Samba in the usual way (as has been done many time before + in this book). + + + + wbinfo + + This is a good time to verify that everything is working. First, check that + winbind is able to obtain the list of users and groups from the ADS Domain Controller. + Execute the following: + +&rootprompt; wbinfo -u +LONDON+Administrator +LONDON+Guest +LONDON+SUPPORT_388945a0 +LONDON+krbtgt +LONDON+jht + + Good, the list of users was obtained. Now do likewise for group accounts: + +&rootprompt; wbinfo -g +LONDON+Domain Computers +LONDON+Domain Controllers +LONDON+Schema Admins +LONDON+Enterprise Admins +LONDON+Domain Admins +LONDON+Domain Users +LONDON+Domain Guests +LONDON+Group Policy Creator Owners +LONDON+DnsUpdateProxy + + Excellent. That worked also, as expected. + + + + getent + + Now repeat this via NSS to validate that full Identity resolution is + functional as required. Execute: + +&rootprompt; getent passwd +... +LONDON+Administrator:x:10000:10000:Administrator: + /home/LONDON/administrator:/bin/bash +LONDON+Guest:x:10001:10001:Guest: + /home/LONDON/guest:/bin/bash +LONDON+SUPPORT_388945a0:x:10002:10000:SUPPORT_388945a0: + /home/LONDON/support_388945a0:/bin/bash +LONDON+krbtgt:x:10003:10000:krbtgt: + /home/LONDON/krbtgt:/bin/bash +LONDON+jht:x:10004:10000:John H. Terpstra: + /home/LONDON/jht:/bin/bash + + Okay, ADS user accounts are being resolved. Now you try group resolution as follows: + +&rootprompt; getent group +... +LONDON+Domain Computers:x:10002: +LONDON+Domain Controllers:x:10003: +LONDON+Schema Admins:x:10004:LONDON+Administrator +LONDON+Enterprise Admins:x:10005:LONDON+Administrator +LONDON+Domain Admins:x:10006:LONDON+jht,LONDON+Administrator +LONDON+Domain Users:x:10000: +LONDON+Domain Guests:x:10001: +LONDON+Group Policy Creator Owners:x:10007:LONDON+Administrator +LONDON+DnsUpdateProxy:x:10008: + + This is very pleasing. Everything works as expected. + + + + net + ads + info + + Active Directory + server + + Kerberos + + You may now perform final verification that communications between Samba-3 winbind and + the Active Directory server is using Kerberos protocols. Execute the following: + +&rootprompt; net ads info +LDAP server: 192.168.2.123 +LDAP server name: w2k3s +Realm: LONDON.ABMAS.BIZ +Bind Path: dc=LONDON,dc=ABMAS,dc=BIZ +LDAP port: 389 +Server time: Sat, 03 Jan 2004 02:44:44 GMT +KDC server: 192.168.2.123 +Server time offset: 2 + + It should be noted that Kerberos protocols are time-clock critical. You should + keep all server time clocks synchronized using the network time protocol (NTP). + In any case, the output we obtained confirms that all systems are operational. + + + + net + ads + status + + There is one more action you elect to take, just because you are paranoid and disbelieving, + so you execute the following command: + +&rootprompt; net ads status -UAdministrator%not24get +objectClass: top +objectClass: person +objectClass: organizationalPerson +objectClass: user +objectClass: computer +cn: fran +distinguishedName: CN=fran,CN=Computers,DC=london,DC=abmas,DC=biz +instanceType: 4 +whenCreated: 20040103092006.0Z +whenChanged: 20040103092006.0Z +uSNCreated: 28713 +uSNChanged: 28717 +name: fran +objectGUID: 58f89519-c467-49b9-acb0-f099d73696e +userAccountControl: 69632 +badPwdCount: 0 +codePage: 0 +countryCode: 0 +badPasswordTime: 0 +lastLogoff: 0 +lastLogon: 127175965783327936 +localPolicyFlags: 0 +pwdLastSet: 127175952062598496 +primaryGroupID: 515 +objectSid: S-1-5-21-4052121579-2079768045-1474639452-1109 +accountExpires: 9223372036854775807 +logonCount: 13 +sAMAccountName: fran$ +sAMAccountType: 805306369 +operatingSystem: Samba +operatingSystemVersion: 3.0.2-SUSE +dNSHostName: fran +userPrincipalName: HOST/fran@LONDON.ABMAS.BIZ +servicePrincipalName: CIFS/fran.london.abmas.biz +servicePrincipalName: CIFS/fran +servicePrincipalName: HOST/fran.london.abmas.biz +servicePrincipalName: HOST/fran +objectCategory: CN=Computer,CN=Schema,CN=Configuration, + DC=london,DC=abmas,DC=biz +isCriticalSystemObject: FALSE +-------------- Security Descriptor (revision: 1, type: 0x8c14) +owner SID: S-1-5-21-4052121579-2079768045-1474639452-512 +group SID: S-1-5-21-4052121579-2079768045-1474639452-513 +------- (system) ACL (revision: 4, size: 120, number of ACEs: 2) +------- ACE (type: 0x07, flags: 0x5a, size: 0x38, + mask: 0x20, object flags: 0x3) +access SID: S-1-1-0 +access type: AUDIT OBJECT +Permissions: + [Write All Properties] +------- ACE (type: 0x07, flags: 0x5a, size: 0x38, + mask: 0x20, object flags: 0x3) +access SID: S-1-1-0 +access type: AUDIT OBJECT +Permissions: + [Write All Properties] +------- (user) ACL (revision: 4, size: 1944, number of ACEs: 40) +------- ACE (type: 0x00, flags: 0x00, size: 0x24, mask: 0xf01ff) +access SID: S-1-5-21-4052121579-2079768045-1474639452-512 +access type: ALLOWED +Permissions: [Full Control] +------- ACE (type: 0x00, flags: 0x00, size: 0x18, mask: 0xf01ff) +access SID: S-1-5-32-548 +... +------- ACE (type: 0x05, flags: 0x12, size: 0x38, + mask: 0x10, object flags: 0x3) +access SID: S-1-5-9 +access type: ALLOWED OBJECT +Permissions: + [Read All Properties] +-------------- End Of Security Descriptor + + And now you have conclusive proof that your Samba-3 ADS Domain Member Server + called FRAN, is able to communicate fully with the ADS + Domain Controllers. + + + + + + Your Samba-3 ADS Domain Member server is ready for use. During training sessions, + you may be asked what is inside the winbindd_cache.tdb and winbindd_idmap.tdb + files. Since curiosity just took hold of you, execute the following: + +&rootprompt; tdbdump /var/lib/samba/winbindd_idmap.tdb +{ +key = "S-1-5-21-4052121579-2079768045-1474639452-501\00" +data = "UID 10001\00" +} +{ +key = "UID 10005\00" +data = "S-1-5-21-4052121579-2079768045-1474639452-1111\00" +} +{ +key = "GID 10004\00" +data = "S-1-5-21-4052121579-2079768045-1474639452-518\00" +} +{ +key = "S-1-5-21-4052121579-2079768045-1474639452-502\00" +data = "UID 10003\00" +} +... + +&rootprompt; tdbdump /var/lib/samba/winbindd_cache.tdb +{ +key = "UL/LONDON" +data = "\00\00\00\00bp\00\00\06\00\00\00\0DAdministrator\0D + Administrator-S-1-5-21-4052121579-2079768045-1474639452-500- + S-1-5-21-4052121579-2079768045-1474639452-513\05Guest\05 + Guest-S-1-5-21-4052121579-2079768045-1474639452-501- + S-1-5-21-4052121579-2079768045-1474639452-514\10 + SUPPORT_388945a0\10SUPPORT_388945a0. + S-1-5-21-4052121579-2079768045-1474639452-1001- + S-1-5-21-4052121579-2079768045-1474639452-513\06krbtgt\06 + krbtgt-S-1-5-21-4052121579-2079768045-1474639452-502- + S-1-5-21-4052121579-2079768045-1474639452-513\03jht\10 + John H. Terpstra.S-1-5-21-4052121579-2079768045-1474639452-1110- + S-1-5-21-4052121579-2079768045-1474639452-513" +} +{ +key = "GM/S-1-5-21-4052121579-2079768045-1474639452-512" +data = "\00\00\00\00bp\00\00\02\00\00\00. + S-1-5-21-4052121579-2079768045-1474639452-1110\03 + jht\01\00\00\00-S-1-5-21-4052121579-2079768045-1474639452-500\0D + Administrator\01\00\00\00" +} +{ +key = "SN/S-1-5-21-4052121579-2079768045-1474639452-513" +data = "\00\00\00\00xp\00\00\02\00\00\00\0CDomain Users" +} +{ +key = "GM/S-1-5-21-4052121579-2079768045-1474639452-518" +data = "\00\00\00\00bp\00\00\01\00\00\00- + S-1-5-21-4052121579-2079768045-1474639452-500\0D + Administrator\01\00\00\00" +} +{ +key = "SEQNUM/LONDON\00" +data = "xp\00\00C\92\F6?" +} +{ +key = "U/S-1-5-21-4052121579-2079768045-1474639452-1110" +data = "\00\00\00\00xp\00\00\03jht\10John H. Terpstra. + S-1-5-21-4052121579-2079768045-1474639452-1110- + S-1-5-21-4052121579-2079768045-1474639452-513" +} +{ +key = "NS/S-1-5-21-4052121579-2079768045-1474639452-502" +data = "\00\00\00\00bp\00\00- + S-1-5-21-4052121579-2079768045-1474639452-502" +} +{ +key = "SN/S-1-5-21-4052121579-2079768045-1474639452-1001" +data = "\00\00\00\00bp\00\00\01\00\00\00\10SUPPORT_388945a0" +} +{ +key = "SN/S-1-5-21-4052121579-2079768045-1474639452-500" +data = "\00\00\00\00bp\00\00\01\00\00\00\0DAdministrator" +} +{ +key = "U/S-1-5-21-4052121579-2079768045-1474639452-502" +data = "\00\00\00\00bp\00\00\06krbtgt\06krbtgt- + S-1-5-21-4052121579-2079768045-1474639452-502- + S-1-5-21-4052121579-2079768045-1474639452-513" +} +.... + + Now all is revealed. Your curiosity, as well as that of those with you, has been put at ease. + May this server serve well all who happen upon it. + + + +Samba Domain Member &smb.conf; File for Active Directory Membership +Global parameters +[global] +unix charsetLOCALE +workgroupLONDON +realmLONDON.ABMAS.BIZ +server stringSamba 3.0.2 +securityADS +username map/etc/samba/smbusers +log level1 +syslog0 +log file/var/log/samba/%m +max log size50 +printcap nameCUPS +ldap sslno +idmap uid10000-20000 +idmap gid10000-20000 +template primary group"Domain Users" +template shell/bin/bash +winbind separator+ +printingcups + +[homes] +commentHome Directories +valid users%S +read onlyNo +browseableNo + +[printers] +commentSMB Print Spool +path/var/spool/samba +guest okYes +printableYes +browseableNo + +[print$] +commentPrinter Drivers +path/var/lib/samba/drivers +admin usersroot, Administrator +write listroot + + + + + + UNIX/Linux Client Domain Member + + + user credentials + + So far this chapter has been mainly concerned with the provision of file and print + services for Domain Member servers. However, an increasing number of UNIX/Linux + workstations are being installed that do not act as file or print servers to anyone + other than a single desktop user. The key demand for desktop systems is to be able + to log onto any UNIX/Linux or Windows desktop using the same network user credentials. + + + + Single Sign-On + SOS + + The ability to use a common set of user credential across a variety of network systems + is generally regarded as a Single Sign-On (SOS) solution. SOS systems are sold by a + large number of vendors and include a range of technologies such as: + + + + + Proxy sign-on + + + + Federated directory provisioning + + + + Meta-directory server solutions + + + + Replacement authentication systems + + + + + Identity management + + There are really only three solutions that provide integrated authentication and + user Identity management facilities: + + + + + Samba Winbind (free) + + + + PADL PAM and LDAP Tools (free) + + + + Vintela Authentication Services (Commercial) + + + + + The following guidelines are pertinent in respect of the deployment of winbind-based authentication + and Identity resolution with the express purpose of allowing users to log onto UNIX/Linux desktops + using Windows network Domain user credentials (username and password). + + + + You should note that it is possible to use LDAP-based PAM and NSS tools to permit distributed + systems logons (SSO) providing user and group accounts are stored in an LDAP directory. This + provides logon services for UNIX/Linux users, while Windows users obtain their sign-on + support via Samba-3. + + + + Windows Services for UNIX + SUS + + On the other hand, if the authentication and Identity resolution backend must be provided by + a Windows NT4 style Domain or from an Active Directory Domain that does not have the Microsoft + Windows Services for UNIX (SUS) installed, winbind is your best friend. Specific guidance for these + situations now follows. + + + + PAM + + Identity resolution + + NSS + + To permit users to log onto a Linux system using Windows network credentials, you need to + configure Identity resolution (NSS) and PAM. This means that the basic steps include those + outlined above with the addition of PAM configuration. Given that most workstations (desktop/client) + usually do not need to provide file and print services to a group of users, the configuration + of shares and printers is generally less important. Often this allows the share specifications + to be entirely removed from the &smb.conf; file. That is obviously an administrator decision. + + + + NT4 Domain Member + + + The following steps provide a Linux system that users can log onto using + Windows NT4 Domain (or Samba-3) Domain network credentials: + + + + + Follow the steps outlined in and ensure that + all validation tests function as shown. + + + + Identify what services users must log onto. On Red Hat Linux, if it is + intended that the user shall be given access to all services, it may be + most expeditious to simply configure the file + /etc/pam.d/system-auth. + + + + Carefully make a backup copy of all PAM configuration files before you + begin making changes. If you break the PAM configuration, please note + that you may need to use an emergency boot process to recover your Linux + system. It is possible to break the ability to log into the system if + PAM files are incorrectly configured. The entire directory + /etc/pam.d should be backed up to a safe location. + + + + If you require only console login support, edit the /etc/pam.d/login + so it matches . + + + + To provide the ability to log onto the graphical desktop interface, you must edit + the files gdm and xdm in the + /etc/pam.d directory. + + + + Edit only one file at a time. Carefully validate its operation before attempting + to reboot the machine. + + + + + + + ADS Domain Member + + + This procedure should be followed to permit a Linux network client (workstation/desktop) + to permit users to log on using Microsoft Active Directory based user credentials. + + + + + Follow the steps outlined in and ensure that + all validation tests function as shown. + + + + Identify what services users must log onto. On Red Hat Linux, if it is + intended that the user shall be given access to all services, it may be + most expeditious to simply configure the file + /etc/pam.d/system-auth as shown in . + + + + Carefully make a backup copy of all PAM configuration files before you + begin making changes. If you break the PAM configuration, please note + that you may need to use an emergency boot process to recover your Linux + system. It is possible to break the ability to log into the system if + PAM files are incorrectly configured. The entire directory + /etc/pam.d should be backed up to a safe location. + + + + If you require only console login support, edit the /etc/pam.d/login + so it matches . + + + + To provide the ability to log onto the graphical desktop interface, you must edit + the files gdm and xdm in the + /etc/pam.d directory. + + + + Edit only one file at a time. Carefully validate its operation before attempting + to reboot the machine. + + + + + + +SUSE: PAM <filename>login</filename> Module Using Winbind + +# /etc/pam.d/login + +#%PAM-1.0 +auth sufficient pam_unix2.so nullok +auth sufficient pam_winbind.so use_first_pass use_authtok +auth required pam_securetty.so +auth required pam_nologin.so +auth required pam_env.so +auth required pam_mail.so +account sufficient pam_unix2.so +account sufficient pam_winbind.so user_first_pass use_authtok +password required pam_pwcheck.so nullok +password sufficient pam_unix2.so nullok use_first_pass use_authtok +password sufficient pam_winbind.so use_first_pass use_authtok +session sufficient pam_unix2.so none +session sufficient pam_winbind.so use_first_pass use_authtok +session required pam_limits.so + + + + +SUSE: PAM <filename>xdm</filename> Module Using Winbind + +# /etc/pam.d/gdm (/etc/pam.d/xdm) + +#%PAM-1.0 +auth sufficient pam_unix2.so nullok +auth sufficient pam_winbind.so use_first_pass use_authtok +account sufficient pam_unix2.so +account sufficient pam_winbind.so use_first_pass use_authtok +password sufficient pam_unix2.so +password sufficient pam_winbind.so use_first_pass use_authtok +session sufficient pam_unix2.so +session sufficient pam_winbind.so use_first_pass use_authtok +session required pam_dev perm.so +session required pam_resmgr.so + + + + +Red Hat 9: PAM System Authentication File: <filename>/etc/pam.d/system-auth</filename> Module Using Winbind + +#%PAM-1.0 +auth required /lib/security/$ISA/pam_env.so +auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok +auth sufficient /lib/security/$ISA/pam_winbind.so use_first_pass +auth required /lib/security/$ISA/pam_deny.so + +account required /lib/security/$ISA/pam_unix.so +account sufficient /lib/security/$ISA/pam_winbind.so use_first_pass + +password required /lib/security/$ISA/pam_cracklib.so retry=3 type= +# Note: The above line is complete. There is nothing following the '=' +password sufficient /lib/security/$ISA/pam_unix.so \ + nullok use_authtok md5 shadow +password sufficient /lib/security/$ISA/pam_winbind.so use_first_pass +password required /lib/security/$ISA/pam_deny.so + +session required /lib/security/$ISA/pam_limits.so +session sufficient /lib/security/$ISA/pam_unix.so +session sufficient /lib/security/$ISA/pam_winbind.so use_first_pass + + + + + + + Key Points Learned + + + The addition of UNIX/Linux Samba servers and clients is a common requirement. In this chapter, you + learned how to integrate such servers so that the UID/GID mappings they use can be consistent + across all Domain Member servers. You also discovered how to implement the ability to use Samba + or Windows Domain account credentials to log onto a UNIX/Linux client. + + + + The following are key points noted: + + + + + Domain Controllers are always authoritative for the Domain. + + + + Domain Members may have local accounts and must be able to resolve the identity of + Domain user accounts. Domain user account identity must map to a local UID/GID. That + local UID/GID can be stored in LDAP. This way, it is possible to share the IDMAP data + across all Domain Member machines. + + + + Resolution of user and group identities on Domain Member machines may be implemented + using direct LDAP services or using winbind. + + + + On NSS/PAM enabled UNIX/Linux systems, NSS is responsible for Identity management + and PAM is responsible for authentication of logon credentials (user name and password). + + + + + + + + + Questions and Answers + + + The following questions were obtained from the mailing list and also from private discussions + with Windows network administrators. + + + + + + + + We use NIS for all UNIX accounts. Why do we need winbind? + + + + + + + NIS + + encrypted passwords + + smbpasswd + + tdbsam + + passdb backend + + Winbind + + You can use NIS for your UNIX accounts. NIS does not store the Windows encrypted + passwords that need to be stored in one of the acceptable passdb backends. + Your choice of backend is limited to smbpasswd or + tdbsam. Winbind is needed to handle the resolution of + SIDs from trusted domains to local UID/GID values. + + + + winbind trusted domains only + + getpwnam() + + On a Domain Member server, you effectively map Windows Domain users to local users + that are in your NIS database by specifying the winbind trusted domains + only. This causes user and group account lookups to be routed via + the getpwnam() family of systems calls. On an NIS-enabled client, + this pushes the resolution of users and groups out through NIS. + + + + As a general rule, it is always a good idea to run winbind on all Samba servers. + + + + + + + + + + Our IT management people do not like LDAP, but are looking at Microsoft Active Directory. + Which is better? + Active Directory + + + + + + + + LDAP + server + + Kerberos + + schema + + Microsoft Active Directory is an LDAP server that is intricately tied to a Kerberos + infrastructure. Most IT managers who object to LDAP do so because of the fact that + an LDAP server is most often supplied as a raw tool that needs to be configured, and + for which the administrator must create the schema, create the administration tools and + devise the backup and recovery facilities in a site dependent manner. LDAP servers + in general are seen as a high-energy, high-risk facility. + + + + management + + Microsoft Active Directory by comparison is easy to install, configure, and + is supplied with all tools necessary to implement and manage the directory. For sites + that lack a lot of technical competence, Active Directory is a good choice. For sites + that have the technical competence to handle Active Directory well, LDAP is a good + alternative. The real issue that needs to be addressed is what type of solution does + the site want? If management wants a choice to use an alternative, they may want to + consider the options. On the other hand, if management just wants a solution that works, + Microsoft Active Directory is a good solution. + + + + + + + + + + We want to implement a Samba PDC, four Samba BDCs, and 10 Samba servers. Is it possible + to use NIS in place of LDAP? + + + + + + + NIS + + LDAP + + encrypted passwords + + synchronized + + secure account password + + PDC + + BDC + + Yes, it is possible to use NIS in place of LDAP, but there may be problems with keeping + the Windows (SMB) encrypted passwords database correctly synchronized across the entire + network. Workstations (Windows client machines) periodically change their Domain + Membership secure account password. How can you keep changes that are on remote BDCs + synchronized on the PDC? + + + + centralized storage + + management + + network Identities + + LDAP is a more elegant solution because it permits centralized storage and management + of all network Identities (user, group and machine accounts) together with all information + Samba needs to provide to network clients and their users. + + + + + + + + + + Are you suggesting that users should not log onto a Domain Member server? If so, why? + + + + + + + security + + data + integrity + + mapped drives + + Many UNIX administrators mock the model that the Personal Computer industry has adopted + as normative since the early days of Novell Netware. One may well argue that the old + perception of the necessity to keep users off file and print servers was a result of + fears concerning the security and integrity of data. It was a simple and generally + effective measure to keep users away from servers, except through mapped drives. + + + + user logins + + risk + + user errors + + strategy + + policy + + UNIX administrators are fully correct in asserting that UNIX servers and workstations + are identical in terms of the software that is installed. They correctly assert that + in a well secured environment it is safe to store files on a system that has hundreds + of users. But all network administrators must factor into the decision to allow or + reject general user logins to a UNIX system that is principally a file and print + server. One must take account of the risk to operations through simple user errors. + Only then can one begin to appraise the best strategy and adopt a site-specific + policy that best protects the needs of users and of the organization alike. + + + + system level logins + + From experience, it is my recommendation to keep general system level logins to a + practical minimum and to eliminate them if possible. This should not be taken as a + hard rule, though. The better question is, what works best for the site? + + + + + + + + + + winbind enable local accounts + + /etc/passwd + + options list + + ACL + + share + + In my &smb.conf; file, I enabled the parameter winbind enable local accounts + on all Domain Member servers, but it does not work. The accounts I put in + /etc/passwd do not show up in the options list when I try to set an + ACL on a share. What have I done wrong? + + + + + + + local users + + local groups + + UNIX account + + getpwnam() + + getgrgid() + + Identity resolution + + failure + + Domain + + The manual page for this &smb.conf; file parameter clearly says, This parameter + controls whether or not winbindd will act as a stand in replacement for the various + account management hooks in smb.conf (for example, add user script). If enabled, winbindd + will support the creation of local users and groups as another source of UNIX account + information available via getpwnam() or getgrgid(), etc... By default this + parameter is already enabled; therefore, the action you are seeing is a result of a failure + of Identity resolution in the Domain. + + + + Domain logons + + Identity resolution + + Domain + user + + Domain + group + + UID + + GID + + These are the accounts that are available for Windows network Domain logons. Providing + Identity resolution has been correctly configured on the Domain Controllers, as well as + on Domain Member servers. The Domain user and group identities automatically map + to a valid local UID and GID pair. + + + + + + + + + + trusted domains + + domain + trusted + + winbind trusted domains only + + domain members + + We want to ensure that only users from our own domain plus from trusted domains can use our + Samba servers. In the &smb.conf; file on all servers, we have enabled the winbind + trusted domains only parameter. We now find that users from trusted domains + cannot access our servers, and users from Windows clients that are not domain members + can also access our servers. Is this a Samba bug? + + + + + + + distributed + + NIS + + rsync + + LDAP + + winbindd + + /etc/passwd + + The manual page for this winbind trusted domains only parameter says, + This parameter is designed to allow Samba servers that are members of a Samba controlled + domain to use UNIX accounts distributed vi NIS, rsync, or LDAP as the UIDs for winbindd users + in the hosts primary domain. Therefore, the user SAMBA\user1 would be + mapped to the account user1 in /etc/passwd instead + of allocating a new UID for him or her. This would clearly suggest that you are trying + to use this parameter inappropriately. + + + + valid users + + A far better solution would be to use the valid users by specifying + precisely the Domain users and groups that should be permitted access to the shares. You could, + for example, set the following parameters: + +[demoshare] + path = /export/demodata + valid users = @"Domain Users", @"OTHERDOMAIN\Domain Users" + + + + + + + + + + + + What are the benefits of using LDAP for my Domain Member servers? + + + + + + + LDAP + + benefit + + UID + + GID + + Domain Controllers + + Domain Member servers + + copy + + replicate + + identity + + The key benefit of using LDAP is that the UID of all users and the GID of all groups + are globally consistent on Domain Controllers as well as on Domain Member servers. + This means that it is possible to copy/replicate files across servers without + loss of identity. + + + + Identity resolution + + winbind + + IDMAP backend + + LDAP + + Domain Controllers + + Domain Member + servers + + Posix + + account information + + When use is made of account Identity resolution via winbind, even when an IDMAP backend + is stored in LDAP, the UID/GID on Domain Member servers is consistent, but differs + from the ID that the user/group has on Domain Controllers. The winbind allocated UID/GID + that is stored in LDAP (or locally) will be in the numeric range specified in the + idmap uid/gid in the &smb.conf; file. On Domain Controllers, the UID/GID is + that of the Posix value assigned in the LDAP directory as part of the Posix account information. + + + + + + + + + + Is proper DNS operation necessary for Samba-3 plus LDAP? If so, what must I put into + my DNS configuration? + + + + + + + DNS + configuration + + DNS + lookup + + hosts + + /etc/nsswitch.conf + + NSS + + /etc/hosts + + WINS + lookup + + Samba depends on correctly functioning resolution of host names to their IP address. Samba + makes no direct DNS lookup calls, but rather redirects all name to address calls via the + getXXXbyXXX() function calls. The configuration of the hosts + entry in the NSS /etc/nsswitch.conf file determines how the underlying + resolution process is implemented. If the hosts entry in your NSS + control file says: + +hosts: files dns wins + + This means that a host name lookup first tries the /etc/hosts. + If this fails to resolve, it attempts a DNS lookup and if that fails, it tries a + WINS lookup. + + + + NetBIOS + + TCP/IP + + name resolution + + The addition of the WINS-based name lookup makes sense only if NetBIOS over TCP/IP has + been enabled on all Windows clients. Where NetBIOS over TCP/IP has been disabled, DNS + is the preferred name resolution technology. This usually makes most sense when Samba + is a client of an Active Directory Domain, where NetBIOS use has been disabled. In this + case, the Windows 200x auto-registers all locator records it needs with its own DNS + server/s. + + + + + + + + + + Our Windows 2003 Server Active Directory Domain runs with NetBIOS disabled. Can we + use Samba-3 with that configuration? + + + + + + + Yes. + + + + + + + + + + net + ads + join + + net + rpc + join + + When I tried to execute net ads join, I got no output. It did not work, so + I think that it failed. I then executed net rpc join and that worked fine. + That is okay, isn't it? + + + + + + + Kerberos + + authentication + + No. This is not okay. It means that your Samba-3 client has joined the ADS Domain as + a Windows NT4 client, and Samba-3 will not be using Kerberos-based authentication. + + + + + + + + + + -- cgit