United States (change)
Shortcuts: Downloads Fedora Red Hat Network
Account Links: Cart Your Account Logout
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.
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.