Section 7.3. Implementation

7.3. Implementation

The domain member server and the domain member client are at the center of focus in this chapter. Configuration of Samba-3 domain controller is covered in earlier chapters, so if your interest is in domain controller configuration, you will not find that here. You will find good oil that helps you to add domain member servers and clients.

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.

We can look at this another way. If a workstation breaks down, one user is affected, but if a server breaks down, hundreds of users may not be able to work. The services that a workstation must provide are document-and file-production oriented; a server provides information storage and is distribution oriented.

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, in this chapter we demonstrate how to implement the technology. It is done within a context of what type of service need must be fulfilled.

7.3.1. Samba Domain with Samba Domain Member Server Using NSS LDAP

In this example, it is assumed that you have Samba PDC/BDC servers. This means you are using an LDAP ldapsam backend. We are adding to the LDAP backend database (directory) containers for use by the IDMAP facility. This makes it possible to have globally consistent mapping of SIDs to and from UIDs and GIDs. This means that it is necessary to run 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 the the local Samba server). Foreign SIDs can come from any domain member client or server, or from Windows clients that do not belong to a domain. Another way to explain the necessity to run winbindd is that Samba can locally resolve only accounts that belong to the security context of its own machine SID. Winbind handles all non-local SIDs and maps them to a local UID/GID value. The UID and GID are allocated from the parameter values set in the smb.conf file for the idmap uid and idmap gid ranges. Where LDAP is used, the mappings can be stored in LDAP so that all domain member servers can use a consistent mapping.

If your installation is accessed only from clients that are members of your own domain, and all user accounts are present in a local passdb backend then it is not necessary to run winbindd. The local passdb backend can be in smbpasswd, tdbsam, or in ldapsam.

It is possible to use a local passdb backend with any convenient means of resolving the POSIX user and group account information. The POSIX information is usually obtained using the getpwnam() system call. On NSS-enabled systems, the actual POSIX account source can be provided from

  • Accounts in /etc/passwd or in /etc/group.

  • 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, hesiod. When correctly installed, Samba adds to this list the winbindd facility. The ldap facility is frequently the nss_ldap tool provided by PADL Software.


To advoid confusion the use of the term local passdb backend means that the user account backend is not shared by any other Samba server instead, it is used only locally on the Samba domain member server under discussion.

The diagram in Figure 7.2 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.

Figure 7.2. Samba Domain: Samba Member Server

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 shown in Chapter 5, "Making Happy Users" and Chapter 6, "A Distributed 2000-User Network". If the network does not have an LDAP slave server (i.e., Chapter 5, "Making Happy Users" configuration), change the target LDAP server from lapdc to massive.



Create the smb.conf file as shown in Example 7.3.1. 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, however this file is intended for use by the OpenLDAP utilities and should not really be used by the nss_ldap utility since its content and structure serves the specific purpose of enabling the resolution of user and group IDs via NSS. Change the parameters inside the file that is located on your OS so it matches Example 7.3.3. 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 NSS control file so it matches the one shown in Example 7.3.4.


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 be. Notice that in the LDAP database the users' primary and secondary group memberships are identical. It is not necessary to add secondary group memberships (in the group database) if the user is already a member via primary group membership in the password database. When using winbind, it is in fact undesirable to do this because it results in doubling up of group memberships and may cause problems with winbind under certain conditions. It is intended that these limitations with winbind will be resolved soon after Samba-3.0.20 has been released.


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 Example 7.3.2). 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 the LDAP directory container when it needs to. To permit Samba write access to the LDAP directory it is necessary to set the LDAP administrative password in the secrets.tdb file as shown here:

root#  smbpasswd -w not24get 


The system is ready to join the domain. Execute the following:

root#   net rpc join -U root%not24get Joined domain MEGANET2. 

This indicates that the domain join succeeded. Failure to join the domain could be caused by any number of variables. The most common causes of failure to join are:

  • Broken resolution of NetBIOS names to the respective IP address.

  • Incorrect username and password credentials.

  • The NT4 restrict anonymous is set to exclude anonymous connections.

The connection setup can be diagnosed by executing:

root#   net rpc join -S 'pdc-name' -U administrator%password -d 5 

Note: Use "root" for UNIX/Linux and Samba, use "Administrator" for Windows NT4/200X. If the cause of the failure appears to be related to a rejected or failed NT_SESSION_SETUP* or an error message that says NT_STATUS_ACCESS_DENIED immediately check the Windows registry setting that controls the restrict anonymous setting. Set this to the value 0 so that an anonymous connection can be sustained, then try again. It is possible (perhaps even recommended) to use the following to validate the ability to connect to an NT4 PDC/BDC:

root#   net rpc info -S 'pdc-name' -U Administrator%not24get Domain Name: MEGANET2 Domain SID: S-1-5-21-422319763-4138913805-7168186429 Sequence number: 1519909596 Num users: 7003 Num domain groups: 821 Num local groups: 8 root#   net rpc testjoin -S 'pdc-name' -U Administrator%not24get Join to 'MEGANET2' is OK 

If for any reason the following response is obtained to the last command above,it is time to call in the Networking Super-Snooper task force (i.e., start debugging):



Just joining the domain is not quite enough; you must now provide a privileged set of credentials through which winbindd can interact with the domain servers. Execute the following to implant the necessary credentials:

root#  wbinfo --set-auth-user=Administrator%not24get 

The configuration is now ready to obtain the Samba 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.

7.3.2. NT4/Samba Domain with Samba Domain Member Server: Using NSS and 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, or a Samba 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.


If you use winbind for identity resolution, 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 WAN 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.



Using your favorite text editor, create the smb.conf file so it has the contents shown in Example 7.3.5.


Edit the /etc/nsswitch.conf so it has the entries shown in Example 7.3.4.


The system is ready to join the domain. Execute the following:

net rpc join -U root%not2g4et 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/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.

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.

7.3.3. NT4/Samba Domain with Samba Domain Member Server without NSS Support

No matter how many UNIX/Linux administrators there may be who believe that a UNIX operating system that does not have NSS and PAM support to be outdated, the fact is there are still many such systems in use today. Samba can be used without NSS support, but this does limit it to the use of local user and group accounts only.

The following steps may be followed to implement Samba with support for local accounts. In this configuration Samba is made a domain member server. All incoming connections to the Samba server will cause the look-up of the incoming username. If the account is found, it is used. If the account is not found, one will be automatically created on the local machine so that it can then be used for all access controls.



Using your favorite text editor, create the smb.conf file so it has the contents shown in Example 7.3.6.


The system is ready to join the domain. Execute the following:

net rpc join -U root%not24get Joined domain MEGANET2. 

This indicates that the domain join succeed.


Be sure to run all three Samba daemons: smbd, nmbd, winbindd.


The Samba member server of a Windows NT4 domain is ready for use.

7.3.4. Active Directory Domain with Samba 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.

The diagram in Figure 7.3 demonstrates how Samba-3 interfaces with Microsoft Active Directory components. It should be noted that if Microsoft Windows Services for UNIX (SFU) 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.

Figure 7.3. Active Directory Domain: Samba Member Server

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 its 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 and the name of the server is W2K3S. In ADS realm terms, the domain controller is known as 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:


This 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:


You can validate that Samba has been compiled and linked with LDAP support by executing:


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[2] 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 NSS.

[2] <>


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 Example 7.3.7.


Edit or create the NSS control file so it has the contents shown in Example 7.3.4.


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:

  • Defective or misconfigured DNS name resolution.

  • 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/bash 

Okay, ADS user accounts are being resolved. Now you try group resolution:

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: 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: 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.20-SUSE dNSHostName: fran userPrincipalName: HOST/fran@LONDON.ABMAS.BIZ servicePrincipalName: CIFS/ servicePrincipalName: CIFS/fran servicePrincipalName: HOST/ 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:

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 your team, has been put at ease. May this server serve well all who happen upon it. IDMAP_RID with Winbind

The idmap_rid facility is a new tool that, unlike native winbind, creates a predictable mapping of MS Windows SIDs to UNIX UIDs and GIDs. The key benefit of this method of implementing the Samba IDMAP facility is that it eliminates the need to store the IDMAP data in a central place. The downside is that it can be used only within a single ADS domain and is not compatible with trusted domain implementations.

This alternate method of SID to UID/GID mapping can be achieved with the idmap_rid plug-in. This plug-in uses the RID of the user SID to derive the UID and GID by adding the RID to a base value specified. This utility requires that the parameter "allow trusted domains = No" must be specified, as it is not compatible with multiple domain environments. The idmap uid and idmap gid ranges must be specified.

The idmap_rid facility can be used both for NT4/Samba-style domains as well as with Active Directory. To use this with an NT4 domain, the realm is not used. Additionally the method used to join the domain uses the net rpc join process.

An example smb.conf file for an ADS domain environment is shown in Example 7.3.8.

In a large domain with many users, it is imperative to disable enumeration of users and groups. For example, at a site that has 22,000 users in Active Directory the winbind-based user and group resolution is unavailable for nearly 12 minutes following first start-up of winbind. Disabling of such enumeration results in instantaneous response. The disabling of user and group enumeration means that it will not be possible to list users or groups using the getent passwd and getent group commands. It will be possible to perform the lookup for individual users, as shown in the procedure below.

The use of this tool requires configuration of NSS as per the native use of winbind. Edit the /etc/nsswitch.conf so it has the following parameters:

... passwd: files winbind shadow: files winbind group: files winbind ... hosts: files wins ... 

The following procedure can be used to utilize the idmap_rid facility:


Create or install and smb.conf file with the above configuration.


Edit the /etc/nsswitch.conf file as shown above.



root#  net ads join -UAdministrator%password Using short domain name -- KPAK Joined 'BIGJOE' to realm 'CORP.KPAK.COM' 

An invalid or failed join can be detected by executing:

root#  net ads testjoin BIGJOE$@'s password: [2004/11/05 16:53:03, 0] utils/net_ads.c:ads_startup(186)   ads_connect: No results returned Join to domain is not valid 

The specific error message may differ from the above because it depends on the type of failure that may have occurred. Increase the log level to 10, repeat the above test, and then examine the log files produced to identify the nature of the failure.


Start the nmbd, winbind, and smbd daemons in the order shown.


Validate the operation of this configuration by executing:

root#   getent passwd administrator administrator:x:1000:1013:Administrator:/home/BE/administrator:/bin/bash IDMAP Storage in LDAP using Winbind

The storage of IDMAP information in LDAP can be used with both NT4/Samba-3-style domains as well as with ADS domains. OpenLDAP is a commonly used LDAP server for this purpose, although any standards-compliant LDAP server can be used. It is therefore possible to deploy this IDMAP configuration using the Sun iPlanet LDAP server, Novell eDirectory, Microsoft ADS plus ADAM, and so on.

The example in Example 7.3.9 is for an ADS-style domain.

In the case of an NT4 or Samba-3-style domain the realm is not used, and the command used to join the domain is net rpc join. The above example also demonstrates advanced error reporting techniques that are documented in the chapter called "Reporting Bugs" in "The Official Samba-3 HOWTO and Reference Guide, Second Edition" (TOSHARG2).

Where MIT kerberos is installed (version 1.3.4 or later), edit the /etc/krb5.conf file so it has the following contents:

[logging]  default = FILE:/var/log/krb5libs.log  kdc = FILE:/var/log/krb5kdc.log  admin_server = FILE:/var/log/kadmind.log [libdefaults]  default_realm = SNOWSHOW.COM  dns_lookup_realm = false  dns_lookup_kdc = true [appdefaults]  pam = {    debug = false    ticket_lifetime = 36000    renew_lifetime = 36000    forwardable = true    krb4_convert = false } 

Where Heimdal kerberos is installed, edit the /etc/krb5.conf file so it is either empty (i.e., no contents) or it has the following contents:

[libdefaults]         default_realm = SNOWSHOW.COM         clockskew = 300 [realms]         SNOWSHOW.COM = {                 kdc = ADSDC.SHOWSHOW.COM         } [domain_realm] = SNOWSHOW.COM 


Samba cannot use the Heimdal libraries if there is no /etc/krb5.conf file. So long as there is an empty file, the Heimdal kerberos libraries will be usable. There is no need to specify any settings because Samba, using the Heimdal libraries, can figure this out automatically.

Edit the NSS control file /etc/nsswitch.conf so it has the following entries:

... passwd: files ldap shadow: files ldap group:  files ldap ... hosts:  files wins ... 

You will need the PADL[3] nss_ldap tool set for this solution. Configure the /etc/ldap.conf file so it has the information needed. The following is an example of a working file:

[3] <>

host base    dc=snowshow,dc=com binddn  cn=Manager,dc=snowshow,dc=com bindpw  not24get pam_password exop nss_base_passwd ou=People,dc=snowshow,dc=com?one nss_base_shadow ou=People,dc=snowshow,dc=com?one nss_base_group  ou=Groups,dc=snowshow,dc=com?one ssl     no 

The following procedure may be followed to affect a working configuration:


Configure the smb.conf file as shown above.


Create the /etc/krb5.conf file following the indications above.


Configure the /etc/nsswitch.conf file as shown above.


Download, build, and install the PADL nss_ldap tool set. Configure the /etc/ldap.conf file as shown above.


Configure an LDAP server and initialize the directory with the top-level entries needed by IDMAP as shown in the following LDIF file:

dn: dc=snowshow,dc=com objectClass: dcObject objectClass: organization dc: snowshow o: The Greatest Snow Show in Singapore. description: Posix and Samba LDAP Identity Database dn: cn=Manager,dc=snowshow,dc=com objectClass: organizationalRole cn: Manager description: Directory Manager dn: ou=Idmap,dc=snowshow,dc=com objectClass: organizationalUnit ou: idmap 


Execute the command to join the Samba domain member server to the ADS domain as shown here:

root#  net ads testjoin Using short domain name -- SNOWSHOW Joined 'GOODELF' to realm 'SNOWSHOW.COM' 


Store the LDAP server access password in the Samba secrets.tdb file as follows:

root#  smbpasswd -w not24get 


Start the nmbd, winbind, and smbd daemons in the order shown.

Follow the diagnostic procedures shown earlier in this chapter to identify success or failure of the join. In many cases a failure is indicated by a silent return to the command prompt with no indication of the reason for failure. IDMAP and NSS Using LDAP from ADS with RFC2307bis Schema Extension

The use of this method is messy. The information provided in this section is for guidance only and is very definitely not complete. This method does work; it is used in a number of large sites and has an acceptable level of performance.

An example smb.conf file is shown in Example 7.3.10.

The DMS must be joined to the domain using the usual procedure. Additionally, it is necessary to build and install the PADL nss_ldap tool set. Be sure to build this tool set with the following:

./configure --enable-rfc2307bis --enable-schema-mapping make install 

The following /etc/nsswitch.conf file contents are required:

... passwd: files ldap shadow: files ldap group:  files ldap ... hosts:  files wins ... 

The /etc/ldap.conf file must be configured also. Refer to the PADL documentation and source code for nss_ldap instructions.

The next step involves preparation on the ADS schema. This is briefly discussed in the remaining part of this chapter.

IDMAP, Active Directory, and MS Services for UNIX 3.5 The Microsoft Windows Service for UNIX version 3.5 is available for free download[4] from the Microsoft Web site. You will need to download this tool and install it following Microsoft instructions.

[4] <>

IDMAP, Active Directory, and AD4UNIX Instructions for obtaining and installing the AD4UNIX tool set can be found from the Geekcomix[5] Web site.

[5] <>

7.3.5. UNIX/Linux Client Domain Member

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 (SSO) solution. SSO systems are sold by a large number of vendors and include a range of technologies such as:

  • Proxy sign-on

  • Federated directory provisioning

  • Metadirectory server solutions

  • Replacement authentication systems

There are really only three solutions that provide integrated authentication and user identity management facilities:

  • Samba winbind (free)

  • PADL[6] PAM and LDAP tools (free)

    [6] <>

  • Vintela[7] Authentication Services (commercial)

    [7] <>

The following guidelines are pertinent to the deployment of winbind-based authentication and identity resolution with the express purpose of allowing users to log on to 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 installed, winbind is your best friend. Specific guidance for these situations now follows.

To permit users to log on to 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 (or Samba-3) domain network credentials:


Follow the steps outlined in Section 7.3.2 and ensure that all validation tests function as shown.


Identify what services users must log on to. 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 Example 7.3.11.


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 Section 7.3.4 and ensure that all validation tests function as shown.


Identify what services users must log on to. 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 Example 7.3.13.


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 Example 7.3.11.


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.

7.3.6. 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 on to a UNIX/Linux client.

The following are key points made in this chapter:

  • 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 (username and password).

    Samba-3 by Example. Practical Exercises to Successful Deployment
    Samba-3 by Example: Practical Exercises to Successful Deployment (2nd Edition)
    ISBN: 013188221X
    EAN: 2147483647
    Year: 2005
    Pages: 142

    Similar book on Amazon © 2008-2017.
    If you may any questions please contact us: