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 ???.
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 whatever the controlling technology may be. So let's get back to Abmas and our good friends Bob Jordan and company.
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.
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.
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?
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.
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.
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:
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.
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:
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.
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).
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.
If the parameter idmap backend = ldap: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.
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 accounts = Yes in the smb.conf file. This parameter specifically applies only to Domain Controllers, not to Domain Member servers.
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.
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.
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 only = Yes. 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).
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 however, this is transparent to the Windows network user. This data is stored in the winbindd_idmap.tdb and winbindd_cache.tdb files.
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.
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 it isn't religious or political. This also doesn't say that you can't use Windows Active Directory in a heterogenous environment it can be done, it just requires commercial integration products it's just not what Active Directory was designed for.
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.
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.
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.
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.
Why is this important? 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.
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.
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:
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.
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.
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.
Procedure 10.1. Configuration of LDAP-Based Identity Resolution
Create the smb.conf file as shown in ???. Locate this file in the directory /etc/samba.
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:
root# 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 ???.
Before proceeding to configure Samba, validate the operation of the NSS Identity resolution via LDAP by executing:
root# 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.
root# 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:
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.
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:
root# slapcat | grep -i idmap dn: ou=Idmap,dc=abmas,dc=biz ou: idmap
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:
root# 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.
The system is ready to join the Domain. Execute the following:
root# net rpc join -U root%not24et Joined domain MEGANET2.
This indicates that the Domain join succeeded.
Just joining the Domain is not quite enough, you must now provide a privilidged set of credentials through which winbindd can interact with the ADS Domain servers. Execute the following to implant the necessary credentials:
root# wbinfo --set-auth-user=Administrator%not24get
- The configuration is now ready to obtain ADS Domain user and group information.
You may now start Samba in the usual manner and your Samba Domain Member server is ready for use. Just add shares as required.
Example 10.1. Samba Domain Member in Samba Domain Control Context smb.conf File
Example 10.2. LDIF IDMAP Add-On Load File File: /etc/openldap/idmap.LDIF
dn: ou=Idmap,dc=abmas,dc=biz objectClass: organizationalUnit ou: idmap structuralObjectClass: organizationalUnit
Example 10.3. Configuration File for NSS LDAP Support /etc/ldap.conf
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
Example 10.4. NSS using LDAP for Identity Resolution File: /etc/nsswitch.conf
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
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.
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.
Note
If you use winbind for Identity resolution, do make sure that there are no duplicate accounts.
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.
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.
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.
Procedure 10.2. Configuration of Winbind-Based Identity Resolution
Using your favorite text editor, create the smb.conf file so it has the contents shown in ???.
Edit the /etc/nsswitch.conf so it has the entries shown in ???.
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.
Validate operation of winbind using the wbinfo tool as follows:
root# 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.
root# 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.
The next step verifies that NSS is able to obtain this information correctly from winbind also.
root# 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/bashThe user account information has been correctly obtained. This information has been merged with the winbind template information configured in the smb.conf file.
root# # 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.
Example 10.5. Samba Domain Member Server smb.conf File for NT4 Domain
Example 10.6. Name Service Switch Control File: /etc/nsswitch.conf
# /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
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.
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.
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:
root# cd /usr/sbin root# 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:
root# cd /usr/sbin root# 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:
root# 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.
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):
root# rpm -q krb5
Or on SUSE Linux, execute:
root# 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 ???.
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):
root# rm /var/lib/samba/*tdb
Validate your smb.conf file using testparm (as you have done previously). Correct all errors reported before proceeding. The command you execute is:
root# testparm -s | less
Now that you are satisfied that your Samba server is ready to join the Windows ADS Domain, let's move on.
This is a good time to double-check everything and then execute the following command when everything you have done has checked out okay:
root# 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.
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:
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.
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.
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:
root# 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).
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:
root# 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:
root# 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.
Now repeat this via NSS to validate that full Identity resolution is functional as required. Execute:
root# 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/bashOkay, ADS user accounts are being resolved. Now you try group resolution as follows:
root# 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.
You may now perform final verification that communications between Samba-3 winbind and the Active Directory server is using Kerberos protocols. Execute the following:
root# 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.
There is one more action you elect to take, just because you are paranoid and disbelieving, so you execute the following command:
root# 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.12-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 DescriptorAnd 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:
root# 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"
}
...
root# 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.
Example 10.7. Samba Domain Member smb.conf File for Active Directory Membership
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.
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
There are really only three solutions that provide integrated authentication and user Identity management facilities:
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.
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.
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.
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.
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.
Example 10.8. SUSE: PAM login 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
Example 10.9. SUSE: PAM xdm 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
Example 10.10. Red Hat 9: PAM System Authentication File: /etc/pam.d/system-auth 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
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).
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?
- Our IT management people do not like LDAP, but are looking at Microsoft Active Directory. Which is better?Active Directory
- We want to implement a Samba PDC, four Samba BDCs, and 10 Samba servers. Is it possible to use NIS in place of LDAP?
- Are you suggesting that users should not log onto a Domain Member server? If so, why?
- winbind enable local accounts/etc/passwdoptions listACLshare 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?
- trusted domainsdomaintrustedwinbind trusted domains onlydomain 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?
- What are the benefits of using LDAP for my Domain Member servers?
- Is proper DNS operation necessary for Samba-3 plus LDAP? If so, what must I put into my DNS configuration?
- Our Windows 2003 Server Active Directory Domain runs with NetBIOS disabled. Can we use Samba-3 with that configuration?
- netadsjoinnetrpcjoin 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?