Procedure 7.1. Configuration of NSS_LDAP-Based Identity Resolution

1. Create the smb.conf file as shown in “Samba Domain Member in Samba Domain Using LDAP smb.conf File”. Locate this file in the directory /etc/samba.

2. 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 “Configuration File for NSS LDAP Support /etc/ldap.conf”. 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
   

3. Configure the NSS control file so it matches the one shown in “NSS using LDAP for Identity Resolution File: /etc/nsswitch.conf”.

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.

5. 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 “LDIF IDMAP Add-On Load File File: /etc/openldap/idmap.LDIF”). 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
   

6. 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
   

7. 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):

   NT_STATUS_ACCESS_DENIED
   Join to 'MEGANET2' failed.
   

8. 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.

9. You may now start Samba in the usual manner, and your Samba domain member server is ready for use. Just add shares as required.

Procedure 7.2. Configuration of Winbind-Based Identity Resolution

1. Using your favorite text editor, create the smb.conf file so it has the contents shown in “Samba Domain Member Server Using Winbind smb.conf File for NT4 Domain”.

2. Edit the /etc/nsswitch.conf so it has the entries shown in “NSS using LDAP for Identity Resolution File: /etc/nsswitch.conf”.

3. 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.

4. 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.

5. 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:
   

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

Procedure 7.3. Configuration Using Local Accounts Only

1. Using your favorite text editor, create the smb.conf file so it has the contents shown in “Samba Domain Member Server Using Local Accounts smb.conf File for NT4 Domain”.

2. 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.

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

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

Procedure 7.4. Joining a Samba Server as an ADS Domain Member

1. 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
   

   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:

   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.

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

3. 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 “Samba Domain Member smb.conf File for Active Directory Membership”.

4. Edit or create the NSS control file so it has the contents shown in “NSS using LDAP for Identity Resolution File: /etc/nsswitch.conf”.

5. Delete the file /etc/samba/secrets.tdb if it exists. Of course, you do keep a backup, don't you?

6. 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
   

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

8. 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.

9. 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.

10. It is now time to start Samba in the usual way (as has been done many time before in this book).

11. 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.

12. 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.

13. 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.

14. 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/fran.london.abmas.biz
    servicePrincipalName: CIFS/fran
    servicePrincipalName: HOST/fran.london.abmas.biz
    servicePrincipalName: HOST/fran
    objectCategory: CN=Computer,CN=Schema,CN=Configuration,
                                  DC=london,DC=abmas,DC=biz
    isCriticalSystemObject: FALSE
    -------------- Security Descriptor (revision: 1, type: 0x8c14)
    owner SID: S-1-5-21-4052121579-2079768045-1474639452-512
    group SID: S-1-5-21-4052121579-2079768045-1474639452-513
    ------- (system) ACL (revision: 4, size: 120, number of ACEs: 2)
    ------- ACE (type: 0x07, flags: 0x5a, size: 0x38, 
                   mask: 0x20, object flags: 0x3)
    access SID:  S-1-1-0
    access type: AUDIT OBJECT
    Permissions:
            [Write All Properties]
    ------- ACE (type: 0x07, flags: 0x5a, size: 0x38, 
                   mask: 0x20, object flags: 0x3)
    access SID:  S-1-1-0
    access type: AUDIT OBJECT
    Permissions:
            [Write All Properties]
    ------- (user) ACL (revision: 4, size: 1944, number of ACEs: 40)
    ------- ACE (type: 0x00, flags: 0x00, size: 0x24, mask: 0xf01ff)
    access SID:  S-1-5-21-4052121579-2079768045-1474639452-512
    access type: ALLOWED
    Permissions: [Full Control]
    ------- ACE (type: 0x00, flags: 0x00, size: 0x18, mask: 0xf01ff)
    access SID:  S-1-5-32-548
    ...
    ------- ACE (type: 0x05, flags: 0x12, size: 0x38, 
                    mask: 0x10, object flags: 0x3)
    access SID:  S-1-5-9
    access type: ALLOWED OBJECT
    Permissions:
            [Read All Properties]
    -------------- End Of Security Descriptor
    

    And now you have conclusive proof that your Samba-3 ADS domain member server called FRAN is able to communicate fully with the ADS domain controllers.