Account Links: Cart | Your Account | Logout

Skip to content

Red Hat Knowledgebase

Red Hat Knowledgebase Search:

Updated Within the Last:

New Solutions within the last day New Solutions within the last week New Solutions within the last month

Browse by topics:


Click to View a Topic
General Linux > Samba > Issue <<  66 of 98 >>

Solution Tools:


Email a Solution Postcard Printer version Submit a comment on this answer Update notifications Request an answer Back

Article Reference

Article ID: 11146
Last update: 10-30-08
Issue:
How do I set up winbind to use an LDAP-based idmap backend instead of local tdb files?
Resolution:

PREREQUISITES

The following article applies to Samba packages contained within Red Hat Enterprise Linux versions 3, 4, and 5.

It is assumed and required that the following prerequisite configuration tasks have already been performed, and are beyond the scope of this article. Refer to other articles in the Red Hat Knowledgebase or other documentation sources for more information.

  1. The Samba server is properly joined to the domain. Winbind cannot provide full proper functionality if the host it is running on is not trusted by the domain controllers (DC's) it is communicating with. This is true even if the server will never be used as a Samba file/print server and only winbind's services are desired.
  2. Aside from the LDAP-specific winbind configuration directives in this article, winbind has otherwise been configured properly, including configuring it to authenticate itself when binding to DC's.
  3. An openldap server that is already functioning. It is also possible to use Red Hat Directory Server as an LDAP server, but the samba.schema Samba LDAP schema file provided with the base samba package MUST be converted to a format that Red Hat Directory Server can use. This article will document use of an openldap LDAP server.
  4. /etc/openldap/ldap.conf has been configured to define the LDAP server, search base, and any other environment-specific parameters to allow the openldap command line utilities such as ldapadd and ldapsearch to communicate with the correct server and search base without specifying them on the utility's command line.
  5. Only a Samba "member server" will be able to populate the LDAP server's Idmap ou container. A Samba PDC will not be able to, in the author's experience. Essentially, the first properly-configured Samba member server to start its winbind service will create the idmap which any other member server also configured to use an LDAP idmap backend will use.



CONFIGURATION STEPS

In the example configuration, the openldap server's data is based in dc=smbtest,dc=bogus. cn=Manager,dc=smbtest,dc=bogus is the administrative user and therefore has write permissions to the dc=smbtest,dc=bogus tree in the directory. When following this article, it will be necessary to modify the smb.conf configuration statements shown to reflect the correct base location and the LDAP user Samba should use for the target LDAP server.

1. Copy samba.schema to LDAP server and edit /etc/openldap/slapd.conf
Edit slapd.conf to include the samba.schema file packaged with the version of Samba the member server(s) will be running. The samba.schema file should be located in the /usr/share/doc/samba-(version)/LDAP directory on the Samba server, and a local copy should be placed on the LDAP server host in a directory the ldap user is able to read, such as /etc/openldap/schema. Changes in the samba.schema file between upstream Samba versions do occur, so it is important to ensure that the LDAP server is using the same samba.schema file that the Samba daemons in that version are built to understand. This also means it is important to keep all Samba member servers running the same Samba version, at least until it is known whether the samba.schema file has changed between the Samba version being used and a different version being considered.

2. Restart ldap service on the LDAP server
Once the slapd.conf file has been edited to include the correct samba.schema file, and the schema file is located in the directory referenced in slapd.conf, restart the ldap service.

3. Stop winbind and smb services on the Samba domain member server
While configuring winbind to use the LDAP idmap backend, winbind and smb service should not be running. Do not start the winbind service back up until this procedure instructs to do so.

4. Remove existing winbind idmap and cache TDB files
During testing in preparation of this article, it was found that if winbind's two TDB files already exist in Samba's lock directory (typically /var/cache/samba), winbindd will not populate the LDAP server's ou=Idmap container as needed. Therefore it is recommended to remove winbind's two TDB files if they already exist, or rename them if a backup of the original idmap is desired for some reason. This also precludes the ability to convert an existing tdb-based idmap to LDAP.

Winbind's two TDB files are named winbindd_cache.tdb and winbindd_idmap.tdb. With newer Samba versions such as 3.0.25b , an additional TDB file named idmap_cache.tdb may also be present and is also recommended to be deleted or renamed.

This step applies whether the Samba server being configured is the first/only server to use the LDAP idmap backend, or an additional server which is desired to map domain users and groups using the same LDAP-based idmap database.

# cd /var/cache/samba
# ls -l
total 168

-rw-r--r-- 1 root root   219 Jul 27 14:10 browse.dat
-rw-r--r-- 1 root root  4096 Aug  9 11:02 gencache.tdb
-rw------- 1 root root  4096 Aug  9 12:01 group_mapping.tdb
-rw------- 1 root root  8192 Aug 13 12:27 idmap_cache.tdb
-rw------- 1 root root   696 Aug 13 12:27 messages.tdb
-rw-r--r-- 1 root root  6149 Jul 24 04:02 namelist.debug
-rw------- 1 root root   696 Aug  9 11:02 netsamlogon_cache.tdb
drwxr-xr-x 2 root root  4096 May 15 13:38 perfmon
drwxr-xr-x 2 root root  4096 May 15 13:38 printing
drwxr-xr-x 2 root root  4096 Aug  6 13:33 smb_krb5
-rw------- 1 root root 53248 Aug 13 12:27 winbindd_cache.tdb
-rw-r--r-- 1 root root  8192 Aug 13 12:27 winbindd_idmap.tdb
drwxr-x--- 2 root root  4096 Aug 13 12:27 winbindd_privileged

# mv idmap_cache.tdb idmap_cache.tdb.backup

# mv winbindd_cache.tdb winbindd_cache.tdb.backup

# mv winbindd_idmap.tdb winbindd_idmap.tdb.backup



5. Edit /etc/samba/smb.conf

The following parameters will need to be added to the [global] section of smb.conf:

# replace samba-vmsrv1.smbtest.bogus with your ldap server host
idmap backend = ldap:"ldap://samba-vmsrv1.smbtest.bogus"

# the main ldap suffix will be appended to this to form the
# DN of the container we store this in:
ldap idmap suffix = ou=Idmap

# ssl off isn't mandatory just easier to set up
# work on getting ssl working later....
ldap ssl = off

# ldap user with write access to Idmap ou:
ldap admin dn = cn=Manager,dc=smbtest,dc=bogus

ldap suffix = dc=smbtest,dc=bogus

# without these set, domain users and groups
# will not show up in getent output
winbind enum users = yes
winbind enum groups = yes


6. Store Samba's LDAP Access Credentials
After adding the above to smb.conf, run 'smbpasswd -w <password>' to store the ldap admin dn's password into /etc/secrets.tdb. For example:

# smbpasswd -w secretpassword

This is a REQUIRED step when using an LDAP backend, and the smb.conf MUST already have a correct/valid ldap admin dn statement configured before executing the command. The admin dn specified in smb.conf and the password specified on the 'smbpasswd -w' command line will be saved in /etc/samba/secrets.tdb.

7. Manually add the Idmap ou container via .ldif file
The initial Idmap ou container must be created and added to the LDAP directory manually. Winbind will be able to use the ou=Idmap container if it exists, but is unable to create one. The following example-idmap-root.ldif file is sufficient for the example LDAP server configuration, but the dn will need to be edited appropriately to match the reader's environment:

dn: ou=Idmap,dc=smbtest,dc=bogus
objectClass: organizationalUnit
ou: Idmap

Save the example-idmap-root.ldif file, and add it to the LDAP directory using the ldapadd command line utility. Example output is provided below:

# ldapadd -v -x -D "cn=Manager,dc=smbtest,dc=bogus" -c -f example-idmap-root.ldif -W
Enter LDAP Password:
add objectClass:
organizationalUnit
add ou:
Idmap
adding new entry "ou=Idmap,dc=smbtest,dc=bogus"
modify complete

#


8. Start winbind on the member server
It should now be OK to start the winbind service back up by executing 'service winbind start'.

9. Verify winbind functionality
Verify winbind is able to enumerate domain users and groups with the commands 'wbinfo -u' (display domain users) and 'wbinfo -g' (display domain groups). Next, initiate population of the LDAP server's ou=Idmap container by running 'getent passwd' and 'getent group'. It is assumed that winbind is listed in /etc/nsswitch.conf as a source for passwd and group, as it should be. Note that the first execution of 'getent passwd' or 'getent group' may be a bit slow to show domain users or groups, depending on the size of the domain, since this prompts the population of the Idmap backend container on the LDAP server.

If desired, it can be confirmed that the LDAP server is being populated with Idmap entries. The following is an example command and semi-truncated output:

 

# ldapsearch -x -b ou=Idmap,dc=smbtest,dc=bogus

# extended LDIF
#
# LDAPv3
# base < ou=Idmap,dc=smbtest,dc=bogus > with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# Idmap, smbtest.bogus
dn: ou=Idmap,dc=smbtest,dc=bogus
objectClass: organizationalUnit
objectClass: sambaUnixIdPool
ou: Idmap
uidNumber: 10034
gidNumber: 10020

# S-1-5-21-1841342613-2888203691-3516634112-1142, Idmap, smbtest.bogus
dn: sambaSID=S-1-5-21-1841342613-2888203691-3516634112-1142,ou=Idmap,dc=smbtest,dc=bogus
objectClass: sambaIdmapEntry
objectClass: sambaSidEntry
uidNumber: 10000
sambaSID: S-1-5-21-1841342613-2888203691-3516634112-1142

# S-1-5-21-1841342613-2888203691-3516634112-513, Idmap, smbtest.bogus
dn: sambaSID=S-1-5-21-1841342613-2888203691-3516634112-513,ou=Idmap,dc=smbtest,dc=bogus
objectClass: sambaIdmapEntry
objectClass: sambaSidEntry
gidNumber: 10000
sambaSID: S-1-5-21-1841342613-2888203691-3516634112-513

[truncated]

# S-1-5-32-551, Idmap, smbtest.bogus
dn: sambaSID=S-1-5-32-551,ou=Idmap,dc=smbtest,dc=bogus
objectClass: sambaIdmapEntry
objectClass: sambaSidEntry
gidNumber: 10018
sambaSID: S-1-5-32-551

# S-1-5-32-545, Idmap, smbtest.bogus
dn: sambaSID=S-1-5-32-545,ou=Idmap,dc=smbtest,dc=bogus
objectClass: sambaIdmapEntry
objectClass: sambaSidEntry
gidNumber: 10019
sambaSID: S-1-5-32-545

# search result
search: 2
result: 0 Success

# numResponses: 56
# numEntries: 55

#


CONCLUSION
Even with the LDAP idmap backend working, winbind-related .tdb files will still be seen in /var/cache/samba. However with an LDAP idmap backend in use, these are strictly used for local caching, and in the event the files become corrupted, they can be deleted without impacting the master UID and GID maps stored in LDAP. TDB files should only be deleted while smb and winbind services are stopped.

Additional member servers can be configured to use the same LDAP-based idmap simply by repeating the configuration steps on these additional servers. It is strongly recommended, however, that the same idmap uid and idmap gid range are configured in the smb.conf of all such member servers.


How well did this entry answer your question?


good wrong incomplete out of date
General Linux > Samba > Issue <<   66  of  98  >>